Migrate legacy Remote Access IPsec before SFOS 22 MR1

With SFOS 22.0 MR1, Sophos finally removed legacy Remote Access IPsec VPN from the supported upgrade path. Firewalls that still contain this old Remote Access IPsec configuration cannot be upgraded to SFOS 22.0 MR1 or newer versions.

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, check Sophos Firewall before the SFOS 22 upgrade is also relevant.

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 a current IPsec configuration, an old legacy entry, SSL VPN or Sophos Connect is meant.

For the SFOS 22 MR1 upgrade, the important points are:

• Legacy Remote Access IPsec is the old configuration type that can block the upgrade.
• Current Remote Access IPsec is the target path if IPsec should continue to be used.
• SSL VPN can be an alternative if IPsec is regularly blocked in hotels, guest networks or mobile network environments.
• ZTNA can make sense if access is needed to individual applications rather than 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.

One important restore case is easy to miss: backups or imported configurations can contain legacy Remote Access IPsec, but this legacy configuration is not migrated automatically. After a restore, hardware replacement or configuration import, the point should therefore be checked again, even if the firewall previously appeared to have been cleaned up.

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 points 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 anyway with MFA, Entra ID SSO, SSL VPN or ZTNA.

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

Document 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 attached to them.

Check the legacy configuration in WebAdmin

Before planning the target state, clearly establish whether legacy Remote Access IPsec is actually involved. This check belongs 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) if the menu item is visible in the installed SFOS version.
2. Check whether legacy Remote Access IPsec is enabled or whether configuration objects still exist.
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 see whether IPsec, VPN Portal, DNS or Ping are reachable 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 on suspicion. 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:

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 should continue to be used with IPsec and the environment generally works well with it. IPsec is often performant, but in restrictive third-party networks it can be affected by blocked UDP ports or special NAT cases.

This path fits well if:

• Sophos Connect is already deployed
• users mainly work with Windows or macOS
• IPsec was stable in previous use
• internal networks should be reachable through classic firewall rules

The existing guide configure Sophos Connect Client on Sophos Firewall can serve as a basis, but must be checked against current SFOS versions and the organisation’s own authentication design.

SSL VPN

SSL VPN is useful when Remote Access should 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 fits well 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 classic full-tunnel VPN is still the right solution at all. ZTNA is not a direct replacement for every VPN scenario, but in clearly scoped use cases it can be the better architecture.

The existing article Sophos ZTNA Gateway Connector is a good starting point. Clientless Access can also be relevant for simple web access if the requirements fit.

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.

Recommended sequence:

1. Define the target variant: current Remote Access IPsec, SSL VPN, ZTNA or a combination.
2. Choose a new IP pool and check it for overlaps.
3. Define the authentication source and MFA.
4. Assign the required users or groups.
5. Define DNS servers and internal domains.
6. Create firewall rules for the new VPN sources.
7. Create a test profile for a few users.
8. Test the connection on at least two different network connections.
9. Only then plan user communication and 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 fallback

The new Remote Access solution should first be tested alongside the old configuration. This allows users to be migrated gradually and issues to be rolled back in a targeted way, without changing Remote Access, firewall rules, DNS, MFA and client distribution all in the same maintenance window.

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

Before the pilot, these points should be defined:

A fallback path does not mean continuing to operate the legacy configuration permanently. It only exists to stop the pilot in a controlled way if login, MFA, DNS, routing or key applications do not work. As soon as the new solution is stable, the old configuration should be removed and the upgrade blocker checked 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 solved, but productive Remote Access can fail.

Functional test

Check at least:

• 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 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, do not check only the VPN configuration, but also 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 silently overwritten. A small pilot with clear feedback is better:

• 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?

Before a broad rollout, the client version in use should also be checked. Check and safely update the Sophos Connect Client version fits this step.

Remove the legacy configuration

Once the new solution has been tested in production, the legacy configuration can be removed. Before that, 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.
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, it is therefore decisive whether the productive 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 reload the firewall or open the firmware area again. Then check whether all legacy Remote Access objects were really removed. If it remains unclear which object is blocking the upgrade, prepare a Sophos Support case with a screenshot of the upgrade message and a current backup.

The legacy question returns after a restore

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

Users cannot log in

For login problems, first check authentication, MFA, 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 up, 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 for IPsec, VPN Portal, DNS and Ping
• coexistence and fallback criterion defined
• test user 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