Configure and test an IPsec failover group on Sophos Firewall

An IPsec failover group orders several site-to-site IPsec connections by priority. If the primary tunnel fails, Sophos Firewall activates the next available connection. For failover to actually help, however, both tunnels must already work individually and cover the same production networks, rules, NAT expectations, and return paths.

Quick procedure: Test two IPsec connections individually, verify the Remote IDs and order, combine them into a group under Site-to-site VPN > IPsec > Failover group, choose a suitable Failover Condition, and then validate failover and failback with a defined test flow.

This guide assumes an existing site-to-site IPsec configuration. It explains redundancy control rather than repeating the complete tunnel setup.

When an IPsec failover group is suitable

A group is primarily suitable for policy-based IPsec and route-based IPsec with specific Traffic Selectors. Multiple connections with identical Local and Remote subnets must either belong to the same failover group or use clearly different selectors. Otherwise, the tunnels can interfere with each other.

The decision is different for a fully route-controlled route-based Any-to-Any design: The XFRM interfaces receive transfer addresses, while static, dynamic, or SD-WAN Routes determine the data path. Sophos documents multiple XFRM gateways with an SD-WAN Profile and SLA checks without an additional VPN failover group for this design. Outside this design, however, Sophos also warns that multiple Any-to-Any connections with identical selectors require a common failover group.

Make route-based IPsec resilient with two internet connections explains the complete design with two providers, separate XFRM gateways, static primary and backup routes, and controlled failover testing.

Normal WAN failover does not replace the group either. WAN link manager can switch the internet connection, but it does not create a second IPsec connection with its own Gateway Address, Listening Interface, and peer configuration.

system link_failover is a separate CLI mechanism

SFOS 22 also publishes a Device Console command that adds a VPN or GRE tunnel as a backup for a primary link. The published grammar is:

system link_failover add [primarylink] [portname] [backuplink] [vpn] [gre] [tunnel] [tunnelname] [monitor PING host] [monitor TCP host] [ipaddress] [portnumber]

For monitor TCP host, specify the TCP port to check; monitor PING host does not use a port. The target must not merely respond but meaningfully represent the relevant path. A successful monitor does not prove that the application, firewall rule, route, or return direction works.

This command is not the same as the WebAdmin IPsec failover group or the XFRM and SD-WAN design. The public SFOS 22 page documents only add; it provides no status, delete, or rollback command and does not explain interactions with existing routes or SD-WAN policies. Without a rollback method confirmed for the installed build, this is not a copy-and-paste procedure. For new configurations, the documented WebAdmin or XFRM methods are the more traceable starting point.

An FQDN with multiple WAN addresses is not failover

If the same DNS A record points to both the primary WAN address and an address that is only active during an outage, the remote peer can select the inactive address. DNS round robin knows neither the WAN status nor the tunnel state. A local IPsec failover group does not automatically correct this remote DNS selection.

For remotely initiated tunnels, the peer therefore needs either two explicitly configured connections or an FQDN whose health-aware DNS or DDNS update points only to the currently reachable address. If neither the peer nor the DNS update can be controlled, this design cannot provide reliable inbound failover. Two simultaneously published addresses do not count as tested failover.

A VPN failover group is also different from an HA cluster. The group switches between tunnels. HA switches between two firewall nodes. In a critical environment, WAN, VPN, and possible HA failures must therefore be planned and tested separately.

What the group monitors

Sophos Firewall checks the peer using the group’s Failover condition. The interval comes from the global Gateway failover time-out value under:

Network > WAN link manager

The same value also affects general WAN gateway monitoring. It should therefore not be changed for only one VPN tunnel. A short value reacts faster but can trigger unnecessary failover during brief packet loss. A long value tolerates disruptions for longer but extends the outage before switching.

The health check only confirms that the remote peer responds to the selected ping or TCP condition. It does not prove that DNS, a business application, NAT, routing, and the complete return path work. These points are tested separately after failover.

Prepare two tunnels for the group

The following example connects a head office and a branch through two tunnels:

• Head office: 10.10.0.0/16
• Branch: 10.20.0.0/16
• Primary connection: HQ-Branch-ISP1
• Secondary connection: HQ-Branch-ISP2
• Primary peer address: 198.51.100.20
• Secondary peer address: 203.0.113.20
• Shared Remote ID of the branch: 10.255.255.2
• Failover group: HQ-Branch-Zurich

