Floating VPN backup route not taking over: failover checklist

Your floating VPN route is configured, the backup distance is higher than the primary, and nothing ever moves. Or it moves, then flips back minutes later while the wireless link is still down. In both cases something other than the failure you care about is deciding route eligibility.

Work these checks in order. Each one has a stop condition, and a failed check cannot be rescued by the ones after it. The examples use RouterOS syntax because distance, gateway reachability and recursive next hop are all visible in the config there, but the order applies to any router with tracked static routes.

Name the failure the backup has to cover

"The primary is down" is four different observations. A radio that loses its peer, an interface that drops its carrier, a remote gateway that stops answering, and an application that stops working all look different from the router's seat. Write down which one the design is for before anyone changes a distance value.

Then check independence. If the VPN's outer transport runs over the same wireless path, or over an access link that shares the same upstream, the backup is not a second failure domain and will be down exactly when you need it. Pull the primary cable on paper: if the tunnel's own transport dies with it, the floating route only covers configuration mistakes, not outages.

Stop asking distance to detect anything

A higher distance makes a route less preferred. That is the whole job. While the primary static route stays eligible, the floating route remains inactive, and that is correct behaviour rather than a bug. The failure becomes visible only when the primary is withdrawn or marked unreachable.

For static routes that requires an explicit tracker:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

Read what that tests: the next hop, not the destination. A radio that still answers on its local side while forwarding beyond it is broken keeps the primary route active. That is the silent case, and distance plus a gateway check will not catch it. If that case matters, detection has to come from something that observes the far side: a routing protocol adjacency, or a probe whose path and result rule you have defined yourself.

Trace where the probe's own packets go

A health probe has a route too. Once data traffic moves to the VPN, an unconstrained probe to the same remote address can follow it, succeed, and be read as proof that the primary recovered. Traffic returns to a broken path and the cycle repeats.

Pin the probe to the path it is supposed to judge. In RouterOS the usual way is a host route to the monitoring target through the primary gateway, with a scope small enough that no other route can resolve it, which is what the recursive failover example in the RouterOS manual builds. Confirm it on the live table with the backup active, not from the config comment:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Define what a probe result means before adding targets

One target that rejects ICMP or goes into maintenance looks exactly like a path failure, and three targets without a rule just give you three opinions. Decide the rule first, then implement it: for example, the primary counts as down when two of three targets fail for two consecutive intervals, written into the runbook where the next person will find it.

Set failure and recovery thresholds so one lost packet does not move the site. Hysteresis costs a little detection time and buys back stability. Pick the interval from how long an outage is tolerable, not from how fast the probe can run, and keep failback slower than failover so the primary has to prove itself before it gets traffic back.

Check the return path and the session story

Failover that only works outbound is half a design. The far site needs a route back to your source range over the VPN, or return traffic arrives from an unexpected address and hits firewall state that no longer matches. Existing sessions will break even when new connections work, so put that in the acceptance criteria instead of promising transfer survival.

Keep management access off the path being tested. If your only way in is through the primary, a failover test locks you out of the device that is misbehaving.

Run the acceptance sequence

Three tests cover most of the ground: physical primary loss, a silent forwarding failure with the interface still up, and primary restoration. For each, record the probe's source and next hop, the active destination route, and a fresh permitted application exchange in both directions.

The silent case is the one that separates designs. If the backup does not take over there, you have built a link monitor rather than a path monitor. Decide whether that is acceptable, and write the limitation where the on-call engineer will read it. A second connected tunnel is not, by itself, a finished backup policy.