UniFi Policy-Based Routing: Sending Specific Devices or Domains Out a Chosen WAN or VPN

Do you know which WAN, or which tunnel, a given device on your network actually leaves through? On a single-WAN UniFi gateway the answer is simple — everything follows the default route — but the moment a second ISP or a WireGuard client tunnel enters the picture, that answer decides whether a streaming box sees the right region, whether a work laptop reaches its corporate resources, and whether a backup job saturates the wrong link.

UniFi Network's policy-based routing, labeled Traffic Routes in earlier releases and Policy-Based Routes in current ones, makes that answer explicit. You choose a source, a destination, and an egress interface, and the gateway steers matching traffic out that path instead of the default route.

This guide covers how those policies are built, how route order and matching decide which rule wins, how WireGuard client tunnels plug in, and how everything interacts with the dual-WAN modes covered in our gateway WAN failover guide. Keep in mind that menu labels have moved between Network application releases, so treat the paths below as descriptions of the current generation rather than permanent addresses.

Conventional routing looks at only one thing: the destination address of a packet. The gateway checks its routing table, finds the most specific matching route, and sends the packet out the interface tied to that route — which, for anything on the internet, is the default route through your primary WAN.

Policy-based routing adds criteria in front of that lookup. Under the hood, UniFi OS relies on the Linux policy-routing machinery — packet marks, rule priorities, and separate routing tables — but the Network application wraps all of that in a single form with four parts:

• Source. The devices the policy applies to, selected as individual clients, entire networks (VLANs), or every client behind the gateway. Client selection follows the device's record in the Network application, so it holds even when a DHCP lease changes.
• Destination. What the traffic is headed to — a list of domains, a list of IP addresses or subnets, a country or region, or all internet traffic.
• Interface. Where matching traffic exits: a specific WAN port, or a VPN client tunnel you have already configured on the gateway.
• Kill switch. An option that blocks matching traffic outright when the chosen interface is unavailable, rather than letting it fall back to the default route.

All of these combine into a single statement the gateway enforces: traffic from this source, headed to this destination, leaves through this interface. What's more, everything a policy does not match continues to use the normal routing table untouched, which is why a well-scoped policy has no effect on the rest of the network.

Typical uses include but are not limited to:

• Region-specific streaming. Sending one streaming device's traffic through a WireGuard tunnel that terminates in another country.
• Work-from-home separation. Pinning a corporate laptop to the secondary WAN so personal traffic on the primary line never competes with its video calls.
• Session-sensitive sites. Forcing banking or SaaS domains that bind a session to a source IP onto one WAN when the gateway is load balancing.
• Data-capped backup links. Keeping bulk traffic such as cloud backups pinned to the primary WAN, with the kill switch on, so it never drains a cellular backup plan during failover.

Note that a device's private (randomized) Wi-Fi address matters here. If a phone or laptop rotates to a new MAC address, the Network application sees a new client and a device-scoped policy quietly stops applying — so disable address rotation on any device you intend to route individually.

Overlapping policies are where most configurations go wrong. For instance, if one policy sends an entire IoT network out WAN2 and a second sends a single camera on that network through a WireGuard tunnel, the gateway has to resolve which rule that camera's traffic follows.

Policy routes are evaluated before the main routing table, which means a policy match overrides a static route or the default route for the same destination. Among policies themselves, recent Network releases present routing policies as an ordered list, and where your release exposes that ordering, it is what breaks ties when two policies match the same traffic.

Rather than relying on precedence you have not verified, keep overlapping rules to a minimum. Here's how to structure them so the outcome stays predictable:

• Narrow before broad. Place device-scoped or domain-scoped policies above network-wide or all-traffic policies, so the specific case is evaluated first.
• One intent per policy. A policy that mixes ten unrelated domains is hard to debug, while separate policies per service make the list self-documenting.
• Name policies by outcome. A label such as Living Room TV via WG-Amsterdam tells the next administrator what the rule does without opening it.
• Recheck after upgrades. Network application updates have migrated and renamed routing features before, so confirm the list after every major release.

Domain-based destinations deserve particular attention, because the gateway cannot read a domain name inside an encrypted connection. Instead, it watches DNS responses passing through it, records the IP addresses each listed domain resolves to, and routes traffic headed to those addresses.

This is why domain policies depend on clients using the gateway, or a resolver that forwards through it, for DNS. Devices that hardcode a public resolver, browsers with DNS over HTTPS enabled, and apps that resolve over their own encrypted channels all bypass that lookup, so the gateway never learns the addresses and the traffic falls through to the default route — the same bypass problem that affects DNS filtering on UniFi.

Be aware of two further side effects. First, services behind a shared CDN may resolve to the same addresses as unrelated sites, so those sites follow the policy too; second, a client that cached a domain's address before the policy existed will connect without a fresh lookup, so flush the client's DNS cache or wait out the record's TTL before testing.

Similarly, connections that were already open when you saved a policy generally keep their original path until they close, so restart the app or device under test rather than judging the policy by a session that predates it.

A WireGuard client on a UniFi gateway is an outbound tunnel: the gateway dials a remote WireGuard server, whether that is a commercial provider such as Mullvad or Proton VPN, a self-hosted server on a VPS, or a peer at another site. You create it under the VPN Client section of the gateway's VPN settings, usually by uploading the provider's .conf file, which carries the private key, the peer's public key, the endpoint, and the tunnel addresses.

