WAN Failover: What Happens to Open Connections When the Line Switches

WAN failover switches to another internet connection after a fault. A usable route does not automatically preserve open connections. The externally visible addresses, router state, transport protocol and application recovery determine the outcome.

The typical case considered here is two independent uplinks with different public IPv4 addresses and NAT. NAT translates local addresses into the public address used on the internet. The router stores which internal connection belongs to each external address and port mapping. A design retaining a stable external address or using a suitable tunnel has different conditions. A claim that every session ends at the switch would therefore be incorrect.

Why an address change interrupts ordinary TCP

An ordinary TCP connection is identified by source and destination addresses and ports. If traffic is translated to a different public source address after failover, the server cannot treat that traffic as the original connection. A new route alone does not transfer TCP state to a new address.

The failure need not become visible at the exact switching instant. NAT state may initially remain pinned to WAN1; applications may wait for retransmissions or abort earlier through separate deadlines. If the original path returns in time with its state intact, a connection can resume. A normal switch to a different source address generally requires a new SSH or database connection.

Detection, route switching and application recovery

No formula based only on an interval and a failure count covers every router. A simple model can nevertheless be derived explicitly: probes start every I, each failed probe completes after T, and exactly N consecutive failures trigger the decision. Here T < I, and the last probe before the outage succeeded. d is the delay until the first probe starts after the outage; D is the detection time.

I = 5 s, T = 1 s, N = 3
0 <= d < I
D = d + (N - 1) * I + T

11 s <= D < 16 s
mean D = 13.5 s  (uniform d)

The average assumes that an outage is equally likely at any point between two probe starts. The calculation excludes the subsequent routing change and application recovery. A different definition of tolerated failures, packet-loss evaluation over a continuously moving time window, delayed evaluation or probes scheduled after previous completion changes the model. For example, pfSense also documents loss thresholds, evaluation periods and alert intervals.

What may continue

QUIC can associate packets with a connection through connection IDs. The new route must still work and undergo validation. Active migration requires a confirmed handshake and can be restricted; a NAT-induced address change needs separate consideration. HTTP/3 alone does not guarantee uninterrupted application behaviour.

A VPN must retain inner addresses and relevant state. Internet traffic through a remote VPN exit also needs a stable external mapping there. WireGuard supports roaming, while IKEv2 can use MOBIKE. If an interruption exceeds an inner application’s deadline, a stable address alone cannot preserve the application session.

Recovery without an unnecessary second interruption

Returning to WAN1 does not have to move existing connections off WAN2 immediately. A router can prefer WAN1 for new connections while existing WAN2 states expire naturally. Forced rerouting or state deletion can instead cause another interruption. The actual behaviour depends on configuration.

A recovery delay and separate failure/recovery criteria limit repeated switching. A fixed timer ratio is not a universal solution. Link stability, application requirements and state handling determine the appropriate policy.

A meaningful failover test

Monitoring traffic must demonstrably use the uplink being monitored. A responding modem does not prove internet reachability, and an unavailable monitoring target does not prove an uplink failure. Multiple suitable signals or targets can improve the decision where supported. pfSense specifies a different monitor IP for each gateway.

A planned test records the outage, gateway decision, successful new connection and recovery of ongoing applications separately. Recovery to the primary link, incoming calls and the actual protocols in use also belong in the test. Resumable downloads and backups reduce the consequences without promising survival for every session.