How does automatic failover to a backup link work?

Automatic failover to a backup link works only when the router checks actual reachability beyond the local network, removes the failed path from routing, and sends new connections through the second WAN. Two cables in a router and two default route entries do not provide redundancy by themselves.

This design has an awkward property: a green interface indicator often survives an ISP outage, while an active TCP session usually does not survive a change of public address. You therefore need to design four separate processes rather than an abstract backup: failure detection, route replacement, address translation replacement, and application recovery. I have configured many pairs of links and have usually found the fault not in route syntax, but in a bad answer to one question: what exactly counts as a failure?

Redundancy starts with a failure model

List the failures the design must handle first, because the router sees each one differently. A broken Ethernet cable or loss of optical signal puts an interface down, but a frozen CPE, a damaged route inside the carrier network, a DNS failure, and heavy packet loss can leave the link up.

It helps to separate monitoring into layers. Physical port state answers only whether the neighboring device is connected. A gateway check shows whether the ISP's nearest router is reachable. A probe to a remote address confirms that the packet passed beyond the access network. A DNS, HTTPS, or business service check measures whether the link is fit for a specific job.

Check separately whether the two links really terminate on independent equipment. One managed switch in front of the router, a shared media converter, or a single power supply can disable both WANs at once even though the diagram shows two providers. Cost may justify that layout, but nobody should present it as protection from failure of the shared part. Name the shared component in the risk register and decide whether it needs a second instance.

Different access technologies do not guarantee different physical paths either. Fiber and radio can meet at one aggregation site, and two carriers can lease the same backbone. An engineer will not always obtain a complete map of the carrier network, but can ask for separate building entries, different points of presence, and a description of the last mile. A simultaneous failure test remains the only convincing check of those assumptions.

For a normal office or branch, a sensible objective is to move outbound traffic when the primary link cannot reach several independent external nodes consistently, and to return it only after stable recovery. This does not make the edge router itself highly available. If the only router loses power, both providers become useless. Protecting against that event requires two edge devices, state synchronization or a coordinated first-hop design, separate power, and a failure test for each device.

Write down the limits of the promise before configuring anything. A backup link can preserve the ability to open new external connections, but it does not have to preserve an active video call, VPN tunnel, or file transfer. It also does not automatically restore inbound published services when the second carrier supplies a different address and external clients continue to contact the first one.

One ping checks the wrong link condition

Checking only the ISP gateway is insufficient because the gateway can answer while the network beyond it is unavailable. Checking one popular public address is also poor practice because its owner may rate-limit ICMP, the route to it can change, and a local failure of that host can make a healthy WAN look dead.

Choose at least two targets outside each provider's access network. They should respond predictably, use a strictly defined WAN, and not depend on a single carrier or autonomous system. If the router permits it, combine the results so loss of one target raises a warning while loss of all targets removes the link from service. A rigid rule that any failed probe means a dead WAN turns a brief problem at one destination into a switch for the entire organization.

Pin the route to every monitoring target to the provider under test. Otherwise, after the primary WAN fails, its probe will leave through the backup, receive a reply, and incorrectly declare the primary path healthy. In the log, this loop looks like continuous movement back and forth. With recursive static routing, individual host routes through each carrier gateway create the pinning. On systems with policy routing, a rule for the monitoring source or process does the same job.

ICMP shows basic IP reachability, but it does not measure application quality. Add packet loss and latency thresholds for voice or terminal access if the platform can calculate them over a monitoring window. Netgate's Multi-WAN documentation explicitly distinguishes complete failure, high latency, and packet loss events. That distinction is useful: a link with 20 percent loss is technically alive while users can no longer work properly. Derive a threshold from measurements of a healthy link and application requirements, not from someone else's configuration.

Timers must filter flapping without hiding failure

Failover time is the sum of the probe interval, the number or window of failed checks, the state change delay, route recalculation, and application reconnection. A promise of failover in one second means nothing if it was measured only by the appearance of a backup default route while the browser held the old TCP session for another minute.

