Migrate legacy Remote Access IPsec before SFOS 22 MR1

With SFOS 22.0 MR1, Sophos retired Legacy Remote Access IPsec VPN. The presence of a legacy configuration on the firewall blocks the upgrade to SFOS 22.0 MR1 and later versions. It must be deleted before the upgrade, even if nobody currently uses it to connect.

This article explains how to identify the old configuration before a firmware upgrade, document it properly, replace it with a current Remote Access solution and only then remove it. For the general upgrade check, also see Check Sophos Firewall before upgrading to SFOS 22.

What legacy Remote Access IPsec means

Sophos has supported several Remote Access methods over the years. In many environments, it is therefore not immediately clear whether the term refers to a current IPsec configuration, an old legacy entry, SSL VPN or Sophos Connect.

The following points are particularly important for the SFOS 22 MR1 upgrade:

• Legacy Remote Access IPsec is the old configuration type that can block the upgrade.
• Current Remote Access IPsec is the target path if IPsec is to remain in use.
• SSL VPN can be an alternative if IPsec is regularly blocked in hotels, guest networks or mobile network environments.
• ZTNA can be appropriate if access is required to individual applications rather than through a full client VPN.

The distinction matters operationally. A green VPN status or a working Sophos Connect Client does not automatically prove that there is no legacy configuration left on the firewall.

The client files also help identify the configuration type:

• With a legacy connection, a .tgb file was extracted from a downloaded .tar archive and imported into a third-party VPN client.
• The current Remote Access IPsec configuration can export an .scx file for Sophos Connect. It contains the advanced settings as well as the general settings.
• A current .tgb file alone does not prove that a legacy configuration exists, because the current IPsec page can still export it for third-party clients. The entry under Remote access VPN > IPsec (legacy) is what matters.

One important restore scenario is easily overlooked: backups or imported configurations can contain legacy Remote Access IPsec. Sophos restores or imports this configuration but does not migrate it to the current Remote Access IPsec model. The upgrade blocker must therefore be checked again after a restore, hardware replacement or configuration import.

When to migrate

The migration should be completed before the planned SFOS 22 MR1 upgrade. This change should not be left until the maintenance window for the firmware update, because Remote Access often involves users, certificates, MFA, DNS, firewall rules and client configurations.

Typical triggers:

• Sophos Firewall is to be upgraded to SFOS 22.0 MR1 or newer.
• The firmware page or Sophos documentation refers to legacy Remote Access IPsec.
• The environment contains old Sophos Connect profiles that have not been reviewed for years.
• Users report recurring Remote Access problems after profile or client changes.
• Remote Access is due to be reassessed with MFA, Entra ID SSO, SSL VPN or ZTNA anyway.

If Remote Access is business-critical, the migration should be handled as a separate change project. A firmware upgrade is then only the trigger, not the entire scope of work.

Document the environment before migration

First, document the current state. This step is more important than it looks, because many VPN configurations consist of more than just a tunnel profile. User groups, IP pools, DNS settings, firewall rules, NAT exceptions and client files are often associated with them.

Check the legacy configuration in WebAdmin

Before planning the target state, clearly establish whether legacy Remote Access IPsec is actually involved. This check is required not only before the firmware upgrade, but also after a restore, hardware replacement or configuration import.

Practical sequence:

1. Open Remote access VPN > IPsec (legacy) on the still-supported source version.
2. Check whether a legacy connection exists there. Whether it is currently in active use is irrelevant to the upgrade blocker.
3. Open Remote access VPN > IPsec and document the current Remote Access IPsec configuration separately.
4. Check Authentication > Users and user groups if static IP addresses, local users or old group assignments were used.
5. Search Rules and policies > Firewall rules for rules from the VPN zone to LAN, DMZ or WAN.
6. Check Administration > Device access to determine whether IPsec, VPN Portal, DNS or Ping can be reached from the required zones.
7. Open the firmware page again and check whether an upgrade blocker is still displayed.

If the legacy area is no longer visible but the upgrade is still blocked, do not delete objects based on assumptions. In that case, a screenshot of the message, a current backup and a traceable object list are more important than rushed clean-up work during the maintenance window.

At minimum, document the following:

• Users and groups: Which users may use Remote Access? Are local users, AD, RADIUS or Entra ID used?
• Authentication: Password, MFA, certificate, preshared key or SSO dependencies.
• IP pool: Which addresses do VPN clients receive? Are there conflicts with LAN, WLAN, VLAN or other VPNs?
• DNS: Which DNS servers and domains are distributed to clients?
• Access: Which internal networks, servers and services must be reachable?
• Firewall rules: Which rules allow traffic from VPN to LAN, DMZ or WAN?
• Client distribution: Where are old .tgb files, current Sophos Connect profiles (.scx or .pro) or SSL VPN configurations stored?
• Operations: Who can inform users, distribute profiles and receive error reports?

