Make Route-Based IPsec Resilient with Two Internet Connections

A second internet connection doesn’t automatically make an IPsec tunnel redundant. Reliable failover requires a separate route-based connection for each link, a separately addressed XFRM interface, and a monitored routing path. Only then can Sophos Firewall deliberately switch traffic from ISP1 to ISP2 and return to the preferred path after recovery.

This workflow covers route-based any-to-any IPsec between two Sophos firewalls. Policy-based tunnels and route-based tunnels with specific Traffic Selectors use an IPsec failover group instead.

Quick procedure

1. Validate one any-to-any tunnel over ISP1 and one over ISP2 separately on both firewalls.
2. Assign a unique transfer address to each of the four XFRM interfaces.
3. Create a monitored gateway for both peer XFRM addresses on each firewall.
4. Add two static routes to the same remote LAN: primary with a lower and backup with a higher Administrative Distance.
5. Record the global Route Precedence and set it to static vpn sdwan_policyroute only if it fits the overall design.
6. Verify firewall rules and return paths for both XFRM paths.
7. Interrupt ISP1 in a controlled manner, test actual application traffic through ISP2, and then validate failback to ISP1.

⚠️ Route Precedence applies to the entire firewall. A change can also affect existing Static, VPN, and SD-WAN paths. First record the current value and all overlapping routes, create a configuration backup, and verify an independent management path.

Design and prerequisites

Understand the failover model

The two IPsec connections remain separate tunnels. The route with the lower Administrative Distance is the preferred data path. If its monitored XFRM gateway is considered unreachable, the route through the second tunnel can take over.

These are two separate states:

• The tunnel is active: IKE and Child SA have been established.
• The path is usable: The gateway, route, firewall rule, NAT expectation, peer, and return path work for actual traffic.

A green tunnel alone is therefore not proof of failover. Ordinary WAN failover isn’t sufficient either: WAN link manager doesn’t create a second IPsec connection or a matching route on the peer.

Any-to-any doesn’t use an additional VPN failover group. Addressed XFRM interfaces, gateways, and routes select the path. Set up a site-to-site IPsec VPN explains the complete basic configuration of such a tunnel.

Plan the example topology

The example connects a head office to a branch office:

• Head office: 172.16.16.0/24
• Branch office: 192.168.10.0/24
• Primary: ISP1
• Backup: ISP2
• ISP1 XFRM network: 10.255.1.0/30
• ISP2 XFRM network: 10.255.2.0/30

Head office 172.16.16.0/24                 Branch office 192.168.10.0/24

       xfrm-ISP1 10.255.1.1  ⇄  10.255.1.2 xfrm-ISP1     AD 1
Firewall HQ                                                   Firewall BO
       xfrm-ISP2 10.255.2.1  ⇄  10.255.2.2 xfrm-ISP2     AD 2

The addresses are documentation values and must be replaced with dedicated, non-overlapping transfer networks. Each XFRM pair needs a separate network. The public ISP addresses, Local and Remote IDs, profiles, and Listening Interfaces must match the peer for each tunnel.

Configure tunnels, gateways, and routes

Prepare two tunnels

Create two connections under Site-to-site VPN > IPsec on each firewall. Both use Route-based (Tunnel interface) and Any for Local subnet and Remote subnet. In a typical head-office and branch-office design, the head office uses Respond only and the branch office uses Initiate the connection.

The first tunnel uses the ISP1 WAN interface and the second uses the ISP2 WAN interface. Test both connections individually before configuring failover. Enable only the intended tunnel each time and test a defined data flow in both directions.

Under Network > Interfaces, assign these example addresses to the automatically created XFRM interfaces:

• Head office: 10.255.1.1/30 for ISP1 and 10.255.2.1/30 for ISP2
• Branch office: 10.255.1.2/30 for ISP1 and 10.255.2.2/30 for ISP2

Don’t readdress an XFRM interface while other routes or services depend on it. Check Object usage, tunnel status, and existing routing objects before every change.

Monitor XFRM gateways

Under Routing > Gateways, create one gateway per tunnel to the peer XFRM address on each side. At the head office, these are 10.255.1.2 and 10.255.2.2; at the branch office, 10.255.1.1 and 10.255.2.1.

Select the corresponding XFRM as the Interface. If the complete downstream path must be assessed, the Monitoring Target should be a stable and permitted endpoint behind the peer. A ping to the peer XFRM address only proves the immediate tunnel segment.

Choosing the target is an operational decision: It must respond reliably, must not disappear during normal maintenance, and requires the appropriate access. Create and test a custom gateway explains the health check, status, and stop conditions in detail.