Use different conditions for leaving and returning. A few consecutive errors or a threshold breach in a short window is usually enough to leave the primary link. Return should be slower: the primary must demonstrate stable operation before users move back. Cisco object tracking provides separate delay down and delay up values for this purpose, and most firewalls and SD-WAN devices offer similar settings or automation.

For example, a probe every 3 seconds, failure after 3 missed replies, and a 5-second down delay produce a theoretical detection time of about 11 to 14 seconds, depending on when the break occurs. Route installation, state removal, and the application's retry come afterward. This is a calculated estimate, not a guaranteed figure. Measure it on your own device under a realistic load.

Do not push intervals to their minimum for an attractive metric. A short timeout on a mobile, microwave, or congested link creates false failures. An excessively long window is harmful too because users will report the outage before monitoring does. A good configuration records isolated losses in telemetry but changes the route only after sustained degradation.

Routing, NAT, and policy must move together

After the system confirms a failure, the backup default route must become active, while outbound NAT and firewall rules must allow the same traffic through the second WAN. A common failure looks like this: the routing table is correct, a packet leaves through the backup interface with a private source address, and the carrier drops it because the masquerade or source NAT rule exists only for the first interface.

Inspect more than the main routing table. Policy routing for guest networks, voice, VPNs, server segments, and traffic from the router itself may refer to a specific gateway. A static route to corporate DNS or the main office can also bypass the new default route. If the backup is not intended for every system, explicitly end excluded policies with a reject rule so traffic does not leak through an accidental path.

The backup link needs its own outbound translations, allow rules, and, where needed, a smaller MSS for tunnels. DNS clients must be able to reach a resolver through either path. Services on the firewall itself, including NTP, updates, a VPN client, and log forwarding, sometimes use a separate table or interface binding, so a test from a user's laptop does not prove that they work.

Do not confuse failover with load balancing. With failover, every new connection uses the first-priority link while it remains usable. With balancing, the system distributes connections between two working WANs. Sending individual packets from one session through different providers is almost always a mistake: different delays and public addresses disrupt packet order and remote-side checks. If you need to use the capacity of both links, distribute whole connections and pin sensitive destinations to one exit.

Existing connections need not survive an ISP change

With ordinary IPv4 NAT, active connections usually break because the backup provider assigns a different public address. The remote server sees the new four-part combination of addresses and ports as a different connection, while packets from the old session either do not arrive or do not match NAT and firewall state.

RFC 4116 states the result without marketing qualifications: transport sessions generally do not survive a rehoming event in NAT multihoming, but new sessions can be created after the path changes. That is the honest expectation for two consumer or business access links that use provider-assigned addresses. A browser usually retries a request and a messenger reconnects, while SSH, RDP, a SIP call, a long upload, and some VPN tunnels notice the interruption.

The state table determines how long a client clings to the dead path. If old state entries remain, an application may wait for a TCP timeout even though the backup route is already active. If states are cleared, the client creates a connection through the second WAN sooner, but the administrator deliberately terminates every matching session. The pfSense documentation therefore offers a choice between keeping states, selectively clearing states for the failed gateway, and flushing the whole table. The last option can disrupt unrelated traffic.

I prefer selective clearing of failed-WAN states after a confirmed outage. A voice gateway or persistent tunnel can also use a separate watchdog that restarts registration or the tunnel if the application recovers too slowly by itself. A session can survive only when both paths use one reachable public prefix and Internet routing moves it between providers, or when a tunnel over both access links leads to a common egress point. That is a different architecture involving BGP, PI addressing, a carrier service, or an external concentrator.

Inbound traffic follows separate failover rules

Backing up outbound access does not make a published server reachable through the second provider. An external client continues to contact the first carrier's address, and a DNAT rule on the backup interface cannot intercept a packet that never arrives there.

For a noncritical publication, you can assign a second address and change DNS during an outage, but delay depends on resolver caching, TTL, record update speed, and application behavior. Existing connections still use the old address. IPsec with a peer address in DNS can also take a noticeable time to recover while both sides refresh the name and rebuild the tunnel.

If an inbound service must retain its address, discuss BGP and a provider-independent prefix with the carriers, or place a public ingress point with a fixed address outside the site. The second option sends traffic to the site over one of two tunnels. It introduces dependency on the external point, whose capacity, latency, and own redundancy must be tested.