The addresses 198.51.100.0/24 and 203.0.113.0/24 are documentation networks and must be replaced with the actual public peer addresses. The networks, names, and Remote ID are example values as well. The principle is what matters: The Gateway addresses may differ, but the IP address of the Remote ID must be the same for all group members. At the peer, this Remote ID must match the corresponding Local ID.

Before grouping them, test both connections individually:

1. Both connections are active under Site-to-site VPN > IPsec.
2. Each connection can be established independently and carries the same defined test flow.
3. Local and Remote subnets or Traffic Selectors mirror the peer configuration.
4. Firewall rules allow the required traffic through the VPN zone in both directions.
5. NAT is identical on both paths and has been configured deliberately.
6. The peer has a return path through both tunnels.
7. The profiles match the respective peer. IPsec profiles on Sophos Firewall explains DPD, rekeying, and lifetimes.
8. An alternative administrative access path and a maintenance window are available.

⚠️ Adding connections to a failover group disconnects established connections. Do not make this change during an unattended remote session or without a tested fallback path.

A connection can only be a member of one failover group. It cannot be deleted while it belongs to a group. Remote access IPsec connections cannot be used as group members.

Choose a suitable Failover Condition

Sophos supports ping or TCP with a defined port. The condition must be deliberately allowed on both firewalls:

• Ping: easy to verify, but requires Ping/Ping6 for the WAN zone under Administration > Device access. Sophos documents this zone allowance as a prerequisite. For fixed peer addresses, a narrow Local Service ACL Exception can be evaluated as hardening; it must match the source address actually used by the peer. Device Access and Local Service ACL explains the configuration.
• TCP 22: requires SSH over the VPN zone. WAN SSH should not be opened for this purpose. A management service is not a good general health check if it would have to be exposed solely for monitoring.
• Other TCP port: requires corresponding inbound and outbound firewall rules. The service must remain available and must not depend solely on the state of an arbitrary application.

The condition should represent a stable response service or path at the remote peer. If the TCP service stops responding because of maintenance, a local failure, or a host firewall, the group can fail over even though the IPsec path itself is still available.

Configure the IPsec failover group

The menu path is:

Site-to-site VPN > IPsec > Failover group > Add

1. Enter a unique Name, HQ-Branch-Zurich in this example.
2. Under Member connections, select at least two site-to-site IPsec connections. Only connections with active status participate in failover, so activate and test every intended member individually before putting the group into service.
3. Put the connections in the required order: HQ-Branch-ISP1 first and HQ-Branch-ISP2 second. The first connection is the primary tunnel.
4. Turn on Mail notification to receive connection failure notifications. The Notification settings and VPN notifications must already work.
5. Turn on Automatic failback if the group should return to the preferred tunnel after it has recovered.
6. Specify a suitable Failover condition using ping or TCP and a port.
7. Click Save.
8. Turn on the group’s status switch. Only then is the group active and attempts to establish the primary connection.

When two Sophos Firewalls are involved, verify connection properties, member order, Remote IDs, and health-check allowances on both sides. A correct group on only one side does not replace a matching peer configuration.

What happens to DPD and Key negotiation tries

As soon as a connection becomes a group member, SFOS turns off Dead Peer Detection for that connection and uses 3 for Key negotiation tries. The Failover Condition takes over monitoring.

After the connection is removed from the group, it once again uses the DPD and Key-negotiation values from its assigned IPsec profile. Include this behavior in the rollback test even when the profile itself was not edited.

Test failover and failback in a controlled manner

Before the outage test, define a specific data flow, for example:

• Source: 10.10.10.25
• Destination: 10.20.20.15
• Service: TCP 443
• Expected firewall rule: HQ-to-Branch-HTTPS

Then perform the test in a clear sequence:

1. Document the group status, member order, firmware build, and Gateway failover time-out.
2. Verify the primary tunnel on both sides in WebAdmin. Use real HTTPS traffic to confirm that both the outbound and return paths work.
3. Record the state in the Advanced Shell with ipsec statusall.
4. During the maintenance window, interrupt the primary WAN or upstream path in a controlled manner. Do not turn off the entire failover group, because this deactivates all active member tunnels.
5. Observe for longer than the configured Gateway failover time-out and record when the switch occurs.
6. Verify that HQ-Branch-ISP2 is established and that the same HTTPS test works in both directions.
7. Check the firewall rule, NAT, return path, and application function. A green tunnel alone is not a success criterion.
8. Restore the primary path and observe Automatic failback.
9. Repeat the same test after failback and document the interruption that was actually measured.

