UniFi Site Magic SD-WAN: Setup, Routing, Security, and Operational Limits

Quick Answer

Use UniFi Site Magic hub-and-spoke when remote sites mainly need central services; use mesh only when direct peer traffic is required. Inventory every subnet first, advertise only required networks, and treat the tunnel as reachability rather than authorization. Validate one allowed flow, one denied flow, DNS, return routing, and a controlled failure before wider rollout. Site Magic does not provide universal multi-vendor SD-WAN, application authentication, or proven failover performance.

Scope and evidence: This guide is for authorized UniFi home-lab, small-office, and branch operators choosing or reviewing a Site Magic design. Product behavior and limits were rechecked against current Ubiquiti documentation on August 24, 2026. The operational tests and example output below are planned procedures, not TechGeeks lab results.

What Site Magic Does

Site Magic is UniFi's managed site-to-site Virtual Private Network (VPN) workflow. In Ubiquiti's current SD-WAN documentation, an operator selects a topology, sites, networks, routes, and WAN assignments in UniFi Site Manager; UniFi then builds the gateway-to-gateway fabric. It reduces manual tunnel plumbing, but routing, addressing, firewall policy, underlay health, identity, and recovery remain operator responsibilities.

That makes Site Magic a practical fit for a UniFi-based home lab, managed family network, shop, warehouse, or small branch estate. It is not a claim of feature parity with carrier-integrated or multi-vendor enterprise SD-WAN. If the requirement includes application-aware path steering, contractual service-level enforcement, third-party edge orchestration, or cloud-native gateway integration, evaluate those capabilities separately.

Choose the Topology Before Connecting Sites

Decision	Hub-and-Spoke	Mesh
Best fit	Branches consume services or egress through one or more central sites.	A small set of peer sites genuinely needs direct paths.
Current documented scale	Up to 1,000 tunnels, depending on hub model.	Up to 20 sites.
Failure shape	Single, failover, or distributed hubs; architecture can use one, two, or up to four active spoke-to-hub tunnels.	One active tunnel per site connection; Ubiquiti warns that failover tunnels need time to re-establish.
Overlap handling	Auto-Scale and NAT can translate overlapping spoke networks, with important initiation and identity limits.	NAT is unsupported; shared networks must not overlap.
Security default	Use spoke isolation where branch-to-branch access is unnecessary, then add narrow service policy.	Apply firewall policy at every site because peer paths increase lateral reachability.
Operational default	Preferred for most managed-family and small-business deployments.	Use only when the peer-to-peer requirement outweighs the larger policy surface.

Current Requirements and Ownership Boundaries

• A hub must be a currently supported Cloud Gateway or independent gateway and must have a public IP address.
• Spokes can be most Cloud Gateways except Express, or supported independent gateways managed by a CloudKey, UniFi OS Server, or Official UniFi Hosting.
• Hub-and-spoke currently requires UniFi Network Application 9.0.108 or newer and UniFi gateway version 4.1.3 or newer.
• Mesh supports current Cloud Gateways or supported independent gateways, requires at least one gateway with a public IP, is limited to 20 sites, and separately requires the same UI Account Owner on every participating gateway.
• Legacy USG models and IPv6 are not currently supported for this SD-WAN feature.
• UniFi OS Server supports Site Magic and Site Manager; the legacy UniFi Network Server does not provide the same Site Magic capability.

Ownership is a deployment gate, not paperwork. The current hub-and-spoke requirements say sites may share the same UI Account Owner or be managed in one Fabric by Fabric Admins. The Mesh requirements instead say every participating gateway must have the same UI Account Owner. On that same page, the FAQ says SD-WAN can be managed only by the Owner, while the ownership-transfer answer says participating consoles must have the same “admin.” Those statements leave delegated creation and recovery authority ambiguous. Do not translate “Fabric Admin” into “can manage SD-WAN”: verify the exact role in your Site Manager tenant, keep the Owner as the documented break-glass authority, and record the result before rollout. The FAQ also says an ownership transfer closes connections to the transferred site while other sites remain up.

Build an Address and Route Inventory

Do this before opening Settings > SD-WAN. Give every route an owner and purpose. Summarize only when the aggregate does not include a network that should remain private.

