Ubiquiti Site Magic Routing: A No-Nonsense Beginner Guide to Routes, Route Injection, and Software-Defined Wide Area Network Fabric Design

Site Magic is one of those UniFi features that feels easy until the first routing problem shows up. The tunnel says it is connected. Both sites look healthy. You can see the remote gateway. Then the actual server, printer, backup target, or management page still does not work. That is when the uncomfortable truth appears: a site-to-site Virtual Private Network (VPN) is not the same thing as working routing, and working routing is not the same thing as permission.

This article is written for the person who is new to routing but wants to understand what is actually happening inside a Ubiquiti Site Magic fabric. We are going to slow it down, define the words, and build the mental model step by step. The goal is not to memorize every protocol detail. The goal is to know what to advertise, what not to advertise, how route injection works, and how to troubleshoot without guessing.

The Beginner Mental Model

Think of every site as a town. A subnet is a neighborhood. A device IP address is a house. A gateway is the town exit. A route is a road sign. The Site Magic tunnel is the private road connecting towns. A firewall is the gate that decides whether a traveler is allowed through.

A tunnel being up means the private road exists. It does not prove that every device knows to use the road. It does not prove the far side knows how to reply. It does not prove firewall rules allow the conversation.

That is why “Site Magic is connected” and “my app works across sites” are different statements. A working connection needs all three pieces: tunnel, route, and permission.

Interactive packet walk: Branch client to HQ server

Example: Branch client 10.20.0.25 opens a file share on HQ server 10.0.10.50.

1. Client sends packet.
Source: 10.20.0.25. Destination: 10.0.10.50. The destination is not local, so the client sends it to the Branch UniFi gateway.

2. Branch gateway checks the route table.
It matches 10.0.0.0/16 via Site Magic because the HQ hub advertised that route.

3. Packet enters the Site Magic tunnel.
The tunnel carries the packet across the internet as encrypted site-to-site Virtual Private Network traffic.

4. HQ gateway receives the packet.
The HQ gateway knows 10.0.10.50 is local behind it.

5. Firewall policy is checked.
If Branch users are allowed to reach the HQ file server on Server Message Block port 445, the packet continues. If not, it stops here.

6. Server replies.
The reply must have a valid return route back to 10.20.0.25. Routing is always a round trip.

Failure shortcut: If no route exists, the packet never enters Site Magic. If the firewall blocks it, the route can be correct and the connection still fails.

What Site Magic Is Really Doing

Ubiquiti documents Site Magic under UniFi SD-WAN. The friendly summary is this: Site Magic creates managed site-to-site VPN connectivity between UniFi gateways, then lets you choose which networks and routes should be shared through that fabric. Ubiquiti also notes that Site Magic uses Open Shortest Path First internally to optimize routing between UniFi gateways.

That last sentence can sound intimidating, but for a beginner it means this: you are not hand-writing every tunnel route the old way. UniFi is helping distribute routing information between participating gateways. Your job is to decide what should be shared and what should stay private.

Networks vs Routes: The Route Injection Moment

This is the part that trips people up. In Hub-and-Spoke, Ubiquiti separates shared “Networks” from shared “Routes.” They sound similar, but they are not the same design idea.

Networks and Routes in plain English

Item	What It Usually Means	Beginner Example	When You Use It
Network	A local UniFi network that lives directly on the selected gateway.	HQ Servers VLAN: 10.0.10.0/24.	You want remote sites to reach a local VLAN behind the hub or spoke.
Route	A non-local subnet the hub knows how to reach, such as another VPN, another router, or a summary route.	Data center summary 10.50.0.0/16 behind the HQ hub.	You want the hub to inject reachability for something beyond its directly attached UniFi networks.
Summary route	A larger route that represents multiple smaller related networks.	10.50.0.0/16 instead of ten separate /24 routes.	You own the whole range and want cleaner route advertisements.
Default route	The catch-all route for everything, written as 0.0.0.0/0.	Send all internet traffic through HQ.	Use cautiously. This is not the normal Site Magic beginner default and may require Policy-Based Routing.

