Connect two sites with UniFi SD WAN

Outcome and prerequisites

Connect Site B to one permitted resource at Site A over a site-to-site tunnel. Use two supported UniFi gateways that appear under the same UI Account Owner in Site Manager. The worked example uses the Mesh topology, which requires at least one participating gateway to have a public IP address. Legacy USG models are excluded by the current documentation. IPv6 routing is not supported in the documented SD-WAN workflow. [1]

Use Site A Main 192.168.10.0/24 with an HTTPS resource at 192.168.10.150, and Site B Main 192.168.110.0/24. Neither subnet may overlap another participating local or remote route. The objective is access to that service, not unrestricted access to everything at both sites. Retain a local administrator connection at each location.

Procedure

  1. Confirm the resource at Site A works locally and record its actual protocol and port. At both sites, save backups and record WAN addresses, LAN ranges, gateway versions and ownership. Confirm that the documented public-IP requirement is met; the public address seen by a website alone does not prove that a gateway behind carrier-grade NAT has a directly usable public WAN address.
  2. Check for overlapping networks. If both sites currently use 192.168.1.0/24, plan a subnet change before creating this mesh. Review fixed client addresses, reservations, DNS and existing firewall rules. Ubiquiti's subnet-change procedure includes preparing DHCP leases and updating affected address-dependent settings. Make that a separate change with its own verification. [2]
  3. Before connecting sites, prepare the intended access policy. At Site A, allow new VPN traffic from Site B's 192.168.110.0/24 to 192.168.10.150 on TCP 443, with established and related responses allowed. Block other new sessions from that remote subnet to private Site A resources. Restrict the rule by remote source subnet, not every VPN user, so it does not accidentally alter unrelated remote-access permissions.
  4. At Site B, permit the corresponding outbound session to the Site A service and its responses. Add a rule blocking other new sessions from Site A's 192.168.10.0/24 into Site B's Main network, below any required exceptions and established-response rules. Check the destination server's own firewall and account permissions. Preserve VPN-to-Gateway control traffic used by SD-WAN; indiscriminately blocking it can leave a tunnel apparently connected while required routes are missing. [1]
  5. Open Site Manager at unifi.ui.com using the shared Owner account. In Site Manager Settings, open SD-WAN. Create a group named Example Two Sites, choose Mesh, select Site A and Site B, then select only the Main network at each location for sharing. Connect the group. The SD-WAN control is in Site Manager, so it may not appear where local gateway VPN-server settings are located. [1]
  6. Wait for both sites and their shared routes to appear healthy. From Site B, open the service using 192.168.10.150. Use the normal application credentials and certificate handling appropriate to the service. Then try a known live but unauthorised service at Site A; it should remain inaccessible.
  7. Test the reverse direction separately. If Site A should not initiate sessions into Site B, attempt a fresh connection to a live Site B test service and confirm it fails. Existing return packets for the permitted Site B session must still work. Document the distinction between responding to a permitted connection and initiating an unrelated one.
  8. Add name resolution only after address-based access succeeds. Use an existing managed DNS design, an appropriate local record, or a narrowly scoped forwarding arrangement. Confirm that the chosen resolver can reach any remote DNS server and that its address is not hidden behind the very policy you are testing. Avoid assuming that all local discovery broadcasts will cross a site-to-site tunnel. [3]

Mesh and hub and spoke choices

Mesh suits this two-site exercise. A larger deployment with central resources can use hub and spoke, with separate hardware, software and public-address prerequisites. Current documentation also describes Fabric administration for that topology, while some related account guidance remains Owner-focused. This walkthrough deliberately uses a common Owner to avoid relying on an ambiguous permission combination. Do not treat a mesh group as permission to connect third party gateways; the documented alternatives include supported IPsec and OpenVPN designs. [1]

Verification and recovery

Record tunnel status, the expected remote subnet, allowed service result, blocked service result and reverse-direction result. If the tunnel is connected but traffic fails, compare actual routes, source subnets, policy order and endpoint firewalls. If only names fail, test DNS independently. If performance disappoints, compare both sites' upload capacity and latency before changing firewall policy.

To remove the exercise, stop sharing the test networks or remove the test SD-WAN group in Site Manager, then remove its specific exceptions. Verify that remote private services are no longer reachable and both sites retain normal internet access. Preserve other site groups and local network settings.

Sources

Back to the series

Leave a comment

Please note, comments need to be approved before they are published.