Site	Local subnet	Advertise?	Remote destination	Required service	Overlap	Owner / rollback
Hub	192.0.2.0/24	Yes	198.51.100.10	HTTPS/TCP 443	No	Network team / withdraw route
Spoke A	198.51.100.0/24	Yes	192.0.2.53	DNS/UDP+TCP 53	No	Site owner / remove spoke
Guest	203.0.113.0/24	No	None	None	No	Site owner / not shared

The addresses above are documentation ranges from RFC 5737. Replace them with your real inventory privately. Do not publish internal addresses, site names, public IPs, device identifiers, or ownership details in screenshots.

Configure Hub-and-Spoke or Mesh

Hub-and-Spoke

1. Open UniFi Site Manager and go to Settings > SD-WAN.
2. Select Hub & Spoke, name the group, and choose Single, Failover, or Distributed hub topology.
3. Choose Max Resiliency, Redundant, or Scalable spoke-to-hub architecture. Document the expected tunnel count and interruption behavior rather than assuming every mode is hitless.
4. Add hub sites, then advertise only the selected local networks or manually defined routes.
5. Assign the primary VPN WAN and optional failover WAN for each hub.
6. Add spokes, select their advertised networks, and set primary and failover WAN assignments.
7. Enable spoke isolation when branches should not communicate. Current Ubiquiti guidance says this auto-generates hub firewall rules and requires zone-based firewall availability.
8. Review overlap, routes, WAN assignments, firewall impact, and the rollback owner before applying.

Mesh

1. Open Settings > SD-WAN, select Mesh, and name the group.
2. Select no more than 20 sites.
3. Select only the networks that peers need to reach.
4. Confirm every shared subnet is unique. Mesh does not support the hub-and-spoke NAT overlap feature.
5. Apply the group, then validate routes, policy, and application traffic at every participating site.

Overlapping Subnets and NAT

Renumber when you control both sites. Hub-and-spoke Auto-Scale and NAT Spoke VPNs can make an overlapping spoke appear from a unique translated /24, but the convenience changes operations:

• The default behavior supports spoke-initiated sessions toward the hub.
• A hub cannot initiate toward a translated spoke resource unless a matching Destination NAT rule is created on that spoke.
• Each published spoke resource needs its own translation and documentation.
• Logs and server policy may identify the translated network instead of the original client.
• IP allowlists, DNS records, monitoring, packet captures, and incident response must all understand the translated address.

Ubiquiti's current example maps a translated address to a local server with a DNAT rule on the spoke. Treat that as a migration aid, not a reason to preserve uncontrolled duplicate addressing. Never use Protocol: All for a production service merely because a documentation example does; narrow the real rule to the protocol and port the application requires.

Security and Isolation Defaults

• Advertise only service networks. Exclude guest, IoT, camera, point-of-sale, and management networks unless a documented flow requires them.
• Use spoke isolation for hub-and-spoke designs without branch-to-branch traffic, then verify the generated policies.
• Apply least-privilege policy between the VPN, Internal, Gateway, and any custom zones. A route does not authorize a service.
• Keep gateway administration on a separate management path. Protect Owner and Fabric Admin identities with phishing-resistant multi-factor authentication and tested recovery.
• Require application authentication and endpoint firewalls. Network location must not become the only trust signal.
• Log configuration changes, VPN events, firewall denies, and WAN failures, but minimize fields and retention because flows reveal clients, sites, services, DNS activity, and behavior.

Validation: Prove the Path in Layers

Run from an authorized canary client and substitute your documented destination. The commands below are exact examples, but they were not performed by TechGeeks for this revision.

# Example commands - not performed by TechGeeks
ip route get 192.0.2.10
dig +short app.example.net
nc -vz -w 5 192.0.2.10 443
curl --fail --show-error --connect-timeout 5 https://app.example.net/health
tracepath -n 192.0.2.10

Example expected output (illustrative, not observed):

192.0.2.10 via 198.51.100.1 dev eth0 src 198.51.100.20
192.0.2.10
Connection to 192.0.2.10 443 port [tcp/https] succeeded!
healthy

The route lookup proves only the client's selected next hop. The TCP check proves a handshake, not application authorization. The HTTP response proves only the tested endpoint at that time. Pair client output with the SD-WAN tunnel state, gateway route or forwarding view, Traffic Flows, firewall rule-hit evidence, server log, and return-path check.