Existing TCP sessions can terminate during the switch. The new tunnel has different Security Associations and may use a different public address. The application therefore often has to establish a new session. IPsec failover improves availability but does not guarantee an uninterrupted session.

Automatic failback stops after five unsuccessful attempts

When the primary peer becomes reachable again, SFOS attempts to restore the preferred connection up to five times if Automatic failback is turned on. If these attempts fail, the secondary tunnel remains active. The firewall does not continue checking the primary tunnel indefinitely; another switch back only occurs if the secondary path fails. If the group contains more than two connections, SFOS fails back to the first available connection in the Member connections order.

The group can be turned off and on manually to trigger another attempt to establish the primary connection. This causes downtime. Check the logs, peer, profile, IDs, and path first.

Read the logs without changing the configuration

dgd.log is important for the group decision, while strongswan.log covers the actual IPsec establishment. The following commands run in the Advanced Shell and do not change the configuration:

tail -n 200 /log/dgd.log
tail -n 200 /log/strongswan.log
ipsec statusall

If necessary, add charon.log and the connection-specific action log. The official SFOS 22 pages disagree on the monitor log name: the general log reference lists ipsec_monitor.log, while the IPsec troubleshooting page lists strongswan-monitor.log. Read only the file that exists on the installed build. In the last line, replace HQ-Branch-ISP1 with the actual connection name:

tail -n 200 /log/charon.log
for log in /log/ipsec_monitor.log /log/strongswan-monitor.log; do [ -f "$log" ] && tail -n 200 "$log"; done
tail -n 200 /log/ipsec_conn/ipsec_HQ-Branch-ISP1.log

Compare timestamps from dgd.log, the IPsec status, WAN event, and application test. A failed health check without a corresponding tunnel or application failure does not yet prove a provider outage. Sophos Firewall IPsec VPN troubleshooting provides the complete diagnostic path.

Common errors and safe rollback

The group does not activate correctly

At least two connections must be selected. Only active connections participate in failover. Check whether an intended member is turned off, already belongs to another group, was created as Remote Access, or uses a different Remote ID. Then test both tunnels individually again before reactivating the group.

The secondary tunnel is green, but traffic fails

The group logic has probably worked, but the data path has not. Check firewall rules, NAT, Local and Remote subnets, automatic or manual routes, and the return path at the peer. The secondary tunnel must be able to carry the same production test flow as the primary tunnel.

The group switches too early or too late

Check the Failover Condition together with Gateway failover time-out. An unstable ping or TCP target can trigger unnecessary switches. A long global timeout also delays other dependent gateway checks. Do not change only the number; document the cause, packet loss, and actual switch time.

Verify the order after drag-and-drop

The current public SFOS 22 help does not provide a reliable affected-version or fix boundary for an incorrect order after drag-and-drop. Reopen the saved group after every change and compare its order with the intended priority.

Remove the group

Turning off a failover group deactivates its members’ active tunnels. Any required standalone connections must then be reactivated separately. Sophos does not document the side effects of deleting the group itself. Therefore, turn off the group during a maintenance window, remove assignments in a controlled manner, and do not assume automatic reactivation. For a controlled rollback:

1. Record the initial state, member order, and profiles in use.
2. Confirm the maintenance window and an alternative administrative access path.
3. Turn off the group and document the interruption.
4. Remove the connections from the group or restore the original assignment.
5. Activate the required standalone connection.
6. Reconsider the DPD and Key-negotiation behavior from the profile.
7. Verify the same test flow, logs, and return path.

Operations

• Retest failover and failback after firmware, provider, peer, routing, NAT, or profile changes.
• Document member order, Remote IDs, profiles, the health-check condition, and the global timeout.
• Use Mail notification only as an alert; technical acceptance still requires status, logs, and real traffic.
• Include both tunnels in monitoring, maintenance plans, and peer documentation.
• Verify that the secondary provider supports the same allowlists, NAT dependencies, and public reachability.
• Only turn the group off and on manually when an interruption has been planned.

FAQ