UniFi Remote Access: Teleport vs Site Magic vs WireGuard

Have you opened the VPN section on a new UniFi gateway lately and found three different remote-access options staring back at you? Teleport, Site Magic, and a hand-built WireGuard server all live in roughly the same corner of the UniFi Network application, all move packets over WireGuard, and all look like they answer the same question.

They answer three different ones. One is a per-device tunnel you hand out by invitation, one is gateway-to-gateway infrastructure between sites you already control, and one is a server you configure yourself because you need to own the ports, the peers, and the routes.

The cost of choosing wrong is rarely immediate. It surfaces a month later, when a branch link needs a human to press a button before the point-of-sale terminal can reach the server, or when a laptop in a hotel cannot see the NAS because nothing in that tunnel advertises the subnet the NAS lives on.

What follows is what each path actually does, how routing and DNS behave inside it, which gateways support what, and how to make the call in ten minutes instead of over a weekend of trial and error.

Start with the shape of the connection, because that one distinction eliminates two of the three options in most deployments. The options are:

• Teleport is client-to-site. A phone, laptop, or tablet running the WiFiman app connects into one network, and the tunnel exists only while that device is connected.
• Site Magic is site-to-site. Two or more UniFi gateways build tunnels to each other and route whole subnets, with no client software on any endpoint and no user action after the initial setup.
• Manual WireGuard or OpenVPN can be either. You stand up a server on the gateway and define peers yourself, which covers remote clients, third-party firewalls, and cloud endpoints that Site Magic will not talk to.

Ask one question first: does the thing that needs access have a person attached to it? If a human presses connect, you want Teleport or a manual WireGuard peer; if a rack of equipment needs a route that is simply always there, you want Site Magic or a manual site-to-site tunnel.

The second question is who owns the far end. Site Magic only federates gateways inside your own UniFi account, so an IPsec tunnel to a client's Fortinet or a WireGuard peer on a cloud VPC falls to the manual path by definition.

Keep in mind that these are not mutually exclusive. A typical multi-site deployment runs Site Magic between offices for the always-on routes and Teleport on top of it for the administrator who needs to log in from an airport.

Teleport is the one-click option, and for its actual job it is very hard to beat. You generate an invitation link in the UniFi Network application, send it to a person, and they open it on a device running WiFiman — the configuration lands in the app and the tunnel comes up.

There is no port forward to create, no peer key to exchange, and no certificate to distribute. Ubiquiti's cloud brokers the connection, which is why Teleport usually survives a WAN that a hand-built WireGuard server cannot, including many double-NAT and carrier-grade NAT situations where the gateway holds no publicly routable address.

That convenience buys a specific set of constraints. Teleport is full-tunnel: once connected, the device's traffic egresses through your gateway's WAN, so the remote user picks up your public IP and your gateway's upload ceiling for everything, not only for internal destinations.

For an administrator on hotel Wi-Fi that is a feature, since the same tunnel also gets them off an untrusted network. For a video call from a home office three time zones away, it is added latency on every packet, whether the destination is your file server or a public site.

Teleport clients land in their own address pool, separate from your VLANs, and current UniFi OS releases treat them as a VPN zone in the zone-based firewall. That matters: the zone policy governs what a connected Teleport device can reach, so if you have segmented your network the way our UniFi VLANs guide lays out, a Teleport client hits those same policies rather than bypassing them.

Client management stays in the console. Connected and previously invited devices are listed there, and revoking one cuts that device off without disturbing anyone else's access.

Where Teleport falls down is anything permanent. Invitations are tied to a person and a device rather than to infrastructure, the connection is initiated by the client, and no server-side mechanism brings a branch office back online at 3 a.m. after a power blip.

Past a handful of users, Teleport also starts to strain administratively. Ubiquiti's answer at that scale is UniFi Identity Enterprise, which layers per-user identity, SSO, and provisioning over the same style of tunnel — that is a licensing decision rather than a checkbox in the Network application.