Route injection is the act of sharing a route into the fabric so other participating gateways learn that a destination exists through a Site Magic path. In a home lab, this might mean the main UniFi gateway advertises a route to a lab subnet behind a separate router. In a small office, it might mean the hub advertises a partner VPN subnet reachable behind the office gateway.

Static Routes at the Hub: Getting Them to Spokes

Static routes at the hub are one of the most useful Site Magic patterns. The common design looks like this: the hub UniFi gateway has a downstream router, lab router, data-center firewall, or third-party VPN device behind it. That downstream device owns networks that are not directly attached UniFi networks. The hub can reach them because it has a static route, but the spokes will not magically learn those networks unless you also advertise them in the Hub-and-Spoke SD-WAN Routes list.

Think of it as two separate jobs. First, the hub must know how to reach the downstream network. Second, Site Magic must be told to share that destination with the spokes. If you do the first job but skip the second, the hub can reach the network but the spokes may not know the path. If you do the second job but skip the first, the spokes may send traffic to the hub and the hub will not know where to forward it.

Static Route Example

Imagine the hub site has a downstream lab router at 10.0.99.2. Behind that lab router is 10.60.0.0/16. You want spokes to reach selected services in that lab range.

1. Create or confirm the static route at the hub. Destination: 10.60.0.0/16. Next hop: 10.0.99.2. The hub UniFi gateway must be able to forward packets toward the downstream router.
2. Add the route to the Hub-and-Spoke SD-WAN hub Routes list. In the Site Magic / UniFi SD-WAN Hub configuration, add 10.60.0.0/16 as a shared Route, not as a local Network.
3. Confirm the downstream router has a return path. The lab router must know how to reach spoke subnets such as 10.20.0.0/24 and 10.30.0.0/24. This might be a default route back to the hub, static routes for spoke summaries, or a dynamic routing design outside Site Magic.
4. Add firewall rules. Allow only the spoke source networks that need the lab services. Do not turn the whole lab into a flat extension of every spoke.
5. Test from a real spoke client. Test an IP address first, then a real port, then DNS. If the hub can reach the lab but the spoke cannot, check the Hub Routes list and the downstream return route.

What If One Site Uses BGP?

Border Gateway Protocol (BGP) adds another layer. Ubiquiti supports BGP on specific UniFi gateways, and its BGP documentation describes exchanging routes with other gateways, Layer 3 switches, providers, or VPN peers. That does not mean every BGP-learned route is automatically redistributed into the Site Magic fabric. Ubiquiti documents that Site Magic uses Open Shortest Path First internally, but it does not expose Site Magic as a normal OSPF process where you can freely tune redistribution, areas, route maps, metrics, or administrative distance.

So the beginner-safe answer is this: treat BGP-learned prefixes as candidates for selected route sharing. If the hub can reach a BGP-learned network and your spokes truly need it, advertise a specific prefix or clean summary through the Hub-and-Spoke Routes list. Do not assume the entire BGP table will appear in Site Magic, and do not try to use Policy-Based Routing as a substitute for missing route advertisement.

BGP-to-Spoke Design Pattern

1. Identify the exact BGP-learned prefix that spokes need. Example: 10.70.20.0/24 for an application subnet, or a carefully planned summary such as 10.70.0.0/16.
2. Confirm the hub has a working route to that prefix. The route might be learned by BGP on the hub itself, learned by a neighboring router, or reachable through a static route to a BGP-speaking device.
3. Advertise only the needed prefix or summary as a Hub Route. In Hub-and-Spoke Site Magic, add it under the hub Routes selection. Do not advertise broad ranges because they are convenient.
4. Make the return path explicit. The BGP side must know how to return to spoke networks. Depending on your design, that may mean advertising spoke summaries into BGP, adding static routes on the BGP router, or keeping the return path through the hub default route. This is outside the magic part of Site Magic; it is normal routing design.
5. Keep firewall policy narrow. The route only creates reachability. Allow the exact source, destination, protocol, and port the application needs.

Hub-and-Spoke Routing

