Check Sophos Firewall before SFOS 22 Upgrade

SFOS 22 introduces significant architectural changes to the Sophos Firewall. Therefore, administrators are not only interested in the new features available after the update. More importantly, the question is whether their firewall can be smoothly updated to SFOS 22.

This guide serves as a pre-upgrade check. The article does not replace the general guide to Sophos Firewall Firmware Update, but complements it with points that can quickly lead to problems with SFOS 22: supported platform, interface names, storage space, backup, HA status, Legacy Remote Access IPsec, policy-based IPsec, NAT, and rollback plan.

Video Guide

When this check is useful

The check should be performed before any planned upgrade to SFOS 22 or higher. It is especially important if any of the following situations apply:

• the firewall is still running on XG or SG hardware
• the appliance has already been updated over several major releases
• there are many VLANs, aliases, bridges, LAGs, RED, or XFRM interfaces
• it is a small desktop appliance, virtual firewall, or software appliance
• the firewall is running in an HA cluster
• Remote Access IPsec VPN is or has been used in the past
• policy-based Site-to-Site IPsec, specific SNAT rules, or VPN NAT rules are in use
• STAS or other user-based authentication controls productive firewall rules
• the firewall is managed via Sophos Central or is to be updated through it

If the firewall is already unstable in everyday use, services need to be restarted regularly, or partitions are heavily filled, the upgrade should not be seen as a repair attempt. In this case, first stabilize the current state and clarify the cause.

1. Check platform and upgrade path

SFOS 22.0 and later versions no longer support XG and SG hardware appliances. Those still operating such devices must first plan the migration to XGS, virtual firewall, software appliance, or cloud deployment. The article What is the difference between an XG and XGS Firewall? helps in deciding between old and new hardware generations.

On supported platforms, it should also be checked from which version the update is being made. The SFOS 22 Release Notes show which versions can be directly migrated to SFOS 22. If an unsupported path is chosen, the firewall may start with factory configuration after confirmation. This exact risk must be excluded before a maintenance window.

Practical steps:

1. Note the current firmware version under Backup & Firmware > Firmware.
2. Document model, serial number, and platform type.
3. Check in the official Sophos Release Notes whether the direct upgrade path is supported.
4. For XG or SG hardware, do not treat SFOS-22 planning as a normal update, but as a migration project.

2. Check interface names before the upgrade

An easily overlooked upgrade point concerns the names of interfaces. Physical or logical interfaces may not be visible or expandable in the WebAdmin view under Network > Interfaces if an interface name, hardware name, or branch name ends with ten or more digits.

This is inconvenient because traffic can continue to be processed, but administration in WebAdmin suddenly looks as if interfaces are missing. This point should be checked before the upgrade, especially in migrations, automated naming schemes, imported configurations, or VLAN names with location, customer, or inventory numbers.

Critical examples:

Practical steps:

1. Open Network > Interfaces.
2. Check physical interfaces, VLANs, aliases, bridges, LAGs, RED interfaces, and XFRM interfaces.
3. Look for names ending with ten or more digits.
4. Change affected names to a shorter or clearly separated format before the upgrade.
5. After the change, check whether firewall rules, NAT rules, SD-WAN routes, DHCP, VPN, and documentation are still understandable.

Better are names where numbers do not appear as a long block at the end. Instead of VLAN_1234567890, for example, VLAN-1234567890-Client or a functional name like Client-VLAN-100 is more readable and operationally robust.

If interfaces are missing in the WebAdmin view after an upgrade, do not immediately assume that the network configuration is lost. First, check whether the behaviour matches the interface name issue, whether traffic continues to run, and whether the affected names need to be adjusted. For general interface planning, see Configure Sophos Firewall Zones and Interfaces.

3. Check storage space and firmware notices

SFOS 22 requires additional storage space for new features and architectural changes. Most appliances meet the requirements, but some desktop, virtual, and software deployments may require manual checking or correction. If the firewall shows a message about storage space requirements on the Control Center or Firmware page, it should not be ignored.

The partition fill level can be roughly checked via SSH:

df -kh

The output does not replace a Sophos compatibility check but helps assess whether /, /var, /content, or other partitions are conspicuously full. If a partition is very tight, do not blindly update. First, clarify what data is there, whether logs or old files can be cleaned up, and whether a Sophos notice exists for the affected appliance.

Timing is also important: if the firewall needs to adjust partitions during the upgrade, the update may take longer than a normal maintenance release. Therefore, the maintenance window should not be planned too tightly.