Reach for Teleport when you need occasional administrative access, you are supporting a small set of named people, the WAN has no static address, and you would rather not maintain peer configurations by hand.

Site Magic is UniFi's automated site-to-site VPN, configured from the UniFi Site Manager rather than from inside a single console. You pick the sites, pick which networks each site advertises, choose a topology, and the gateways negotiate WireGuard tunnels among themselves.

The appeal is that it removes the part of site-to-site VPN that consumes the afternoon: matching proposals at both ends, remembering which side initiates, and hand-writing static routes twice. Add a VLAN to a site later and you publish it into the mesh from the same screen.

Both topologies have real use cases. Full mesh gives every site a direct path to every other site, which is what you want when branches talk to each other; hub-and-spoke forces traffic through a designated site, which is what you want when a filtering appliance, an inspection point, or a compliance boundary lives at headquarters.

Site Magic routes rather than bridges, and in a mesh it does not NAT between sites. Ubiquiti is explicit about the mesh limit: NAT is unsupported, so overlapping subnets cannot exist inside the group. Two sites both using 192.168.1.0/24 leave no valid routing table, and the tunnel comes up while traffic goes nowhere useful.

Hub-and-spoke is the exception, and it is worth knowing before you renumber a site. Enabling Auto-Scale and NAT Spoke VPNs applies a source NAT rule that translates each spoke into its own /24 before routing it to the hub, so overlapping spokes can coexist.

The trade is direction. Sessions can then only be initiated by the spoke, and a resource on the spoke stays unreachable until you add a destination NAT rule for it by hand. Where more than a few resources need exposing, Ubiquiti's own recommendation is to design the subnets so they do not overlap.

Plan your addressing before you build the mesh rather than after. Give every site a distinct block, use a per-site third octet as the low-effort convention, and keep the scheme documented somewhere other than in the head of the person who set it up.

WAN changes are handled for you, which is a large share of the value. Because the gateways coordinate through your UniFi account instead of through static peer addresses, a site whose ISP rotates its address re-establishes its tunnels without anyone editing a configuration file.

Bandwidth, however, is still bounded by the slowest link in the path. A mesh does not create capacity, so a site on a thin upload will bottleneck every flow that traverses it — size that circuit for the traffic you actually intend to push across it.

Be aware that Site Magic is a closed system. Every endpoint must be a supported UniFi gateway adopted into your account, so a third-party firewall, a cloud network, or a client-owned appliance still requires the manual configuration described next.

The manual options are what remains when Teleport is too ephemeral and Site Magic is too closed. Current UniFi OS gateways expose a native WireGuard server, a legacy OpenVPN server, and IPsec for site-to-site work with non-UniFi endpoints.

WireGuard is the default choice among these. You define the listen port, the server's tunnel subnet, and a peer entry per device, and the gateway generates a configuration file or QR code that the official WireGuard client on any platform can import.

The per-peer AllowedIPs field is the knob Teleport does not give you. Set it to your internal ranges and you get a split tunnel where only internal traffic crosses; set it to 0.0.0.0/0 and you get full-tunnel behavior identical to Teleport, chosen deliberately rather than imposed on you.

The trade is reachability. A self-hosted WireGuard server listens on the WAN, which means it needs a routable public address and usually an explicit forward — behind CGNAT it will not work at all without an external relay or a jump host.

A dynamic WAN address is survivable but needs handling. Point peers at a hostname backed by dynamic DNS instead of a literal IP, and confirm the record actually updates when the ISP rotates the lease, particularly if your gateway is switching between two circuits in the pattern covered in our gateway WAN failover guide.

The same implementation also runs in reverse. A UniFi gateway can act as a WireGuard client into a provider or a cloud network, and policy-based routing then decides which internal networks or individual clients egress through that tunnel instead of the WAN.

OpenVPN remains present on many consoles, and it earns its place in exactly two situations: a device or appliance that speaks nothing else, or a network path that blocks UDP and forces you onto TCP 443. Otherwise WireGuard wins on handshake time, roaming behavior, and CPU cost per megabit.