Hub-and-Spoke is the easier default for most people because it gives the network a center of gravity. The hub is where shared services usually live: Network Attached Storage, Domain Name System, monitoring, cameras, backups, management tools, file shares, or cloud egress. Spokes are remote locations that mainly need the hub, not each other.

In Hub-and-Spoke, the hub can advertise selected local networks and selected routes. Spokes learn that traffic for those destinations should go to the hub. The hub can also learn selected spoke networks if you want hub users or services to reach spoke resources.

Spoke-to-spoke traffic is a separate design choice. Ubiquiti documents spoke isolation as a way to block traffic between spokes using hub firewall rules. If two branches do not need to talk to each other, isolation is your friend.

Mesh Routing

Mesh is for peer sites. Instead of remote sites mostly talking through a central hub, selected networks at each participating site become reachable directly between mesh members. That can be great when sites genuinely need lateral communication. It can also be too much reachability if you use it because it sounds more advanced.

Ubiquiti documents Mesh as supporting up to 20 sites. The setup flow is simpler: select the participating gateways and the networks from each site that should participate. Ubiquiti does not document the same manual shared Routes option for Mesh that it documents for Hub-and-Spoke. Mesh is direct, but less customizable.

Route Summarization: Cleaner, But Sharper

Summarization means advertising one larger route instead of many smaller routes. If you own 10.50.1.0/24, 10.50.2.0/24, and several other related networks, you might advertise 10.50.0.0/16 from the hub. That can make the fabric cleaner.

The danger is that a summary route can include more than you intended. If you advertise 10.50.0.0/16, you are saying the hub is the path for everything from 10.50.0.0 through 10.50.255.255. Do that only when it matches your actual design.

The Safe Advertising Rule

Start with the smallest reachability that solves the real problem. Then add firewall rules that are even narrower. This is the difference between a working lab and a giant flat network stretched over the internet.

Should I advertise this network through Site Magic?

Plain English: advertising a network tells other Site Magic gateways, “traffic for this subnet should come to me.” Only advertise networks another site genuinely needs to reach.

Question	If yes	If no
Do users at another site need this subnet?	Consider advertising it.	Leave it unshared.
Is it guest, Internet of Things, camera, or lab?	Usually do not advertise it unless there is a specific reason.	It may be a better candidate if it hosts shared resources.
Does it overlap with another site?	Fix the overlap first or use supported Hub-and-Spoke NAT behavior deliberately.	Proceed normally.
Is it not local to the UniFi hub, but reachable behind the hub?	Advertise it as a shared Route in Hub-and-Spoke.	Select the local Network you want to share.

Beginner rule: advertise the smallest set of networks that makes the task work. “Everything everywhere” is easier to click, but harder to secure and troubleshoot.

Beginner route-advertising scenarios

Scenario	Advertise	Do Not Advertise	Firewall Rule Pattern	Test
Home lab hub with NAS	NAS or storage subnet, such as 10.10.20.0/24. Optional DNS subnet if remote sites use hub DNS.	Guest, cameras, Internet of Things, lab experiments, full client LAN.	Allow remote trusted LANs to the NAS only on needed ports such as TCP 445 or backup app ports.	From a remote site, open the share and confirm guest or IoT cannot reach it.
Managed family network	Admin/support subnet or one support device.	Your private home devices, cameras, kids gaming VLAN, guest networks.	Allow your admin subnet to family router UI or support PC. Block family site from initiating into your home LAN.	From your admin laptop, reach the support target. From family PC, confirm it cannot browse your devices.
Small office and warehouse	Office server subnet and warehouse scanner subnet if required.	Office guest Wi-Fi, cameras, personal devices, building controls.	Allow scanner/POS subnet to the office app server only on app/database ports.	Scanner reaches the app. Warehouse guest Wi-Fi cannot reach office systems.
Camera or IoT exclusion	Usually nothing. Maybe the recorder/NVR subnet if remote viewing is required.	Raw camera VLAN, smart plugs, TVs, speakers, guest/IoT.	Block VPN sources to camera/IoT VLANs. Optionally allow admin subnet to NVR HTTPS only.	Remote admin can view NVR if intended; remote site cannot ping cameras.
Remote backups	Backup target subnet or one backup server route.	Normal user LAN, guest, camera/IoT, management VLAN.	Allow source backup device to target on backup ports such as SSH, SMB, or app-specific ports.	Run a small backup and a restore listing. Confirm backup target cannot browse the source LAN.
Cloud or third-party edge behind hub	Only internal subnets that need the cloud or third-party path.	Default route unless deliberately planned, guest, IoT, overlapping networks.	Use IPsec/OpenVPN for the third party. Advertise or policy-route only specific cloud CIDR ranges.	Client reaches cloud private IP. Normal internet still exits where you expect.

