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 running SFOS 22.0. It follows Sophos’ design for two internet connections. Policy-based tunnels and route-based tunnels with specific Traffic Selectors use an IPsec failover group instead.

⚠️ The current Sophos help conflicts on two any-to-any connections. The dedicated dual-ISP guide builds two such tunnels without a failover group. The general IPsec troubleshooting guidance, however, says that multiple connections with identical local and remote subnets, explicitly including Any-Any, only work in the same failover group. A failover group changes DPD and failback behaviour. This guide therefore doesn’t invent that step: validate the design on the installed SFOS 22 maintenance release and refer any different behaviour to Sophos Support before production use.

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 custom gateway with a deliberately chosen health check 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.

SFOS 22 allows static, SD-WAN, or dynamic routes for any-to-any XFRM interfaces. The dedicated dual-ISP procedure specifically uses two static routes. This workflow follows that static-route design; don’t add an SD-WAN route for the same destination unless its interaction and precedence have been designed and tested separately.

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.

On both firewalls, under Network > Interfaces, expand the WAN interface used for the respective IPsec connection. The automatically created XFRM interfaces appear beneath it as child interfaces. Use this to associate each XFRM with the tunnel over ISP1 or ISP2 before assigning its transfer address.

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.

For each gateway, set at least Name, Gateway IP, and Interface. Gateway IP is the peer XFRM address and Interface is the corresponding XFRM. Health check is off by default and must be turned on for path monitoring. SFOS 22 then shows Interval (default 60 seconds), Time-out (default 2 seconds), Retries (default 3), and at least one Monitoring condition with Protocol, Port for TCP, and IP address.

The probe IP must be a host behind the gateway. To assess the complete downstream path, choose a stable, permitted endpoint behind the peer. A ping to the peer XFRM address only proves the immediate tunnel segment. You can combine conditions with AND or OR: AND requires every response, whereas OR checks from the top until one target responds.

Choosing the protocol, target, and intervals is an operational decision: The target must respond reliably, must not disappear during normal maintenance, and requires the appropriate access. Defaults are starting points, not a guaranteed switchover time. Accept a change only after measuring detection, failover, and failback time. 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.

The dedicated Sophos guide attributes automatic failover and failback to this design. The general static-route reference confirms priority by Administrative Distance, but doesn’t separately describe how a failed custom-gateway health check removes a route from selection. The active route, not only gateway status, must therefore be observed in the acceptance test.

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.

The SFOS 22 help lists the general default as static, sdwan_policyroute, vpn, whereas the dedicated dual-ISP guide requires static vpn sdwan_policyroute for this design. Rollback must therefore restore the exact order previously recorded with show, not blindly apply the default.

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.

This differs from NAT Traversal. Sophos Firewall enables NAT-T automatically and uses UDP 4500 when it detects NAT; without NAT, IKE uses UDP 500 and ESP uses IP protocol 50. If a firewall is behind an upstream router, that router’s DNAT and access rules must reach the appropriate Listening Interface on both ISP paths. Overlapping site networks, by contrast, require corresponding SNAT and DNAT rules for payload traffic.

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. SFOS 22 restores route-based IPsec tunnels seamlessly, but limits session failover for traffic inside the tunnel to stateless protocols such as UDP and ICMP; TCP isn’t supported. Assess an existing and a new TCP connection separately. HA logs and reports also remain only on the node that processed the traffic, so check both devices.

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. The current Sophos troubleshooting page lists /log/strongswan.log, /log/charon.log, /log/strongswan-monitor.log, and /log/dgd.log; the last contains Dead Gateway Detection and VPN failover events. In the Advanced Shell, the read-only command ip xfrm state shows whether transform states exist. IPsec VPN troubleshooting explains the safe diagnostic path.

Tunnel and gateway status disagree

DPD and the gateway health check measure different things. Dead Peer Detection is configured under Profiles > IPsec profiles and detects an unresponsive IKE peer after the phase 2 tunnel has remained idle; Sophos recommends enabling DPD. The custom-gateway health check tests the selected host behind the XFRM path. Don’t disable DPD to hide a faulty probe host. If Sophos Support requires a failover group because of the documentation conflict above, note that adding one disables DPD in the associated profile, sets Key negotiation tries to 3, and introduces separate Automatic failback behaviour with no more than five retries. This is a different operating model and must not be mixed into this workflow without separate acceptance testing.

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