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 route-based Any-to-Any: The XFRM interfaces receive transfer addresses, while static, dynamic, or SD-WAN Routes determine the data path. Multiple XFRM gateways can be prioritized directly through an SD-WAN Profile and SLA checks. No additional VPN failover group is required for this design.

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.

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 configuration nor the DNS update can be controlled, stop the design at this point. Two simultaneously published addresses must not be treated 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. For fixed peer addresses, a narrow Local Service ACL Exception is better than an unnecessarily broad allowance. Device Access and Local Service ACL explains the secure 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 active site-to-site IPsec connections.
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 if tunnel changes should be reported by email. 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 disables Dead Peer Detection for that connection and effectively sets Key negotiation tries to 3. The Failover Condition takes over monitoring. The values shown in the profile alone therefore do not represent all effective behavior.

After the connection is removed from the group, it once again uses the DPD and Key-negotiation values from its assigned IPsec profile. This matters during rollback: A tunnel can behave differently after the group has been removed even though 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.

The group can be turned off and on manually to trigger another attempt to establish the primary connection. However, this causes downtime and is not a harmless refresh switch. 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, ipsec_monitor.log, and the connection-specific action log. In the last line, replace HQ-Branch-ISP1 with the actual connection name:

tail -n 200 /log/charon.log
tail -n 200 /log/ipsec_monitor.log
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 and active. Check whether a connection 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.

The order is incorrect after drag-and-drop

Sophos confirms the NC-178121 issue for SFOS 22.0 GA: After a drag-and-drop change, site-to-site IPsec connections could end up in the wrong position within the failover group. This specific issue is fixed in SFOS 22.0 MR2 Build 546.

On SFOS 22.0 GA, document the order before and after every change and do not rely only on the visual move. The public release note does not specify an unambiguous separate affected-version or fix boundary for MR1. If a similar issue occurs on MR2 Build 546 or later, it must not automatically continue to be attributed to NC-178121.

Remove the group

Turning off a failover group deactivates its members’ active tunnels. Any required standalone connections must then be reactivated separately. 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