L2TP/IPsec is the last resort. It still ships, it still works with the VPN clients built into Windows and macOS, and it is the option to pick only when installing any client software is off the table.

One performance note applies to all of them. VPN throughput on UniFi gateways is CPU-bound, and the hardware offload that carries a gateway to line-rate NAT does not apply to tunnel encryption — check the model's published VPN figure on its datasheet rather than assuming your WAN speed carries into the tunnel, since that is one of the specs worth weighing when choosing a UniFi gateway in the first place.

Every one of these paths gets blamed for problems that are actually routing, DNS, MTU, or firewall policy. Four behaviors account for most of the support threads.

Multicast does not cross the tunnel. mDNS and Bonjour discovery are link-local by design, so a remote client on Teleport or WireGuard will not see AirPlay targets, Chromecasts, network printers, or HomeKit accessories in a device picker even when the underlying IP connectivity is perfectly fine.

The workaround is to stop relying on discovery. Reach those devices by IP address or by a DNS name you control, and treat anything that only advertises itself over multicast as unavailable remotely.

DNS is configured separately from routing. A tunnel can route your internal traffic correctly while the client still asks a coffee-shop resolver about an internal hostname and gets nothing back.

Teleport pushes the gateway as the resolver, so internal names generally work. On a manual WireGuard peer you must populate the DNS field in the client configuration, and on Site Magic there is no cross-site resolution at all — each gateway serves its own clients, so multi-site name resolution needs a central DNS server or conditional forwarders pointed across the mesh.

MTU is the quiet failure. Tunnels add header overhead, so a path that works for pings and SSH sessions can stall on large transfers when packets need fragmenting and something upstream silently drops them.

The symptom is distinctive: small requests succeed, large ones hang partway. Lower the tunnel MTU in the client configuration until transfers complete, and expect to go lower than the default on a PPPoE WAN, which has already surrendered bytes to its own encapsulation.

Firewall policy still applies. On zone-based firewall releases, VPN clients arrive in a VPN zone with its own policies toward your internal zones, and a tightly segmented network will block the tunnel exactly as you designed it to.

Test the specific thing you need before declaring the VPN broken. Ping a host by IP, then by name, then hit the actual service port — the layer that fails tells you whether you are looking at routing, DNS, MTU, or policy.

The support matrix follows the firmware generation more than the price tier. The dividing line is UniFi OS.

• UniFi OS consoles and gateways. The Dream Machine family, the Dream Router, the UXG line, and the Cloud Gateway models support Teleport, Site Magic, and the native WireGuard server, subject to running a current UniFi OS and Network release.
• The legacy USG and USG-Pro-4. These support none of the three, since they predate UniFi OS and are limited to the older remote-user options — which is on its own a reasonable argument for replacing them.
• Feature availability tracks firmware, not only hardware. Site Magic and the WireGuard server each arrived in specific UniFi OS and Network versions, so a console parked on an old release will not show them regardless of model.

Update the console before concluding that a gateway lacks a feature. The options appear in the interface only once both UniFi OS and the Network application are current, and the UniFi gateway lineup in our gear section is the faster way to confirm which generation a given model belongs to.

Then choose by the shape of the requirement rather than by whichever option appears first in the menu:

• A person needs access occasionally. Teleport, unless you specifically need a split tunnel or per-user identity.
• Sites you own need permanent routes. Site Magic, after you have de-conflicted the subnets.
• The far end is not a UniFi gateway, or you need control over ports, routes, and peers. Manual WireGuard, with IPsec for third-party firewalls and OpenVPN only when something on the far end demands it.

One more note on ordering. Get the gateway generation and the subnet plan right first, because both Site Magic and any future site-to-site work depend on unique addressing, and re-numbering a production network is far more disruptive than choosing well the first time.

Most networks end up running two of the three, and that is the correct outcome rather than a sign of over-engineering. Site Magic carries the infrastructure, Teleport or a WireGuard peer carries the humans, and each one does the job it was actually built for.