The return path must also be symmetric. A packet that enters WAN2 must receive its reply through WAN2, or source filtering at the carrier and a stateful firewall may drop it. Policy routing based on the incoming interface, separate tables, and correct source NAT solve this problem. Test published services from a real external network, not from the LAN through hairpin NAT.

A working configuration is visible in the route table

This RouterOS 7 example demonstrates recursive checking rather than providing a ready-made template. Replace the gateways and monitoring addresses, verify table names, and run the commands in a lab first. MikroTik's WAN Backup documentation uses the same method: a host route pins an external probe to a provider, while the default route recursively depends on the probe's reachability.

/ip route
add dst-address=1.1.1.1/32 gateway=192.0.2.1 scope=10 comment=probe-isp1-a
add dst-address=9.9.9.9/32 gateway=192.0.2.1 scope=10 comment=probe-isp1-b
add dst-address=8.8.8.8/32 gateway=198.51.100.1 scope=10 comment=probe-isp2-a
add dst-address=208.67.222.222/32 gateway=198.51.100.1 scope=10 comment=probe-isp2-b
add dst-address=0.0.0.0/0 gateway=1.1.1.1,9.9.9.9 distance=1 target-scope=11 check-gateway=ping comment=default-isp1
add dst-address=0.0.0.0/0 gateway=8.8.8.8,208.67.222.222 distance=2 target-scope=11 check-gateway=ping comment=default-isp2

The addresses 192.0.2.1 and 198.51.100.1 come from documentation ranges and must be replaced with real next hops on a production network. Two gateways in each default route create multiple recursive next hops. Confirm the behavior of your RouterOS version before deployment. The required logic keeps the primary route available while at least one target replies and removes it only after both targets fail.

After configuration, /routing/route/print detail where dst-address=0.0.0.0/0 should show the primary route as active and the backup as a candidate with a higher distance. During an outage, the primary route's recursive next hops become unreachable, the primary default route becomes inactive, and the route with distance=2 becomes active. At the same time, inspect NAT counters, the selected outbound interface, and the test client's external address. An active route flag without passing traffic proves only half of the design.

Equipment from another vendor still uses the same dependency graph: a probe is pinned to a WAN, a track object receives the result, the primary default route depends on that track, the backup has a worse metric, and NAT plus policies exist for both exits. Do not copy syntax between platforms. Copy the testable causal relationship.

Testing must break the network above the physical port

An acceptance test must reproduce every claimed failure and measure the result at application level. Pulling the cable is useful, but it is the easiest case: the interface drops immediately and the more advanced reachability check does no work at all.

1. Start a continuous ping, short HTTPS requests, a long download, an SSH or RDP session, and a test call. Capture timestamps for routing, NAT, and monitoring events at the same time.
2. Block the monitoring targets through the primary WAN above the local gateway, or temporarily create a blackhole at the carrier in a test environment. Confirm that losing one target does not remove the link while losing all of them transfers traffic.
3. Leave the link up but block ordinary Internet traffic. This exposes a check that accidentally leaves through the backup or measures only the gateway.
4. Restore the primary path briefly and break it again. The route must not flap, and delay up must keep users on the backup until recovery remains stable.
5. Repeat the test for inbound publications, VPNs, DNS, voice, and services on the router itself. Record old-session interruption separately from the time of the first successful new connection.

The report should contain timestamps for the last successful probe, declaration of WAN failure, active route replacement, the first packet with the new public address, and the first successful application action. A debate about whether failover was fast then becomes a set of measurable intervals. Record traffic that intentionally cannot use the backup as well, such as backups or updates when the second plan has limited speed or data.

Do not conduct the first full test during business hours without a maintenance window and a rollback path. Disable automatic return first, verify a manual move, then enable detection and only afterward enable failback. In an infrastructure project, GSE can connect server and network components, link independence, and round-the-clock support in one design, but acceptance criteria must still belong to the customer and reflect its applications.

Returning to the primary link is more dangerous than leaving it

Automatic failback often creates a second unplanned interruption: users are already working through WAN2, then the recovered WAN1 takes the route back and changes the public address again. If the primary carrier repeatedly rises and falls, the network will break sessions at each event unless the design has hysteresis.

