VPN failover: when the return path stays on the old tunnel

The backup tunnel comes up, the primary goes down, and the application still times out. On both sites the tunnel status looks healthy, which is what makes this confusing. A failover that moves requests to the backup but leaves replies on the old path is not a failover. The runbook below tests the return path, not just the handshake.

Record routes at both ends first; a single-site view cannot show an asymmetric path. It is also the step most often skipped under time pressure.

Record both sites' routes before the test

For each protected prefix, write the primary route, the backup route and the preference that selects between them. Include the LAN gateway behind each VPN endpoint, because the endpoint is rarely the last hop.

Static metrics, tracked routes and dynamic routing all express eligibility differently. Know which one your design uses, and what it takes for the alternate to become active. Write the condition next to the route, for example a lower metric until the probe fails.

Do this at both sites. A backup that is preferred on one side and ignored on the other produces exactly the asymmetry you are trying to avoid.

Watch requests and replies in each phase

Use a harmless permitted application and observe three phases: normal, primary failure, and restoration. In each phase, record which tunnel carries the request and which carries the reply. A reachable peer address does not prove the protected application path works. Capture at both sites so a one-way flow is visible.

If requests move and replies do not, check the remote site's route to the client prefix and its preference for the backup. That is a routing decision, not a tunnel failure.

Restore the original condition after the test and confirm the primary is preferred again. A restored primary that is not preferred is a failover design that has not finished.

Handle session state when the gateway changes

Firewalls and NAT can hold connection state on one gateway, and a path change to another gateway does not carry it. Some applications reconnect on their own; others fail until the session is reestablished. If the backup changes the public source or the translated private address, remote access rules may react as well. Document any expected session restart instead of promising interruption-free failover.

Keep stable addressing where the application requires it. A failover design that changes the source address for every session is a design choice, and it should be written down. That choice determines how much of the outage users actually notice.

Test an application that holds a long session, not only a new request.

Restore the primary and check for flapping

Confirm that route advertisements or preferences settle without oscillating. A flapping primary can be more disruptive than a clear outage, because every transition resets state.

Keep gateway administration reachable through a recovery path so the test itself does not lock you out. Record the phases, the observed paths and the recovery time; that record is what makes the next failover predictable. The strongSwan forwarding notes are useful when the endpoints are Linux hosts.