Overlapping Subnets and NAT

Overlapping subnets are one of the most common home-network problems. If Site A and Site B both use 192.168.1.0/24, a device at Site A may think 192.168.1.50 is local even when you meant the remote site. The packet never takes the Site Magic road because the local map says the destination is right here.

When you control both networks, the clean answer is renumbering. Use unique site ranges such as 10.10.0.0/16 for home, 10.20.0.0/16 for parents, and 10.30.0.0/16 for a shop or office. Give yourself room to grow.

Ubiquiti documents Auto-Scale and NAT Spoke VPN behavior for Hub-and-Spoke overlap cases. In plain English, NAT lets overlapping spoke networks appear as different translated ranges at the hub. That removes ambiguity, but it also changes what the hub sees in logs and can make hub-initiated access require Destination NAT rules. Ubiquiti documents that Mesh does not support NAT for overlapping subnets.

Two sites use the same subnet. What now?

If Site A and Site B both use 192.168.1.0/24, routing becomes ambiguous. The gateway cannot reliably know which 192.168.1.50 you mean.

Situation	Best next move	Why
You are still designing the network.	Renumber one site.	Clean routing beats clever workarounds.
Spoke users only need hub resources.	Hub-and-Spoke Auto-Scale/NAT may be acceptable.	It can translate overlapping spoke traffic into unique ranges.
Hub must initiate into a NATed spoke.	Plan Destination NAT rules for each exposed resource.	Spoke-initiated access is the default easy direction.
You are building Mesh.	Renumber overlapping networks.	Ubiquiti documents that Mesh does not support NAT for overlapping subnets.

Noob translation: overlapping subnets are like two buildings with the same room numbers. NAT can help in some Hub-and-Spoke cases, but changing one building’s room numbers is often the cleaner fix.

Policy-Based Routing and Default Routes

Normal routing asks: “Where is the destination?” Policy-Based Routing asks a richer question: “Who is sending this traffic, where is it going, and which interface or tunnel should it use?” UniFi Policy-Based Routing can direct selected traffic through a Wide Area Network, local interface, or VPN tunnel.

This matters because people sometimes expect Site Magic to automatically send internet traffic through another site. That is not the beginner default. Site Magic route advertisements are about reachable remote networks. If you want a branch VLAN to send internet traffic through HQ for filtering or IP allowlisting, treat that as a separate design using the supported routing and policy tools.

Firewall Rules: Routes Are Not Trust

A route says, “this destination is reachable this way.” A firewall rule says, “this source is allowed to talk to that destination on this protocol and port.” You need both. If you advertise a server subnet but the firewall blocks the branch client, the route can be correct and the app can still fail.

The noob mistake is to add an allow-any rule between sites because something did not work. That may fix the immediate symptom, but it quietly turns your segmented network into a stretched flat network. A compromised client at one site can now explore another site.

Least-privilege firewall examples

Instead of This	Use This
Site A any → Site B any: allow	Site A Staff VLAN → Site B File Server: TCP 445 allow
Remote any → Management VLAN any: allow	Admin subnet → gateway/switch management: HTTPS/SSH only
IoT VLAN → VPN any: allow	IoT VLAN → VPN any: block unless one device has a documented need.
Guest VLAN → remote LAN: allow	Guest VLAN → remote LAN: block. Guests should not cross your SD-WAN.

