UniFi Gateway Failover and WAN Redundancy Explained

What happens to your network the moment your primary internet circuit goes dark? If the honest answer is that everything behind your UniFi gateway simply stops — VoIP handsets, cameras, point-of-sale, remote-access sessions, all of it — then you are running a single point of failure that a backhoe, a fiber cut, or a routine ISP maintenance window can take out without warning.

Dual-WAN failover exists to turn that hard outage into a brief, recoverable interruption, and UniFi gateways handle the mechanics natively once you understand how they decide to switch. This is an explainer for the reader who already knows what a default route is and wants to know precisely how UniFi's failover and load balancing behave in production.

The payoff is straightforward: a properly configured second circuit turns a dead primary into a brief interruption instead of an afternoon of downtime. The cost is a handful of behaviors you have to design around, which is what the rest of this guide is about.

We will walk through how the gateway treats WAN1 and WAN2, what actually trips a failover, the real difference between failover-only and load balancing, how to configure and test it, and the gotchas that catch nearly everyone the first time. If you are still choosing hardware, the companion guide to choosing a UniFi gateway covers which models even have the ports to do this.

Every UniFi dual-WAN setup rests on one idea: one circuit is the primary path to the internet, and the second exists to carry traffic when the primary cannot. You define both under Settings → Internet in the UniFi Network application, where WAN1 and WAN2 each map to a physical, WAN-capable port on the gateway.

That hardware requirement is the first gate, because dual-WAN needs two ports that can actually act as WAN. The UDM Pro, UDM Pro Max, UDM SE, and UXG-Pro ship with a dedicated WAN2 — typically an RJ45 plus an SFP/SFP+ port you can assign — while smaller Cloud Gateways such as the UCG-Ultra let you reassign a LAN port to WAN2 in recent UniFi Network firmware.

Each WAN is configured independently, so WAN2 can be DHCP, a static handoff, or PPPoE regardless of what the primary uses. This matters when your backup is a different technology entirely, such as a cable modem sitting behind your fiber or an LTE gateway behind both.

Once both circuits are defined, you choose how they cooperate — failover-only or load balancing — and everything else stays put. Your VLAN segmentation, firewall rules, and internal routing are untouched by a WAN switch, because dual-WAN only changes how packets leave the building, not how they move inside it.

The gateway will only move traffic to WAN2 when it believes WAN1 has failed, and it reaches that conclusion in two very different ways. The fast, unambiguous case is loss of carrier: the physical link drops, the port goes down, and the gateway knows instantly that the circuit is gone.

The harder case is the soft failure, where the link stays up but the path to the internet is broken — the ISP's upstream is down, or the handoff is live yet routing nothing. For this, UniFi runs a continuous connectivity probe against upstream targets, and only when that probe fails consistently does the gateway declare WAN1 down and switch.

That detection window is why failover is not instant. There is a short interval while the probe confirms the primary is genuinely dead rather than briefly flapping, and any in-flight session stalls during that gap before traffic resumes on WAN2.

The choice of probe target matters more than people expect. A connectivity check aimed at something that lives on the primary ISP's own network can mask a real outage or, worse, trigger a phantom failover when that single target hiccups.

By default, UniFi failback is preemptive. The moment WAN1 passes its health check again, the gateway restores it as the primary route — usually what you want, though it does mean a second, smaller disruption as sessions that settled onto WAN2 get moved back.

This is also where a marginal primary circuit bites. If WAN1 keeps dropping and recovering, preemptive failback will bounce you back to it each time it looks healthy, producing a ping-pong that is often more disruptive than simply staying on the backup.

The two modes solve different problems, and picking the wrong one is the most common dual-WAN mistake. Failover-only is pure redundancy: WAN2 does nothing until WAN1 fails, then carries everything until the primary returns.

Load balancing, by contrast, uses both circuits at once, distributing sessions across them by a weight you set — for example, a 3:1 split that sends most flows over your faster fiber and the remainder over a secondary line. The critical detail is that this distribution is per-session, not per-packet, which drives the single most misunderstood behavior in the whole feature.

Here is how the trade-off breaks down in practice:

