Fix Sophos Firewall IPsec Remote Access 4-Hour Timeout

If Sophos Connect with IPsec Remote Access and OTP disconnects after approximately four hours, the documented IKEv1 rekeying of the default profile may be the cause. During Phase 1 rekeying, the firewall requests another OTP; the existing tunnel then goes down. Sophos specifies an interval of approximately four hours for the default profile.

This article explains how to classify the behaviour, which logs support the diagnosis, and how to adjust the value properly using a custom IPsec profile. For the basic Sophos Connect configuration, start with Configure Sophos Connect on Sophos Firewall. For choosing between IPsec, SSL VPN, mobile clients, and ZTNA, Sophos Connect or SSL VPN: Which Remote Access Solution Fits? is the better starting point.

⚠️ Important: This cause applies to Remote Access IPsec with IKEv1 and OTP. A longer IKE lifetime will not fix an SSL VPN disconnection, a configured idle timeout, or an unstable internet connection.

Narrow Down the Cause First

The rekeying issue is likely when several indicators match:

• Sophos Connect regularly disconnects after approximately four hours.
• Users must confirm OTP or MFA again after the disconnection.
• The connection is stable beforehand and works again after signing in again.
• Other VPN profiles or SSL VPN connections do not show this behaviour.
• The timing matches the Phase 1 rekey of the assigned IPsec profile.
• The VPN log contains IKE, authentication, or rekeying messages that coincide with the disconnection.

First, check under Remote access VPN > IPsec which IPsec profile is selected and whether Disconnect when tunnel is idle is enabled. An idle timeout only terminates inactive connections after the configured Idle session time interval. This differs from a recurring OTP disconnection during active use.

If the connection drops at random, only fails on certain networks, or carries no traffic immediately after being established, general IPsec VPN Troubleshooting is more appropriate.

Exclude Legacy Remote Access IPsec First

Especially in older environments, first establish which IPsec Remote Access variant is actually in use. This article covers the current Remote Access IPsec configuration with Sophos Connect and IPsec profiles. It is not the right starting point if Legacy Remote Access IPsec is still present or an upgrade to SFOS 22.0 MR1 is being blocked.

Practical classification:

• Connection disconnects after a similar duration and then reconnects: This article is the right next step.
• Upgrade to SFOS 22.0 MR1 or newer is blocked because of Legacy IPsec: Start with Migrate Legacy Remote Access IPsec before SFOS 22 MR1.
• Tunnel is connected, but internal destinations are unreachable: Continue with Sophos Firewall IPsec VPN Troubleshooting.
• Users should move from IPsec to SSL VPN, ZTNA, or another model: See Sophos Connect or SSL VPN: Which Remote Access Solution Fits?.

This distinction matters because tuning the key life is not a migration plan. If an old legacy configuration remains on the firewall, it should be properly documented, replaced, and removed before a major firmware upgrade.

Why IKEv1 Rekeying with OTP Disconnects the Tunnel

Sophos Connect uses an IKEv1 profile for Remote Access IPsec. In many environments, DefaultRemoteAccess is assigned. Among other settings, this profile defines the lifetime of the Phase 1 Security Association and when renegotiation begins.

Three fields determine the timing:

• Key life: Maximum lifetime of the Phase 1 SA in seconds.
• Re-key margin: Period before the Key life expires in which renegotiation begins.
• Randomize re-keying margin by: Percentage variation in the rekeying time so that not all tunnels renegotiate simultaneously.

The existing screenshot shows a Key life of 18000 seconds for DefaultRemoteAccess. However, this must not be used to derive a universal four-hour formula: the re-key margin, randomisation, client behaviour, and authentication affect when the interruption becomes visible. The values of the profile actually assigned and the timestamps from the specific incident are decisive.

The key technical decision is this: a longer value reduces re-authentication but also extends the lifetime of the IKE SA. This is an operational and security decision, not merely a convenience setting.

Correlate Logs with the Connection Duration

In the Log viewer, open the VPN section and compare the connection establishment with the subsequent disconnection for the same user. Record the start time, user, public client IP, and time of the renewed OTP request. Also capture the Sophos Connect client status at the same time.

Messages such as invalid SPI can occur after Security Associations have expired or already been replaced. On their own, however, they do not prove this issue. Stronger evidence is the combination of a regular connection duration, an IKEv1 profile, an OTP request, and a matching Phase 1 rekey. For recurring VPN issues, Save Sophos Firewall Logs for Support and Analysis and Sophos Firewall Troubleshooting: Services and Logs can also help.

Adjust the IPsec Profile Through the GUI

The cleaner method is not to modify the default profile directly, but to clone it and deliberately use the new value for Remote Access.

The current menu path is:

Profiles > IPsec profiles

Procedure:

1. Click Clone for DefaultRemoteAccess.
2. Give the new profile a clear name, for example RemoteAccess_OTP_12h.
3. Leave Key exchange set to IKEv1 and keep Re-key connection enabled.
4. Under Phase 1, check the Key life, Re-key margin, and Randomize re-keying margin by values.
5. Enter the required Key life. Sophos documents a maximum of 24 hours for this workaround, which is 86400 seconds.
6. Under Phase 2, ensure that its Key life remains lower than the Phase 1 value.
7. Under Dead peer detection, use an option available for Remote Access: disabled or When peer unreachable: Disconnect.
8. Save the profile.
9. Under Remote access VPN > IPsec, select the new IPsec profile and save the configuration.
10. Deploy the updated Sophos Connect configuration and test it with a pilot user first.

After the change, saving the firewall alone is not enough. If .scx files are distributed manually, export a current file under Remote access VPN > IPsec using Export connection, then import it again on the clients. If a .pro provisioning file with Sophos Connect 2.1 or newer is already in use, the client automatically retrieves subsequent configuration changes from the VPN Portal. For this to work, the gateway address and VPN Portal port must not have been changed in the meantime.

For client operation and versions, see Check and Securely Update the Sophos Connect Client Version. For Windows installations, see Install the Sophos Connect Client on Windows, and for macOS, Install the Sophos Connect Client on macOS.

Set an Appropriate Lifetime

There is no reliable formula for calculating a single ikekeylife value directly from a desired OTP prompt interval. Key life is the maximum SA lifetime; rekeying starts within the Re-key margin and may also be randomised.

For example, 43200 seconds corresponds to a twelve-hour Key life. Depending on the re-key margin and randomisation, renegotiation starts earlier. The value should therefore not be described as a guaranteed twelve-hour user session. Sophos specifies 24 hours as the upper limit for this workaround.

Before making the change, clarify:

• What maximum IKE key lifetime and rekeying interval are acceptable from a security perspective?
• Does the value suit working hours, shift patterns, and the helpdesk process?
• Is OTP, RADIUS MFA, Entra ID SSO, or another authentication method used?
• Are there compliance requirements for re-authentication?
• Does rekeying or reconnecting work reliably with the current Sophos Connect client?

For MFA fundamentals on the firewall, see Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access. If Microsoft Entra ID SSO is in use, also consider Set Up Microsoft Entra ID SSO for Sophos Connect and VPN Portal.

Why Direct Database Changes Are Not Recommended

Some older runbooks include direct changes in the Advanced Shell or SQL commands against the firewall database. This is not recommended for normal operations.

Reasons:

• The intervention bypasses normal WebAdmin validation.
• Incorrect values can disrupt VPN profiles or Remote Access.
• Changes are harder to trace.
• In support cases, a clean GUI change is easier to explain.
• Internal behaviour may change after updates.

The value should therefore be set through a custom IPsec profile in WebAdmin. Direct database changes belong, at most, in a clearly defined Sophos Support context and not in a normal admin guide.

Test the Change Across the Rekeying Window

After the adjustment, conduct a small test with pilot users.

Checkpoints:

1. The new profile is selected in Remote Access IPsec.
2. The new .scx file has been imported, or the .pro provisioning has retrieved the change.
3. The connection establishes successfully.
4. Internal destinations are reachable.
5. DNS, routing, and firewall rules work.
6. The connection remains active until the expected rekeying window.
7. No unplanned interruption or unclear OTP loop occurs during rekeying.
8. The VPN logs show the expected renegotiation without new errors.

If the connection establishes but no traffic flows, the issue is more likely to involve routes, firewall rules, NAT, or DNS. In that case, see Test a Firewall Rule with Log Viewer, Policy Test, and Packet Capture.

Common Mistakes

Common pitfalls:

• Default profile modified directly: Other Remote Access scenarios may be affected unintentionally. A cloned profile assigned specifically is preferable.
• Client profile not updated: With manual .scx distribution, users continue to use old settings. With working .pro provisioning, subsequent changes are retrieved automatically instead.
• Key life set too long: Less re-authentication means a longer IKE SA lifetime. Security and operational requirements should be assessed together.
• Only the client reinstalled: The firewall profile remains unchanged. The firewall profile and client configuration must be checked together.
• invalid SPI used as the only evidence: The message can also result from SAs that have already been replaced. The connection duration, IKE rekey, and OTP request must coincide.
• Database modified directly: This increases the risk of support and configuration problems. The GUI profile should be used for normal operations.

Operational Checklist

• Record affected users and times.
• Check whether IPsec Remote Access with Sophos Connect is in use.
• Check VPN logs for indications of IKE, SPI, and rekeying.
• Identify the IPsec profile in use.
• Clone DefaultRemoteAccess instead of modifying it directly.
• Record the Phase 1 values for Key life, Re-key margin, and randomisation.
• Define a technically appropriate target value of no more than 24 hours.
• Assign the new profile in Remote Access IPsec.
• Redistribute the client configuration.
• Test with pilot users and inform the helpdesk.
• After a few days, check whether fewer OTP reconnect cases occur.

FAQ