DNS: When IP Works But Names Fail

Domain Name System is separate from routing. A route can be perfect and a hostname can still fail. Test by IP address first. If 10.0.10.50 works but nas.home.arpa fails, you probably have a DNS problem, not a Site Magic route problem.

For multi-site networks, decide which DNS server each VLAN should use. Some people centralize DNS at the hub. Others keep DNS local and use conditional forwarding for internal zones. Both can work, but the design needs to be intentional. Do not rely on .local names across routed networks unless multicast Domain Name System reflection is deliberately configured and scoped.

Troubleshooting: Walk the Packet

The best troubleshooting habit is to follow one packet from source to destination and back. Write down the exact source IP, destination IP, port, and expected path. Change one thing at a time. Retest the same thing after each change.

Site Magic route not working? Climb this ladder

1. Confirm the goal.
Write the source device, destination device, source subnet, destination subnet, and app or port. “Branch laptop to HQ printer” is fixable. “VPN broken” is too vague.

2. Check tunnel status.
In UniFi Site Manager, open the SD-WAN group and confirm both sites are connected and healthy.

3. Check advertised networks and routes.
If only 10.20.0.0/24 is shared, traffic to 10.30.0.0/24 will not work. Tunnel up plus missing advertised network means no route.

4. Check subnet overlap.
If both sides use the same private range, the source may treat the destination as local and never send traffic into the tunnel.

5. Test by IP address before DNS names.
If ping 10.0.10.50 works but ping server.home.arpa fails, routing is probably fine and Domain Name System is the issue.

6. Test a real port.
Windows: Test-NetConnection 10.0.10.50 -Port 445. macOS or Linux: nc -vz 10.0.10.50 445. Ping can be blocked even when the app works.

7. Check firewall and isolation.
Routes create a path. Firewall rules, network isolation, and host firewalls still decide whether traffic is allowed.

8. Check return path.
The destination must know how to reply. Confirm the remote client uses its local UniFi gateway and not another router, VPN app, or static gateway.

9. Check NAT and Carrier-Grade NAT.
If the WAN address is private or in 100.64.0.0/10, the site may be behind upstream NAT. Site Magic can often traverse NAT, but topology requirements still matter.

10. Review logs.
Look for tunnel disconnects, WAN failover, firewall drops, Intrusion Detection System or Intrusion Prevention System blocks, DNS failures, or route changes.

Command Examples for Real Testing

Use these from a client device, not only from the gateway. Gateway-to-gateway success is useful, but the actual user workflow usually happens from a laptop, workstation, phone, server, printer, or backup device.

Beginner testing commands

Goal	Windows	macOS / Linux	What It Tells You
Check IP reachability	ping 10.0.10.50	ping 10.0.10.50	Basic reachability, but ping can be blocked by firewalls.
Test a TCP port	Test-NetConnection 10.0.10.50 -Port 445	nc -vz 10.0.10.50 445	Better app-level test for a specific service.
Trace the path	tracert -d 10.0.10.50	traceroute 10.0.10.50	Shows whether traffic heads toward the tunnel or the normal internet, though VPN devices may hide hops.
Check DNS resolution	nslookup nas.home.arpa	dig nas.home.arpa	Shows whether the name resolves to the expected private IP.
Check default gateway	ipconfig	ip route | grep default or route -n get default	Confirms the client is using the expected UniFi gateway.

A Practical Design Workflow

1. Draw the sites. Name every site and write its subnets. Example: Home 10.10.0.0/16, Parents 10.20.0.0/16, Shop 10.30.0.0/16.
2. Pick the topology. Use Hub-and-Spoke when remote sites mostly need central services. Use Mesh only when peer sites genuinely need direct communication.
3. Choose the exact services. Write “Branch laptop to HQ file server on TCP 445,” not “Branch needs HQ.”
4. Advertise the smallest useful networks. Prefer a server subnet or specific route over an entire site when possible.
5. Add firewall rules after routes. Allow only the source, destination, and port that match the workflow.
6. Test by IP address first. DNS comes later.
7. Test from real clients. A gateway ping is not the same as a user workflow.
8. Document the route. Record why it exists, who owns it, and how to test it.
9. Review after every new VLAN or site. Site Magic makes sharing easy, so stale route decisions accumulate quickly.