If there are already problems with routing or traffic through the tunnel, they should not be carried over unchecked into the new configuration. Sophos Firewall IPsec VPN troubleshooting helps with the analysis.

Choose the target path

There is no single right replacement for legacy Remote Access IPsec. The choice depends on what users actually need and how the environment is operated.

Current Remote Access IPsec

Current Remote Access IPsec is the obvious option if Sophos Connect is to continue using IPsec and the environment generally works well with it. IPsec is often performant, but in restrictive third-party networks it can encounter blocked UDP ports or special NAT cases.

This path is a good fit if:

• Sophos Connect is already deployed
• users work with Windows 10/11 or macOS 13 and newer
• IPsec has been stable in previous use
• internal networks are to be accessible through standard firewall rules

Sophos Connect itself supports current Remote Access IPsec on these Windows and macOS versions. Linux and other mobile platforms require a suitable third-party client; iOS can install its own IPsec profile from VPN Portal. The existing guide Configure Sophos Connect Client on Sophos Firewall describes the complete setup.

SSL VPN

SSL VPN is useful when Remote Access needs to work as robustly as possible through different third-party networks. Depending on the environment, SSL VPN can be simpler, but it raises different performance and client questions. For Windows, see the guide Install Sophos Connect SSL VPN Client.

This path is a good fit if:

• users often work in hotels, guest Wi-Fi networks or external company networks
• IPsec connections repeatedly fail because of network restrictions
• existing SSL VPN processes are already established
• mobile platforms or third-party OpenVPN clients are relevant

ZTNA or Clientless Access

If users only need individual internal web applications or defined applications, check whether a traditional full-tunnel VPN is still the right solution at all. ZTNA is not a direct replacement for every VPN scenario, but it can provide a better architecture for clearly scoped use cases.

For help with the decision, first read What is Zero Trust Network Access? Fundamentals, benefits and limitations. If Sophos ZTNA is to be used, Sophos ZTNA Gateway Connector describes the specific component. Clientless Access is only an alternative for suitable browser-based services and does not replace general network access.

Build the new Remote Access configuration

Prepare the new configuration in parallel before removing the old one. The aim is not to move all users into an untested setup at the same time.

For current Remote Access IPsec, simply creating a new profile name is not enough. The migration process should deliberately carry over or redefine the critical settings:

1. Define the target option: current Remote Access IPsec, SSL VPN, ZTNA or a combination.
2. Under Remote access VPN > IPsec, enable Remote Access and select the external Interface.
3. Use a suitable IPsec profile. Remote Access accepts IKEv1 profiles with Dead Peer Detection disabled or set to Disconnect.
4. Define the Authentication type, local and remote ID and Allowed users and groups.
5. Under Assign IP from, select a private range from at least one /24 subnet. It must not overlap with SSL VPN, L2TP, PPTP, LAN, WLAN or Site-to-Site networks.
6. Define DNS server 1, optionally DNS server 2, and the required internal resources.
7. Make a deliberate choice between Split Tunnel and Use as default gateway, and configure Prompt users for 2FA token to suit the MFA method.
8. Under Authentication > Groups, check whether Remote Access IPsec is permitted for the user group that actually applies. It is not enabled automatically for imported AD groups and migrated groups.
9. Under Administration > Device access, allow IPsec from the WAN zone. VPN Portal is only required if clients or provisioning access it; DNS and Ping should only be enabled where required by the specific design.
10. Create separate, clearly named firewall rules for inbound and outbound VPN traffic and enable logging.
11. Use Export connection to generate an .scx file for Sophos Connect or update existing .pro provisioning.
12. Distribute the test profile to a small number of pilot users, test it on at least two different network connections and only then plan the rollout.

MFA should not be treated as an optional detail for Remote Access. If the VPN is reachable worldwide, MFA, clean user groups, logging and a review of the Device Access settings belong together. The article Set up Sophos Firewall MFA covers the basics.

Plan coexistence and a fallback path

The new Remote Access solution should first be tested alongside the old configuration. This allows users to be migrated gradually and changes to be rolled back selectively if problems occur, without changing Remote Access, firewall rules, DNS, MFA and client distribution in the same maintenance window.

However, coexistence must be planned properly. The new configuration should not use the same IP pool, the same ambiguously named firewall rules or the same profile names as the old legacy configuration. Otherwise, Log Viewer will no longer show which access method actually connected a user.

Define these points before the pilot:

• Pilot group: a small number of users who are easy to contact and use different devices and networks.
• IP pool: a dedicated range without overlaps with LAN, WLAN, Site-to-Site VPN or old Remote Access.
• Firewall rules: dedicated, clearly named rules for the new VPN pool.
• Client profiles: a new connection name so users can distinguish the legacy connection from the target connection.
• Fallback criterion: define in advance when to revert to the old connection.
• Support window: the helpdesk or an administrator must be available during the pilot.