Remember that in current releases, creating the client does not on its own send any LAN traffic through it. The tunnel comes up as an available interface, and a policy route is what decides which devices or destinations actually use it.

Several details in the configuration affect how the tunnel behaves once traffic flows:

• MTU. WireGuard adds roughly 60 bytes of overhead per packet over IPv4 and 80 bytes over IPv6, which is why 1420 is the common default. If your WAN uses PPPoE, which already subtracts 8 bytes from the standard 1500, lowering the tunnel MTU further avoids fragmentation and the stalled page loads it causes.
• Persistent keepalive. A keepalive interval, commonly 25 seconds, keeps NAT mappings open on any upstream device and helps the tunnel recover quickly after a WAN change.
• DNS. Clients on your network still query whatever DNS server DHCP hands them, typically the gateway, which resolves over its normal upstream path. If DNS privacy matters for the routed devices, hand them the provider's resolver through that network's DHCP settings so their lookups travel inside the tunnel with everything else.

Throughput is the other planning factor. WireGuard encryption runs on the gateway's CPU, and tunnel throughput on entry-level models can land below their routed WAN rating, so check Ubiquiti's published specifications before routing an entire network through one; our guide on how to choose a UniFi gateway explains how to size hardware around CPU-bound features.

Finally, keep outbound client tunnels distinct from inbound access. A WireGuard VPN server, Teleport, or Site Magic lets you reach your network from outside, a separate topic covered in our UniFi remote access guide and the Home Assistant remote access walkthrough.

If your gateway sits behind an ISP router, the outbound client generally works without any port forwarding, since the gateway initiates the connection. That said, the double NAT guide explains why inbound services in the same topology need more work.

A UniFi gateway with two WANs runs in one of two broad modes: failover, where the secondary WAN carries traffic only when the primary is down, or load balancing, where new connections are distributed across both links by weight. Policy routes sit on top of either mode, and a policy that names a specific WAN pins matching traffic to that port regardless of how the rest of the network is being distributed.

The interesting behavior appears when the pinned interface fails. Accordingly, the kill switch setting is the most consequential decision in any policy that targets a WAN or tunnel, and the table below summarizes the typical outcomes:

Scenario	Kill switch off	Kill switch on
Policy pins traffic to WAN2 and WAN2 goes down	Traffic falls back to the default route on the healthy WAN	Matching traffic is blocked until WAN2 recovers
Policy uses a WireGuard tunnel and the tunnel drops	Traffic leaves unencrypted through the active WAN	Matching traffic is blocked until the tunnel re-establishes
Primary WAN fails while a tunnel policy is active	The tunnel typically re-forms over the backup WAN and traffic resumes after the handshake	Same outcome, with traffic held back during the gap
Policy pins bulk traffic to WAN1 during a WAN1 outage	Bulk traffic shifts to the backup link, including metered cellular	Bulk traffic stops, protecting the backup plan's data allowance

That last row is the cleanest argument for the kill switch on cost-sensitive links. If your failover path is a UniFi LTE or 5G backup with a data cap, pinning backups, offsite camera uploads, and game downloads to the primary WAN with the kill switch enabled keeps them from consuming the plan the moment the primary drops.

Tunnels also interact with failover in a less obvious way. The WireGuard client reaches its endpoint through whichever WAN currently holds the default route, so a failover changes the tunnel's public source address; WireGuard handles this roaming natively, because the server updates the peer's endpoint from the next authenticated packet, and a persistent keepalive ensures that packet arrives promptly.

Load balancing introduces its own wrinkle. Sites that bind a login session to a source IP — some banks, payroll portals, and admin consoles — can log users out when consecutive connections leave through different WANs, and a domain-based policy pinning those services to one WAN is the direct fix.

Once the WAN or tunnel exists, building the policy itself takes only a few minutes. Here's the sequence we follow on a fresh configuration:

1. Confirm the interface is healthy. Check that the second WAN shows as online, or that the WireGuard client shows a recent handshake, before routing anything into it.
2. Decide on the source scope. For more than a handful of devices, a dedicated VLAN is cleaner than a long client list, and our UniFi VLANs explainer covers how to carve one out.
3. Create the policy. In the routing section of the gateway's settings, add a policy-based route, choose the source, destination type, and interface, and enable the kill switch if leaking to the default WAN is unacceptable.
4. Order it. Place the new policy above any broader policy it overlaps with, then save.
5. Test from the client. Load a what-is-my-IP page on the routed device and on a non-routed device, and confirm they report different public addresses.

Testing should go further than a single page load. A traceroute from the routed device should show the expected ISP or tunnel peer immediately beyond the gateway; a DNS leak test confirms whether lookups follow the same path; and a quick check that local resources — a printer, a NAS, a Home Assistant host on an IoT VLAN — remain reachable proves the policy is not capturing inter-VLAN traffic.

Keep in mind that routing and firewalling are separate layers. A policy route decides where permitted traffic exits, while zone-based firewall policies still decide whether that traffic is allowed at all, so a device that loses internet access after a routing change may simply be hitting a block rule you forgot about.

If you are planning a second WAN or an always-on tunnel and still choosing hardware, start with CPU headroom for WireGuard and enough WAN-capable ports for the topology you want. Our UniFi gateway lineup lays out the current options, and the WAN failover guide pairs with this one for the failover half of the design.