Set a longer up delay than down, and check link quality after recovery. During sensitive shifts or operations, a manual return in an agreed maintenance window may be better. That is controlled management of the second impact. Automatic failover protects users from an ongoing outage, while automatic failback only restores the preferred price or capacity.

Decide whether to clear backup-WAN states on return. If they remain, existing connections can finish over WAN2 and new ones can use WAN1, provided that the platform retains each state's gateway binding. Clearing them immediately makes the return faster and more visible. Keeping active states is usually better for calls and transactions, but the router must hold both paths correctly during the transition.

After every incident, compare actual time with the target and identify the stage that delayed recovery. If the route changed in 12 seconds but the VPN returned after 90, tuning the probe will fix nothing. Investigate IKE timers, DNS, registration, or the behavior of the specific client.

Backup capacity needs policy protection

A backup link must carry critical traffic during an outage, but buying an exact copy of the primary plan is not always necessary. Start by measuring production load by traffic class, then decide which applications must continue, which may slow down, and which should stop until WAN1 recovers. Average consumption is useless for this calculation because an outage can coincide with a workday peak, backup job, video meeting, or mass file synchronization.

Create a bandwidth budget for voice, terminal access, payment operations, the corporate VPN, and infrastructure DNS and NTP. Add room for protocol overhead and brief bursts. Then limit or block operating system updates, synchronization of large cloud folders, guest Wi-Fi, and off-site backups over WAN2 if they can displace production applications. Priority without a limit on an aggressive class often fails because large flows have already filled the queue and the bottleneck sits at the carrier, where your router cannot control transmission.

Shape outbound speed slightly below the backup connection's measured capacity. The queue then stays on your device, where voice and interactive traffic can receive predictable service. Control is weaker in the inbound direction, so limit recipients locally, agree on a carrier profile, or reduce application intensity. Test quality at full load. An idle link almost always shows attractive latency that disappears after one large upload.

A backup over LTE or another metered service needs separate protection from an unexpected bill. Set usage warnings, block heavy categories, and make sure the link has not become primary because someone forgot about an outage. If the carrier uses CGNAT, ordinary outbound connections may work while inbound publications and some tunnels do not. Establish this service property before an incident, not during one.

Edge device performance also changes when the second WAN is active. NAT, tunnel encryption, state tracking, queueing, and detailed logging consume CPU and memory. Test the router at the required throughput with security rules enabled instead of relying on port speed in a specification. If the backup is slower than expected, identify the limit first: the service plan, radio signal, duplex, MTU, CPU, queue, and remote VPN gateway require different corrections.

Finally, the policy must preserve management access to the network itself. Administrator access, monitoring, logs, and DNS must not accidentally fall into an unimportant traffic class and disappear under congestion. Reserve a small guaranteed share for them and verify that an engineer can reach the equipment over an independent path. A backup that works only while nobody needs to diagnose it has failed acceptance.

Treat the backup as a production link

A WAN that sits unused for months quietly stops being a backup: the gateway address changes, billing expires, the carrier replaces its CPE, a NAT rule remains from an older design, or capacity no longer fits new applications. An external-address probe catches some of these failures, but it does not confirm actual throughput or access to every service.

Run a controlled switch on a schedule and keep users on the second link long enough to expose DNS, VPN, published services, plan limits, and asymmetric routing. Monitoring must show each WAN separately, the active default route, latency, loss, the number of switches, and the reason for every event. An alert that the site is on backup is needed immediately even when users notice nothing, because the next failure will leave the site without external access.

Keep a diagram that shows physical paths. Two contracts do not provide independence if both entries share one splice enclosure, city backbone, CPE, rack, or power source. Ask carriers about the last mile and building entries, then confirm the answer by inspection and testing. Failure testing, not logos on contracts, proves technical independence.

A design is ready when the team can explain and reproduce every state: why the WAN was declared failed, which route won, which NAT rule applied, which sessions broke, how applications recovered, and when return is allowed. If only the person who once configured the router can answer those questions, the redundancy already has a single point of failure.