• Failover-only. WAN2 stays idle and consumes no bandwidth until the primary drops, which makes it the right choice for any backup that is slower, metered, or capped — an LTE modem being the classic example. Nothing rides the backup until you actually need it.
• Load balancing. Both circuits carry traffic continuously, raising your aggregate throughput across many simultaneous connections and keeping both lines warm. The catch is that a single connection — one large download, one nightly backup upload — is pinned to one WAN and can never exceed that circuit's speed on its own.

This is why load balancing does not add your two speeds together. Two 500 Mbps lines do not give a single transfer 1 Gbps; they give you two independent 500 Mbps paths that many users and sessions can fill in parallel.

For an LTE or otherwise metered backup, failover-only is almost always the correct answer, because balancing would spend money and data on a link you only ever wanted as insurance.

Configuration follows the mental model directly. First, physically connect the second circuit and assign its port as WAN2 under Settings → Internet — on gateways where WAN2 is a reassignable LAN port, you designate that role here before the port will accept an uplink.

Next, define the WAN2 connection itself as DHCP, static, or PPPoE, exactly as you would the primary. Then choose the load type — failover-only or load balancing — and, if you are balancing, set the distribution weight to reflect the real capacity of each line rather than an even split that overloads the weaker one.

Set the failover priority so the gateway knows which circuit is primary, and confirm the connectivity-check target is something reliably reachable and independent of your primary ISP. A probe pointed at a flaky target will cause false failovers, flapping you between WANs for no reason.

One provider-specific trap is worth flagging: some ISPs bind service to the MAC address of the first device they see, so a modem moved from an old router onto the UniFi WAN port may hand out a dead lease until you reboot the modem or clone the expected MAC. Handle that on WAN2 the same way you would on WAN1.

Finally, think about the ports and cabling feeding all of this. If you are running a second handoff into an SFP+ port or rearranging the switch that uplinks the gateway, the UniFi switch selection guide covers the port-speed and uplink side of the equation.

A failover you have never exercised is a failover you do not really have. The most reliable test is also the bluntest: physically unplug the primary WAN and watch what happens in the UniFi Network dashboard.

You should see WAN1 flip to a failed state, traffic move to WAN2, and — once you reconnect the primary — preemptive failback restore WAN1 as the default route. Time this switch so you know roughly how long users lose connectivity, because that window is the real-world cost of every failover event.

Beyond the manual test, keep an eye on the gateway's WAN status and the connectivity-check history over time. Repeated, brief failovers usually point to a marginal primary circuit or a poorly chosen probe target rather than a genuine outage, and catching that pattern early saves you from chasing phantom problems.

It is also worth documenting the expected behavior for whoever runs the network next. Note which circuit is primary, what the failover target is, and what a legitimate failover looks like in the dashboard, so a real event is not mistaken for a fault.

Dual-WAN is dependable once configured, but it fails in predictable ways worth internalizing before you rely on it. The first is that stateful sessions do not survive a switch.

When traffic moves from WAN1 to WAN2, the source public IP changes, so anything tracking connection state resets — active VoIP calls drop, SSH sessions die, and site-to-site or client VPN tunnels tear down and re-establish on the new path. Failover protects your connectivity; it does not preserve your individual live sessions.

The second gotcha is specific to load balancing. Because sessions are spread across two different public IPs, services that pin a login to a source address get confused, so users hit repeated reCAPTCHA challenges, banking sites log them out mid-task, and some SaaS tools flag the shifting IP as suspicious.

Third, watch the backup link's cost and quality. An LTE failover left in load-balancing mode will quietly burn metered data every day, and asymmetric speeds mean a slice of your traffic silently rides the slower line even when the primary is perfectly healthy.

Fourth, remember that not every gateway can do this at all. A single-WAN device has one internet port, so if redundancy is a hard requirement, confirm the second WAN capability on the datasheet before you buy rather than discovering the limit mid-outage.

Redundant internet is one of the highest-leverage upgrades you can make to a UniFi network, and the gateway you choose decides whether it is even on the table. If you are speccing hardware with failover in mind, browse the UniFi gateway lineup for models that carry a true second WAN port, then pair the decision with the gateway selection guide to match the platform to your throughput and redundancy needs.