Beginner Checklist Before You Click Connect

Limitations and Gotchas

• Site Magic is UniFi gateway to UniFi gateway. Use IPsec or OpenVPN for third-party gateways and many cloud-provider use cases.
• Legacy USG models are not supported in Ubiquiti guidance for this SD-WAN feature.
• IPv6 is not yet supported for Site Magic SD-WAN according to Ubiquiti FAQ guidance.
• Hub-and-Spoke and Mesh have different behavior. Do not assume a design option in one topology exists in the other.
• Mesh supports up to 20 sites in Ubiquiti documentation.
• Mesh does not support NAT for overlapping subnets in Ubiquiti documentation.
• Hub-and-Spoke can use Auto-Scale/NAT for overlapping spoke networks, but NAT can hide client identity and complicate hub-initiated access.
• Existing tunnels should keep passing traffic during a Ubiquiti cloud issue, but configuration changes depend on cloud availability.
• Ownership and Fabric permissions matter. Treat account ownership as part of the network design, not an afterthought.
• Sending broad internet traffic through another site is a separate routing or policy design. Do not confuse remote subnet reachability with default-route steering.

Glossary

If the routing terms blurred together while reading, use this as the quick reference. The article intentionally keeps these definitions plain-English instead of protocol-textbook perfect.

Beginner glossary

