Two IPsec Gateways, No Shared IP: What Failover Really Does

Kill gateway A during a meeting and watch the tunnel come back through B a minute later; the connection works, the video call may not. That is the honest shape of cold failover between two independently addressed IPsec gateways. The client reselects an endpoint and builds a new relationship, which restores reachability without transferring the old session's cryptographic state. Walking the sequence makes it obvious which promises the design can keep.

Set the scene: two addresses, no floating IP

Gateway A answers at one reachable address and gateway B at another. The client has an approved way to choose B when A is gone, and there is no shared outside address that both gateways claim. In this design, a virtual IP means that shared entry point, not the inner address assigned to a remote-access client.

That definition matters because the two ideas get mixed up in tickets, and the fix for one is not the fix for the other. A report that the shared entry did not follow the gateway describes one design. A report that the laptop lost its inner address describes the client's lease. Different owners, different logs, different repairs.

Walk the failure: detect, then reselect

First something notices that A stopped answering. That can be dead peer detection at the tunnel layer, a routing protocol withdrawing a path, or an application timeout that finally forces a reconnect. Each has a different timescale, and the slowest one usually determines how long users wait.

Then the client selects B through whatever mechanism the deployment supports: a second configured remote, a DNS name resolved to a healthy address, or routing that now prefers a different path. Selection is a policy step, and it has to exist before the failure or it will happen by accident.

What B can and cannot inherit

B can share a configuration template, a certificate authority and an authentication policy with A. It cannot inherit the live security associations. Session keys, security parameter indices and sequence state belong to the relationship that A and the client established, and B has none of them.

Moving that state between gateways is a real engineering problem, which is why the strongSwan high-availability documentation treats it as a cluster design rather than a configuration flag. A particular cluster recipe is not a generic answer for a cloud network, and copying it without the supporting infrastructure buys complexity instead of continuity.

Establishing a fresh relationship

With B selected, the client performs a new IKE exchange: new nonces, new Diffie-Hellman values, new identifiers for the resulting associations. Authentication happens again at B. If the design relies on machine credentials, the reconnect can be unattended; if it requires a human factor, someone has to be present for the failover to complete.

Define that user experience before the outage, not during it. Say plainly what the client will do, how long it will try and what it will show when it gives up, because the difference between a minute of reconnect and a support call is usually documentation and a tested profile.

Preserving the same inner address helps applications that expect a stable local identity, and it does not preserve their sessions. NAT bindings expire, TCP connections reset and anything with a timeout of its own decides independently whether to retry.

Two tunnels in parallel are a different design

Running both tunnels at once is a valid pattern when both gateways and the routing design support it. Route selection then chooses the active path, and the return path has to agree, or traffic leaves through one gateway and comes back through the other with no state to match it.

Overlapping tunnel policies do not create orderly failover by themselves. They create two candidates, and something has to decide between them deterministically, whether that is a routing metric, a policy priority or an explicit preference in the client.

Whatever shape you choose, write the contract down: how failure is detected, how the alternate is selected, what authentication the alternate requires and how long the reconnection is expected to take. A shared IP can simplify discovery, but it is not a synonym for continuous state, and availability is a design either way.