Add static primary and backup routes

At the head office, add two IPv4 unicast routes to branch network 192.168.10.0/24 under Routing > Static routes:

• through 10.255.1.2 and the ISP1 XFRM with Administrative distance 1
• through 10.255.2.2 and the ISP2 XFRM with Administrative distance 2

At the branch office, add two mirrored routes to head-office network 172.16.16.0/24:

• through 10.255.1.1 and the ISP1 XFRM with Administrative distance 1
• through 10.255.2.1 and the ISP2 XFRM with Administrative distance 2

The lower Administrative Distance wins while its gateway is available. Identical destination networks and different distances therefore form the primary and backup paths. This is different from ECMP with equal priorities. Set up and test a static route explains the general route and return-path logic.

Set Route Precedence carefully

Sophos documents this design with Static ahead of VPN and SD-WAN. First record the existing state in the Device Console:

system route_precedence show

Only if this order fits the entire routing design, set it on both firewalls:

system route_precedence set static vpn sdwan_policyroute

Then verify the value again with system route_precedence show. This change isn’t a general IPsec fix. It also affects other overlapping Static, VPN, and SD-WAN routes. Change Route Precedence safely explains the global effect and rollback.

Align rules, NAT, and the return path

Both firewalls need appropriate rules between LAN and VPN. Limit sources, destinations, and services to the actual site networks and applications; keep Log firewall traffic enabled during rollout.

Normally routed site traffic usually doesn’t require SNAT. If NAT exemptions or targeted translations already exist, they must behave the same way on both paths. Don’t add a broad MASQ rule as a failover shortcut.

The route on the peer is just as important as the forward path. A tunnel can be active even though the reply returns through the wrong ISP or a more general route. Evaluate Route Lookup, the active route, Firewall Rule ID, NAT Rule ID, and Packet Capture together.

Validate and operate failover

Validate failover and failback

Before the outage test, validate both tunnels individually with the same application flow. Keep one continuous test connection visible and also establish new sessions during the test.

During the maintenance window, interrupt only the ISP1 path in a controlled manner. Don’t disable both WAN ports or both tunnels at the same time. The test answers four questions:

1. Is the ISP1 gateway detected as unavailable?
2. Does the route with Administrative Distance 2 through the ISP2 XFRM become active?
3. Do new connections reach the peer, and do replies return through ISP2?
4. After ISP1 recovers, is the route with Administrative Distance 1 used again?

In Log Viewer and a narrow Packet Capture, the expected Firewall Rule ID, active XFRM interface, and bidirectional data flow must agree. A ping alone isn’t enough. HTTPS, RDP, VoIP, or another real application also shows whether session setup, MTU, and the return path work. Test a firewall rule using Log Viewer and Packet Capture explains the combined workflow.

In an HA cluster, test a new connection over both ISP paths after a planned failover. An active tunnel doesn’t promise that existing TCP sessions or routing states continue without interruption.

Troubleshoot systematically

Both tunnels are green, but ISP2 doesn’t take over

Check the gateway status, Monitoring Target, and both static routes. The destination network and prefix must be identical, while the next hops and XFRM interfaces must differ. Then compare the Administrative Distance and current Route Precedence.

ISP2 takes over, but applications don’t respond

Check firewall rules, NAT exemptions, and the return route on both sides. Packet Capture must show the request and reply on the ISP2 XFRM. If only the reply is missing, the fault is usually behind the peer or in an asymmetric return path.

Failback switches too early or doesn’t switch at all

Observe the Health Check and Monitoring Target. The target must not intermittently report the tunnel as healthy while the application path is still impaired. Check Administrative Distance, the active route, and a genuinely new session together; existing connections may remain attached to their previous state.

Only one direction works

Compare the mirrored configuration: XFRM address, gateway, static route, rule, and return path must exist on both firewalls. strongswan.log and xfrmi.log help with the IKE and XFRM layers; IPsec VPN troubleshooting explains the safe diagnostic path.

Roll back safely

Before the change, document the backup, original Route Precedence, tunnel status, XFRM addresses, gateways, rules, and routes. If the redundant path isn’t reliable:

1. Disable the new backup routes.
2. Disable the ISP2 gateways and second tunnel instead of deleting them immediately.
3. Restore the original Route Precedence on both firewalls.
4. Restore rules and NAT to the documented previous state.
5. Retest the original ISP1 path using a new application session.

Remove XFRM addresses, gateways, or tunnels only when Object usage no longer shows dependencies. Sophos Firewall backup and restore explains the backup and recovery workflow.

FAQ