Two Active IPsec Tunnels Still Need a Return Path Plan

Open a terminal on a workstation at one site and connect to a server at the other. That single TCP conversation now has to cross four gateways instead of two, and the interesting part is not whether it works on a good day. The interesting part is which gateway pair the forward direction picked, which pair the reply picks, and who is holding state for the flow while that happens. Nothing in the routing table decides that for you.

Draw four gateways before you draw a route

A dual-active design with two independent VPN firewalls per site, one pair per ISP, gives you two usable paths and three ways to break them. Write down the addresses before you configure anything: the client as seen before and after each gateway, the server likewise, the forward next hop, and the reverse next hop.

That table is the design. Everything after it is a question of whether the devices agree with the table.

How the forward path gets chosen

An equal-cost multipath routing layer distributes flows across next hops by hashing header fields, which RFC 2992 describes in detail. That selection can be entirely stateless: it needs no connection-tracking entry, only a stable hash over unchanged fields. Keep the path set and the hash inputs constant and every packet of the flow chooses the same next hop.

Per-flow selection avoids the reordering that packet-by-packet balancing would cause across links with different delays. It does not promise that equal routing cost means equal measured latency, because it does not. And when path membership changes, flows remap, so connection survival during a failure is a separate requirement from path selection.

What the return path actually needs

Here the walkthrough stops being symmetrical. A stable forward hash tells you nothing about what the far site will do with the reply. If an independent firewall must see both directions of the connection to maintain useful state, a return route that bypasses it leaves traffic matching nothing at all. Two boxes with similar rule sets are not shared state.

Confirm the implemented bidirectional behaviour, or write explicit policy that keeps the required boundaries coherent. A guess here gets discovered during an outage, by people who are not enjoying it.

Where translation decides for you

NAT is the other lever, and it is optional rather than required. Path-specific translated identities can steer replies back to the gateway holding the state, which is a legitimate design. They also add mappings, reverse routes and an owner for that state, so accept the burden only for a requirement you can name out loud.

If the requirement is simply that both paths carry traffic and either one survives an ISP loss, plain per-flow multipath with coherent return routing is usually the smaller design.

Walk the acceptance in order

Test in this sequence and record the addresses at each step: a fresh connection on path A and its reply path, the same on path B, then loss of one ISP, then restoration. For each result, note which established flows moved, which had to reconnect, and where new flows went afterwards. Write the expected value down first, then compare it against the capture. Two established tunnels prove none of it.

The design is finished when the table you wrote matches what the capture shows, not when both tunnels are up.