4. Prepare backup and recovery

A fresh backup is needed before the upgrade. This sounds trivial, but it is crucial for major releases. The backup should not only be created but also be findable, decryptable, and assignable to a specific device. The article Create or Restore Sophos Firewall Backup explains the key points around backup, restore, and Secure Storage Master Key.

Before SFOS 22, at least these points should be completed:

• create and externally store the current configuration backup
• document the Secure Storage Master Key if encrypted backups are used
• check local and maintenance network admin access
• check license status and Sophos Central access
• have the current firmware image and target firmware ready
• define rollback decision: when to wait, when to roll back

For critical locations, it should also be clear who has access to the appliance on-site and how to perform a reimage if necessary. Reinstallation is a different procedure than a normal firmware update. There is a separate guide for this: Reinstall Sophos Firewall OS.

5. Define Go/No-Go before the maintenance window

An SFOS-22 upgrade should not be decided only during the maintenance window. It must be clear beforehand under what conditions to start, wait, abort, or roll back. This reduces hasty decisions if the firewall takes longer, an HA node does not synchronize, or a critical service does not work after the restart.

Meaningful Go/No-Go points:

For distributed locations, it should also be clear who is reachable during the maintenance window: technical contact person, site contact, person with physical access, and decision-maker for rollback. If the upgrade is performed remotely, it should also be checked whether alternative access is available if VPN, WAN, or Central Management temporarily does not work.

A fallback plan is not a weakness of the change. It prevents simultaneous changes to firmware, routing, VPN, HA, and switching during a disruption. If a critical service fails after the upgrade, the defined validation plan should be worked through first. Only then is it decided whether a rollback, a restore, a reimage, or targeted troubleshooting is more sensible.

6. Properly prepare HA cluster

In HA clusters, not only the active firewall should be considered. Both nodes must be supported, have the same sensible initial state, and synchronize cleanly. An upgrade on an already compromised HA cluster increases the risk of unnecessary outages.

Before the maintenance window, check:

• System services > High availability shows a healthy HA status.
• Both appliances are the same model or a supported HA combination.
• Firmware status, license status, and subscription are plausible.
• HA link, monitored ports, and connected switch ports are stable.
• It is documented which device was active before the upgrade.

For general HA planning and the specifics of Active-Passive, Active-Active, licensing, and maintenance, see the article Sophos Firewall HA Cluster Variants.

7. Search for Legacy Remote Access IPsec

From SFOS 22.0 MR1, Legacy Remote Access IPsec VPN is no longer supported. Firewalls with this legacy configuration cannot be updated to SFOS 22.0 MR1 or later. This is a typical upgrade blocker because Remote Access IPsec is often set up once in older environments and then not touched for a long time.

Before the upgrade, check whether old Remote Access IPsec configurations are present. If so, they must first be migrated to the current Remote Access IPsec configuration, SSL VPN, ZTNA, or another suitable remote access design. The specific procedure is in Migrate Legacy Remote Access IPsec before SFOS 22 MR1. For general IPsec troubleshooting, Sophos Firewall IPsec VPN Troubleshooting is also helpful.

Practical steps:

1. Open the Remote access VPN section in WebAdmin.
2. Check whether a Legacy Remote Access IPsec configuration is present.
3. Document affected users, profiles, pools, authentication, and distributed Sophos Connect configurations.
4. Plan replacement configuration and test with a few test users.
5. Only after successful migration, remove the legacy configuration and recheck the firmware upgrade.

If Sophos Connect is used, the existing instructions for Sophos Connect Firewall Configuration, Windows Installation, and macOS Installation should also be included.

8. Check policy-based IPsec and NAT

SFOS 22.0 GA and later versions change the behaviour of policy-based Site-to-Site IPsec VPN. Additionally, the SFOS-22 release notes document a resolved issue where policy-based IPsec traffic could fail if the default SNAT rule was configured with a static IP address instead of MASQ.

This is not a reason to rebuild every IPsec setup in advance. However, it is a good reason to consciously test policy-based IPsec before and after the upgrade. This is especially important if the firewall uses multiple VPNs, overlapping networks, specific SNAT rules, a customized default SNAT rule, or partner networks with fixed source IP expectations.

Before the upgrade, check:

1. Identify policy-based Site-to-Site tunnels.
2. Document local and remote networks or traffic selectors.
3. Check NAT rules on VPN traffic, especially default SNAT, MASQ, specific SNAT rules, and rule order.
4. Define a test case with source, destination, service, and expected direction for each important tunnel.
5. Document peer and return path so that a post-upgrade test does not just mean “Ping does not work”.