Test	Expected result	Evidence to retain	What it does not prove
Allowed client to allowed service	DNS, route, TCP, and application request succeed.	Client command/output, rule hit, flow, server log.	Other users, ports, or failure paths.
Guest or IoT to same service	Denied and logged.	Timed denial plus matching gateway log.	Every lateral path is blocked.
Allowed client to unexpected port	Denied and logged.	Port test and rule-hit evidence.	Endpoint firewall coverage.
WAN or hub interruption	Behavior matches chosen architecture; local management remains available.	UTC timeline, tunnel state, packet loss, session and failback status.	Carrier SLA or universal failover time.
Cloud control loss	Existing connection behavior is observed; configuration dependence is recorded.	Management and data-plane timeline.	Every cloud outage scenario.

Troubleshooting

• Site is absent from the group: Verify supported gateway, software minimums, online state, ownership, Fabric membership, and administrator role.
• Tunnel is green but traffic fails: Check advertised routes, local route selection, overlap, source and destination zones, rule order, return path, endpoint firewall, and service listener.
• IP works but name fails: Check which resolver the client uses, whether the record is reachable from that site, split-DNS scope, and both UDP and TCP port 53 where applicable.
• Small requests work but larger ones stall: Compare path maximum transmission unit (MTU), packet-too-big handling, encapsulation overhead, and underlay filtering. Do not lower MTU globally without evidence.
• Hub cannot reach a translated spoke host: Auto-Scale NAT is spoke-initiated by default. Verify the explicit DNAT mapping, destination, protocol, and spoke policy.
• Failover works but sessions reset: A restored route does not guarantee stateful session survival. Record whether the application reconnects and whether return-path symmetry changed.

Rollback and Recovery

1. Export current configurations and record UniFi Network, gateway, and client versions before the change.
2. Confirm local or out-of-band administration at every site. Do not make the new fabric the only recovery path.
3. Capture the current route, firewall, DNS, NAT, and WAN assignments.
4. Add one canary spoke and one service first.
5. If validation fails, disable the new custom policy or remove the canary from the SD-WAN group, then withdraw only the newly advertised routes.
6. Restore the recorded firewall and NAT state, confirm local internet and management, and retest the known-good path.
7. Do not transfer ownership during recovery unless that is the documented plan; current Ubiquiti guidance says ownership transfer closes that site's SD-WAN connections.

Hub Tunnel Capacity Reference

Ubiquiti's SD-WAN guide listed these hub capacities when rechecked on August 24, 2026. These are tunnel counts, not encrypted throughput, client sessions, or performance with inspection enabled.

Hub model	Listed SD-WAN VPN tunnels
Enterprise Firewall Core (EF Core)	1,000
Enterprise Fortress Gateway (EFG)	1,000
Gateway Enterprise (UXG Enterprise)	1,000
Dream Machine Beast (UDM Beast)	200
Dream Machine Pro Max (UDM Pro Max)	200
Dream Machine Special Edition (UDM SE)	100
Dream Machine Pro (UDM Pro)	100
Cloud Gateway Fiber (UCG Fiber)	100
Cloud Gateway Industrial (UCG Industrial)	100
Dream Wall (UDW)	100
Gateway Pro (UXG Pro)	100

Useful Gear and Buyer Notes

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

Buyer Scenario	Good Fit	Why This Pick	Amazon Affiliate Link
Small remote home	Cloud Gateway Ultra / UCG-Ultra	Compact spoke candidate for a small remote site. It is not in the current documented hub list, so verify current Site Magic eligibility, capacity, and software support before buying.	Amazon: UCG Ultra
Power home or small office	Cloud Gateway Max / UCG-Max	Compact spoke candidate for a busier remote site. It is not in the current documented hub list; verify current application, storage, performance, and Site Magic requirements separately.	Amazon: UCG Max No Storage
Rack homelab	Dream Machine Pro or UDM SE	Rack-mounted, full UniFi app suite, and useful as a small hub. Ubiquiti lists UDM Pro and UDM SE at 100 SD-WAN VPN tunnels in the hub capacity table. The linked Amazon result is a UDM Pro bundle, so verify seller and package contents before buying.	Amazon: UDM Pro bundle
Dual-WAN small business	Cloud Gateway Fiber, UDM SE, or UDM Pro Max	Use UCG Fiber when it fits the edge design; use UDM SE or UDM Pro Max when you want a rack console with the broader UniFi application stack.	Amazon: UCG Fiber
Many branches	UXG Enterprise or Enterprise Fortress Gateway	Prioritize hub tunnel capacity. Ubiquiti lists UXG Enterprise and EFG at 1,000 SD-WAN VPN tunnels. I did not find a reliable exact Amazon product page during this check.	Search Amazon: Enterprise UniFi gateway
Existing independent gateway design	UXG Pro	Useful when you want an independent gateway managed by CloudKey or Official UniFi Hosting. Ubiquiti lists UXG Pro at 100 SD-WAN VPN tunnels.	Amazon: UXG Pro
Accessories	Rack shelf, patch cables, UPS	Do not ignore the physical layer. Stable power and clean cabling matter more than another dashboard.	Search Amazon: UniFi rack shelf UPS patch cables

