How to Set Up UniFi VPN Remote Access: WireGuard or Teleport

If you are working out how to set up UniFi VPN remote access, the decision tree is short. Phones and non-technical users behind any kind of NAT: use Teleport. Laptops, always-on access, or anything you want under your own control: run the built-in WireGuard server on your gateway. L2TP: no. Ubiquiti’s own documentation now recommends Teleport or WireGuard and notes that L2TP is losing operating-system support and misbehaves behind NAT.

All of this requires a UniFi gateway. A UDM Pro, UDM SE, Dream Router, UCG-Ultra, or a UXG in front of your switches all qualify; a Cloud Key managing third-party routing does not run a VPN server. If you are still choosing hardware, the gateway selection guide covers which console fits which WAN.

If you administer several networks, plan the controller and access path for each using UniFi remote management across multiple sites.

Pick the protocol before you touch the UI

UniFi’s VPN overview splits the feature into three things people constantly confuse:

• VPN Server: remote clients dial into your network. Protocols: WireGuard, OpenVPN, L2TP, plus Teleport. This is what “remote access” means and what this guide covers.
• VPN Client: your gateway routes outbound traffic through someone else’s VPN endpoint (up to 8 client profiles, WireGuard or OpenVPN). This does not let you in from outside.
• Site-to-Site: two networks joined permanently (OpenVPN, IPsec, or Site Magic between UniFi gateways). Overkill for reaching your NAS from a hotel.

Within the server options, WireGuard is the default answer. Per Ubiquiti it delivers higher throughput than traditional VPNs such as L2TP, and the WireGuard project itself is a deliberately small, modern codebase with public-key authentication instead of shared secrets. That small attack surface matters more than it used to: enterprise SSL-VPN appliances have spent the last few years as a headline generator for exploited edge-device CVEs, a pattern you can watch roll by on techsentinel.news. A UDP-only protocol that does not even answer unauthenticated packets is a materially quieter thing to expose.

OpenVPN remains available for clients that cannot run WireGuard, typically locked-down corporate laptops. It works; it is just slower and heavier to configure.

Setting up the WireGuard VPN server

The server lives in the Network application under Settings, VPN, VPN Server. The flow, per Ubiquiti’s WireGuard article:

1. Enable WireGuard and accept or change the listen port. The default is UDP 51820. There is no reason to move it unless your ISP mangles that port; obscurity buys you nothing on a protocol that silently drops unauthenticated traffic.
2. Check the tunnel subnet. The wizard pre-fills one. Make sure it does not overlap any VLAN you already run, and ideally not the 192.168.0.0/24 and 192.168.1.0/24 ranges either, because that is what every hotel and coffee-shop network hands out and an overlapping remote LAN breaks routing in ways that look like “VPN connects but nothing loads.”
3. Add a client. Each client gets its own keypair and its own config. Do not share one profile across devices; per-device profiles mean you can revoke a lost laptop without re-keying everything.
4. Export the config. Desktop clients import the .conf file into the official WireGuard app; on mobile you scan the QR code straight from the UniFi console. Client installers for every mainstream OS are on wireguard.com.
5. Set client DNS to your gateway’s LAN IP (for example 192.168.1.1) if you want internal hostnames and any local DNS filtering to keep working remotely. Leave the default full-tunnel AllowedIPs of 0.0.0.0/0 if you want all traffic through home; narrow it to your internal subnets (say 192.168.10.0/24, 192.168.20.0/24) for split tunnel.

One design note: remote VPN clients land on your network with the access the tunnel subnet’s firewall rules give them. If you have followed the IoT and guest segmentation model, treat the VPN subnet as another zone and write explicit allow rules to the VLANs it actually needs, rather than letting it default to everything.

The NAT question decides everything

This is where most “UniFi VPN won’t connect” threads end up. Ubiquiti’s remote access guide is blunt about it: every VPN server option except Teleport needs a public IP on your gateway’s WAN.

• Gateway holds a public IP directly: nothing to do. The gateway opens its own WAN port when you enable the server.
• Double NAT (ISP router in front of your UniFi gateway): forward UDP 51820 on the upstream router to the UniFi gateway’s WAN address. Ubiquiti warns that upstream forwarding problems are a common cause of VPN disconnects, and recommends putting the gateway on a public IP where possible, for example by bridging the ISP device.
• CGNAT (WAN address in 100.64.0.0/10, common on 5G and some fiber ISPs): inbound is dead. No port forward will save you. Your options are paying the ISP for a real public IP, relaying through a cheap VPS you control, or using Teleport, which is the one UniFi option built for exactly this.

A dynamic-but-public IP is fine; use the console’s DDNS support or a hostname you update, and put that hostname in the client config’s endpoint field instead of the raw IP.

Teleport when you do not want to manage keys

Teleport is Ubiquiti’s one-click server: WireGuard underneath, with key exchange and connectivity brokered through Ubiquiti’s cloud, driven from the WiFiman app on iOS and Android. You enable it on the console, send an invitation from WiFiman, and the remote device is in. No port forwarding, no public IP requirement, no config files.

The trade-offs are real but acceptable for the use case: it depends on Ubiquiti’s cloud for session setup, it is tied to the WiFiman app rather than the standard WireGuard client, and you give up the per-client subnet and DNS control the manual server offers. For a family member’s phone, that is the right trade. For your own laptop, run the real WireGuard server and keep both enabled; UniFi runs them side by side without conflict.

Things to test before you call it done

Test from an outside network. From your own LAN or Wi-Fi you are testing hairpin behavior, not remote access. Tether to a phone, then:

ping 192.168.1.1              # your gateway's LAN IP through the tunnel
dig @192.168.1.1 nas.internal # internal DNS resolution via the tunnel
mtr 192.168.10.20             # path to a host on another VLAN, checks firewall rules
iperf3 -c 192.168.10.20       # throughput to an iperf3 server on the LAN

In the WireGuard client, confirm “latest handshake” updates and transfer counters move in both directions; a handshake with zero received bytes means your AllowedIPs or the return route is wrong. Then power-cycle the gateway once and verify the tunnel comes back without help, because the first time you actually need remote access is always the week nobody is home to fix it.

Related across the network

• OPNsense WireGuard Road Warrior: Remote Access Setup — opnsenselab.com
• How to Set Up WireGuard VPN on pfSense: Step-by-Step Guide — pfsenselab.com
• Best Homelab Firewall in 2026: OPNsense, pfSense, UniFi, MikroTik — firewallcompare.com
• How to Set Up WireGuard on OPNsense: Road Warrior, Site-to-Site — firewallcompare.com
• UniFi Dream Machine Pro vs pfSense: Hardware and Cost — firewallcompare.com
• VPN vs Tor vs Proxy: What Actually Protects Your Privacy — anonguide.com
• Cloudflare Access vs Tailscale: Architecture Compared — cloudflarezerotrust.org