After the upgrade, these tests should not be mixed with broad aggregate checks. A narrow test per tunnel is better: compare Log Viewer, Packet Capture, Firewall Rule ID, NAT Rule ID, and byte counter in ipsec statusall. If the tunnel is green but no user traffic flows, Sophos Firewall IPsec VPN Troubleshooting is suitable. For NAT classification, Understanding NAT on Sophos Firewall helps.

9. Check STAS and user-based rules

If STAS is active, it should not just be checked off as “works in everyday life” before SFOS 22.0 MR1 or later. The Known Issues list documents a problem where the option Restrict client traffic during identity probe can block an upgrade to SFOS 22.0 MR1 or lead to repeated identity probes with short traffic interruptions after the upgrade.

This mainly affects environments where STAS is used not only for reporting but for productive user-based firewall rules. If the user IP assignment briefly fails, it quickly looks like a rule, DNS, or application problem in operation.

Before the upgrade, check:

1. Open Authentication > STAS.
2. Check STAS status and used collectors.
3. Check whether Restrict client traffic during identity probe is active.
4. Identify user-based rules that depend on STAS.
5. Log in test users and check Live Users and Log Viewer.

If this option is active or short interruptions are already noticeable, this point should be clarified before the maintenance window. The detailed procedure is in Set up STAS on Sophos Firewall.

10. Validate specifically after the upgrade

After the restart, the upgrade is not automatically complete. Only when the most important operational functions have been checked is the maintenance window properly concluded.

At least check:

• correct firmware version is active
• Network > Interfaces shows physical and logical interfaces plausibly
• Internet access and central firewall rules work
• Site-to-Site VPN and Remote Access VPN work
• policy-based IPsec tests show the expected source IP and appropriate NAT rule
• HA status is synchronized again
• STAS, AD SSO, or other user assignment works if used productively
• Sophos Central Management and Reporting send data
• Log Viewer shows no new critical errors
• important services like DNS, DHCP, Web Protection, IPS, and authentication run as expected

If VPN, routing, or rules do not work as expected, do not immediately change multiple places at once. First, narrow down with Log Viewer, Policy Test, Packet Capture, and the affected service logs. For structured troubleshooting, Test Firewall Rule with Log Viewer, Policy Test, and Packet Capture and Sophos Firewall Troubleshooting: Services and Logs are helpful additions.

11. Secure evidence and operational documentation

An upgrade is only cleanly completed when the result is traceably documented. This helps with later disruptions, audits, support cases, and the next maintenance window. Therefore, immediately after the upgrade, not only note “running again” but secure concrete evidence.

Meaningful evidence:

If changes were made to rules, interfaces, hosts, or services, the Audit Trail Logs should also be checked. In environments with longer log retention, a check of Central Firewall Reporting or syslog is also part of the conclusion.

For multiple firewalls, it is also important that backups can be clearly assigned. In newer SFOS versions, backup emails contain more identification data such as hostname, firmware version, serial number, and model. Nevertheless, an internal simple upgrade note should still be kept: firewall, location, old version, new version, time window, responsible person, test result, and open points.

If storage, hardware, or SSD notices appear after the upgrade, they should not be lost in the firmware ticket. For this check, Check SSD Health on Sophos Firewall is suitable.

Checklist for the maintenance window

Before the upgrade

• Platform and upgrade path checked
• Release notes and known notices read
• Interface names with ten or more trailing digits excluded
• Storage space and firmware notices checked
• Backup created and externally stored
• Secure Storage Master Key available
• Go/No-Go decision, fallback path, and responsible parties defined
• HA status documented
• Policy-based IPsec, VPN NAT, and test traffic documented, if used
• STAS and user-based rules checked, if used
• Legacy Remote Access IPsec excluded or migrated
• Rollback plan defined

During the upgrade

• Document status messages
• Do not make parallel changes to routing, VPN, or switching
• Observe failover and synchronization in HA clusters
• Adhere to decision point for waiting, error analysis, or rollback
• Do not blindly confirm unexpected messages, but check the cause

After the upgrade

• Check firmware version and license status
• Test VPN, routing, DNS, DHCP, and central firewall rules
• Check policy-based IPsec with defined source/destination test, if used
• Check STAS, AD SSO, and user-based rules with test user
• Check HA sync and Sophos Central connection
• Check Log Viewer and relevant service logs
• Secure firmware, HA, and audit evidence
• Document result and open points in the operations journal

FAQ