Security, Privacy, Legal, and Recovery Boundaries

• Security: Site Magic encrypts and routes inter-site traffic, but it does not replace least-privilege firewall policy, endpoint security, application authentication, monitoring, backups, or tested incident recovery.
• Privacy: UniFi cloud management, client records, flows, captures, DNS, and logs can identify people and locations. Use synthetic labels in published evidence and minimize access and retention.
• Legal: Connect, monitor, and impair only networks and traffic you are authorized to administer. Employee monitoring, regulated data, and cross-jurisdiction traffic may require policy or legal review.
• Recovery: Preserve exports, local administration, an independent access path, and explicit route, policy, NAT, and ownership rollback steps before changing production sites.

Limitations: What This Evidence Does Not Prove

• A green Site Magic connection proves control-plane state, not bidirectional application reachability, authorization, DNS, MTU, or return-path correctness.
• A route in a forwarding table proves eligibility, not that every packet used that route or replies followed a compatible path.
• A listed tunnel capacity does not prove throughput, session capacity, carrier availability, or acceptable gateway CPU under inspection.
• Ubiquiti's documented failover modes do not prove a specific interruption time or application-session survival in this network.
• This documentation-backed revision does not validate every gateway model, ownership transition, cloud outage, NAT overlap, or IPv4-to-IPv6 migration.

Evidence-Capture Checklist Before Publication

• Record gateway, UniFi OS, UniFi Network, and client versions; topology; synthetic subnets; WANs; policy hashes; and UTC start/end under artifacts/labs/ubiquiti-site-magic-unifi-sd-wan-guide/YYYY-MM-DD/.
• Capture the starting export and local management proof before creating the canary fabric.
• Capture current topology, advertised networks, isolation, NAT/overlap, WAN, and tunnel-health screens at a fixed viewport.
• Pair exact client commands with raw output, exit status, time, and artifact ID for one allowed service, denied source, denied port, DNS, and return-path test.
• Record one controlled WAN or hub failure, failback, packet loss, session behavior, and management reachability.
• If authorized, test overlapping subnets only in a disposable topology and compare NAT behavior with a renumbered control.
• Redact names, accounts, addresses, MACs, tokens, serials, notifications, and metadata; have a second reviewer inspect publishable derivatives at original resolution.

Related TechGeeks Resources

• UniFi Site Magic Firewall Rules: Least-Privilege Access Between Sites (staged companion article)
• Ubiquiti Site Magic Routing: Routes, Injection, and Fabric Design
• Homelab VLAN Design: Simple Network Segmentation That Works
• WireGuard Home VPN: Secure Remote Access for Your Homelab
• Networking Field Notes: Start Here
• Network Security Field Notes: Start Here

References

• Ubiquiti: Setting Up SD-WAN with UniFi Site Manager and Fabrics (rechecked August 24, 2026)
• Ubiquiti: Getting Started with UniFi Fabrics (rechecked August 24, 2026)
• Ubiquiti: Introduction to VPNs (rechecked August 24, 2026)
• Ubiquiti: Zone-Based Firewalls in UniFi (rechecked August 24, 2026)
• Ubiquiti: Self-Hosting UniFi (rechecked August 24, 2026)
• Ubiquiti: Introducing Network 10.5 (rechecked August 24, 2026)
• NIST SP 800-207: Zero Trust Architecture

Final Thought

Site Magic is strongest when it makes a deliberate design easier to operate. Choose topology from real traffic, keep addressing clean, advertise less, authorize narrowly, and prove failure and recovery with a canary. That produces a supportable UniFi fabric without mistaking a convenient tunnel workflow for a complete security or availability architecture.