A fallback path does not mean continuing to operate the legacy configuration permanently. Its sole purpose is to stop the pilot in a controlled manner if login, MFA, DNS, routing or key applications do not work. Once the new solution is stable, remove the old configuration and check the upgrade blocker again.

Tests before removing the legacy configuration

The old configuration should only be removed once the replacement has been tested. Otherwise, the upgrade problem may be resolved while production Remote Access fails.

Functional test

Check at least the following:

• login with a test user works
• MFA or SSO is requested as expected
• the client receives a suitable VPN IP
• internal DNS names resolve
• key servers are reachable
• internet behaviour matches the design: Split Tunnel or Full Tunnel
• logout and a new login work

Firewall and routing test

In Log Viewer, check whether traffic from the VPN zone hits the expected rules. If traffic is dropped, check not only the VPN configuration, but also the firewall rule, NAT, Route Precedence and return path. For individual connections, the article Test a firewall rule with Log Viewer, Policy Test and Packet Capture is useful.

Client test

With Sophos Connect, existing profiles should not be overwritten without notice. A small pilot with clear feedback is preferable:

• Does the client import the new configuration?
• Is the old connection replaced in a way that users understand?
• Does the connection establish after a restart?
• Are DNS suffixes, routes and saved connections correct?
• Are there differences between Windows and macOS?

When distributing .scx files, any subsequent change must be exported and imported again. Existing .pro provisioning can retrieve subsequent changes automatically, provided that the gateway address and VPN Portal port remain accessible and unchanged.

Before a broad rollout, also check the client version in use. Check and safely update the Sophos Connect Client version is relevant for this step.

Remove the legacy configuration

Once the new solution has been tested in production, the legacy configuration can be removed. Before doing so, create another current backup. This is particularly important if firewall rules, user groups or authentication servers are also being adjusted in the same change.

Practical sequence:

1. Create a fresh backup.
2. Inform active users about the maintenance window.
3. Leave the new Remote Access configuration enabled.
4. Remove legacy Remote Access IPsec in WebAdmin.
5. Check old profiles, IP pools and rules that are no longer needed for dependencies.
6. Open the firmware page again and check whether the upgrade blocker has disappeared.
7. Document the result.

Do not immediately delete everything that looks old. Old firewall rules, hosts or groups may also be used for Site-to-Site VPN, SSL VPN or other purposes. Check dependencies first, then clean up.

After a restore or configuration import, repeat the check. A backup can contain old legacy objects without automatically creating a current Remote Access IPsec configuration from them. For operations and documentation, the decisive factor is therefore whether the production target configuration was actually rebuilt, tested and distributed.

Troubleshooting

Upgrade remains blocked

If the upgrade remains blocked even though the visible legacy configuration has been removed, first reopen the firmware area and check Remote access VPN > IPsec (legacy) again. Do not delete hosts, groups or current IPsec profiles based on assumptions. If it remains unclear which legacy configuration is being detected, prepare a Sophos Support case with a screenshot of the upgrade message, the source version and a current backup.

The legacy issue returns after a restore

After a restore, hardware replacement or import of an old configuration, check Remote Access again. What matters is not whether the earlier change was once completed, but what exists in the currently running configuration. Old backups can reintroduce historical Remote Access objects or trigger a new check of the upgrade path.

Users cannot log in

For login problems, first check authentication, MFA, the user group and VPN policy. If RADIUS, AD or Entra ID is involved, test the server connection separately from the VPN. A VPN problem is not always an IPsec problem.

The connection is established, but internal systems are not reachable

The cause is then often firewall rules, NAT, DNS or routing. Check whether the client receives a suitable VPN IP, whether internal names resolve correctly and whether the traffic in Log Viewer hits the expected rule.

Some networks work, others do not

In this case, Split Tunnel networks, IPsec routes, static routes or missing return routes are often involved. For IPsec scenarios, IPsec route on Sophos Firewall is a useful follow-up article.

Checklist

Before the rollout

• Legacy Remote Access IPsec identified
• users, groups, IP pool, DNS and firewall rules documented
• target path chosen: current IPsec, SSL VPN, ZTNA or combination
• MFA and authentication checked
• Device Access checked according to requirements: IPsec on WAN, VPN Portal for distribution or provisioning, DNS and Ping only if required
• coexistence and fallback criterion defined
• test users defined
• backup created

During the rollout

• new configuration tested with pilot users
• client profiles distributed
• Log Viewer and affected firewall rules checked
• fallback path communicated
• user feedback collected

After the migration

• legacy configuration removed
• upgrade blocker checked again
• restore and import scenario documented
• old profiles and rules checked for dependencies
• documentation updated
• firmware upgrade planned only afterwards

FAQ