Term	Plain-English Meaning	Example
Software-Defined Wide Area Network (SD-WAN)	A managed way to connect sites and steer traffic across Wide Area Network links.	UniFi SD-WAN / Site Magic connecting a home lab and a branch office.
Virtual Private Network (VPN) tunnel	The encrypted private path between gateways.	A Site Magic tunnel between two UniFi gateways.
Local Area Network (LAN)	The network inside one site before traffic leaves through a gateway.	A home LAN, office LAN, or lab LAN.
Headquarters (HQ)	The main or central site in a Hub-and-Spoke design.	The HQ hub hosts shared servers and central services.
Subnet	A group of Internet Protocol addresses treated as one local network.	10.20.0.0/24
Classless Inter-Domain Routing (CIDR)	The slash notation that describes how large a subnet or route is.	/24, /16, and 0.0.0.0/0.
Route	A road sign that tells a gateway where to send traffic for a destination.	Send 10.0.0.0/16 through Site Magic.
Static route	A route manually configured by an admin.	Destination 10.60.0.0/16 via next hop 10.0.99.2.
Border Gateway Protocol (BGP)	A dynamic routing protocol used to exchange routing information between routers, sites, providers, or routing domains.	A hub learns 10.70.0.0/16 from a data-center router by BGP.
Autonomous System (AS)	A routing domain used by BGP.	Your lab router and hub gateway might use an internal AS number.
Layer 3 switch	A switch that can route between networks.	A core switch that exchanges BGP routes with a UniFi gateway.
Route redistribution	Moving routes learned by one routing method into another routing method.	Taking selected BGP-learned routes and making them reachable to spokes by advertising hub Routes.
Virtual Local Area Network (VLAN)	A separated network segment usually carried over shared switching hardware.	Servers VLAN, Internet of Things VLAN, guest VLAN.
Internet of Things (IoT)	Smart devices and appliance-style devices that usually should not be trusted like laptops and servers.	Cameras, TVs, smart plugs, speakers, and sensors.
Network Attached Storage (NAS)	A storage device or server that provides shared files over the network.	A Synology, TrueNAS, or file server at the hub site.
Advertised network	A local UniFi network selected to be reachable through the fabric.	The HQ server VLAN is shared with branches.
Injected route	A non-local or manually selected route shared into the fabric, usually from a hub.	The hub advertises a partner VPN subnet behind it.
Summary route	One larger route that represents several smaller networks.	10.50.0.0/16 covers many 10.50.x.0/24 networks.
Firewall rule	A permit or deny decision after a route exists.	Allow Branch A staff to reach HQ server on TCP port 445.
Transmission Control Protocol (TCP)	A common transport protocol used by many applications that need reliable sessions.	Server Message Block on TCP port 445.
Server Message Block (SMB)	A file-sharing protocol commonly used by Windows shares and many Network Attached Storage systems.	SMB commonly uses TCP port 445.
Secure Shell (SSH)	An encrypted remote login and file-transfer protocol.	SSH commonly uses TCP port 22.
Hypertext Transfer Protocol Secure (HTTPS)	Encrypted web access used by many admin pages and applications.	HTTPS commonly uses TCP port 443.
Internet Protocol Security (IPsec)	A common standard for site-to-site VPNs outside Site Magic.	A third-party cloud VPN might use IPsec instead of Site Magic.
Network Address Translation (NAT)	A way to rewrite source or destination addresses so overlapping or hidden networks can communicate.	Spoke 192.168.1.0/24 appears to the hub as 172.16.1.0/24.
Source NAT (SNAT)	Translation of the source address.	A spoke client is translated before reaching the hub.
Destination NAT (DNAT)	Translation of the destination address.	The hub reaches a specific device behind a NATed spoke.
Open Shortest Path First (OSPF)	A routing protocol that lets routers share route information.	Ubiquiti says Site Magic uses OSPF internally to optimize paths between UniFi gateways.
Domain Name System (DNS)	The naming system that turns names into IP addresses.	nas.home.arpa resolves to 10.0.10.50.
Carrier-Grade NAT (CGNAT)	Upstream provider NAT often seen in the 100.64.0.0/10 range.	A spoke WAN address of 100.75.10.25.
Point of Sale (POS)	Retail payment, scanner, or register systems that often need narrow application access.	A warehouse scanner or POS terminal reaching an office app server.
Network Video Recorder (NVR)	A recorder that stores camera video.	A remote admin may need HTTPS access to an NVR, but not to every camera.
User Interface (UI)	The screen or web page where an admin manages a system.	A router UI or UniFi admin UI.
UniFi Security Gateway (USG)	Ubiquiti’s older gateway line.	Legacy USG models are not supported for this Site Magic SD-WAN feature.
Internet Protocol version 6 (IPv6)	The newer Internet Protocol addressing system.	Ubiquiti FAQ guidance says IPv6 is not yet supported for Site Magic SD-WAN.
Frequently Asked Questions (FAQ)	A vendor’s common questions and answers section.	Ubiquiti FAQ guidance is useful for feature limitations.
Intrusion Detection System (IDS)	Security inspection that detects suspicious traffic.	A UniFi security feature that may log a suspicious flow.
Intrusion Prevention System (IPS)	Security inspection that can block suspicious traffic.	A UniFi security feature that may stop a flow even when routing is correct.

Official References

• Ubiquiti: UniFi Gateway - Setting Up SD-WAN with UniFi Site Manager and Fabrics
• Ubiquiti: UniFi Gateway - Introduction to VPNs
• Ubiquiti: Intro to Networking - Packet Routing Tables & Protocols
• Ubiquiti: UniFi Gateway - OSPF Advanced
• Ubiquiti: UniFi - Border Gateway Protocol (BGP)
• Ubiquiti: UniFi Gateway - Policy-Based Routing
• Ubiquiti: DNAT, SNAT, and Masquerading in UniFi
• Ubiquiti: Required Ports Reference

Final Thoughts

The clean Site Magic mindset is simple: advertise less, permit precisely, and test one path at a time. Do not treat the fabric as a magic flat network. Treat it as a managed routing fabric that still needs subnet discipline, firewall discipline, and DNS discipline.

Once that clicks, Site Magic becomes much less mysterious. A route advertisement says where a network lives. A route injection says the hub knows how to reach something beyond itself. A firewall rule says whether the conversation is allowed. A DNS record gives the destination a useful name. Keep those jobs separate in your head, and most Site Magic troubleshooting gets dramatically calmer.