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

In short: the upgrade should only be started once platform, upgrade path, backup, storage, HA state, VPN dependencies, and a fallback path are clarified in writing. If any of these points remains unclear, the maintenance window is usually scheduled too early.

Before the maintenance window, these areas in particular must be clear:

• Platform: XGS, virtual, software, or cloud deployment instead of XG/SG hardware.
• Firmware path: Check source version and direct upgrade path against the release notes.
• Configuration: Secure backup, Secure Storage Master Key, and access outside the normal VPN path.
• Network: Document interface names, policy-based IPsec, NAT, and critical test flows.
• Operations: Prepare HA status, STAS, Central Management, logs, and rollback decision.

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
• UTM9 SSL VPN tunnels or old RED 15, RED 15w, or RED 50 devices are still present
• policy-based Site-to-Site IPsec, specific SNAT rules, or VPN NAT rules are in use
• bridges with VLAN tags manually set via CLI or VLAN traffic to the firewall itself 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.

For migrations to XGS, virtual or cloud appliances, backup/restore is often part of the project. Backups from supported source versions can be migrated to other platforms; with newer backups, Sophos supports restore with an assistant for interface mapping. This does not replace migration planning, but it is important so that XG/SG replacement is not confused with an in-place upgrade.

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:

• VLAN_1234567890: ends with ten digits.
• Branch_1000000001: branch name can disrupt display.
• PortA_2026010101: intended to be descriptive, but risky number ending.

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 legacy dependencies

When upgrading from older SFOS versions towards 22, it is easy to miss the notes from SFOS 21.5. This is risky because some restrictions already apply from 21.5 GA and therefore also affect the SFOS 22 upgrade path.

Before the maintenance window, these legacy dependencies should either be ruled out or consciously migrated:

• UTM9 SSL VPN: Firewalls from 21.5 GA no longer establish SSL VPN tunnels to UTM9 OS. Such connections should be migrated to SFOS 20.0 MR1 or later, Site-to-Site IPsec, or RED.
• RED 15, RED 15w and RED 50: These legacy RED devices are no longer supported from 21.5 GA. If sites still depend on them, the replacement belongs before the firewall upgrade.
• Legacy Remote Access IPsec: From SFOS 22.0 MR1, this old Remote Access IPsec configuration blocks the upgrade. This point is checked separately below.

These dependencies are not just “old devices in the inventory”. They determine whether branch offices, remote users, or transitional connections are still reachable after the upgrade. For RED or UTM9 dependencies, a separate migration plan should exist before the SFOS 22 window.

4. 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.

For virtual and software-based firewalls, check especially carefully whether the provisioned virtual disk and the root or primary partition fit the planned SFOS 22 upgrade. Sophos provides separate notes on the SFOS 22 storage requirement and extending virtual disks in support articles KBA-000010091 and KBA-000043681. These links are useful if a virtual disk actually has to be adjusted, but the change should not be improvised during the firmware window.

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. Sophos mentions additional minutes during the upgrade depending on the environment; the maintenance window should therefore not be planned too tightly.

If a virtual disk must be extended, clarify backup, Secure Storage Master Key, hypervisor snapshot strategy, datastore capacity, and fallback path first. After the adjustment, check the partitions again and only then repeat the SFOS 22 upgrade attempt. For general storage analysis, Check Sophos Firewall storage and manage reports fits.

5. 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.

6. 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:

• Platform supports SFOS 22: Go if model and upgrade path are checked. No-Go for XG/SG hardware or an unclear upgrade path.
• Backup and SSMK: Go if the backup is externally stored and restore data is available. No-Go if the backup is missing, cannot be found, or the Secure Storage Master Key is missing.
• Remote Access IPsec: Go if legacy configuration is excluded or migrated. No-Go if legacy configuration is present or remains unclear.
• Legacy locations: Go if UTM9 SSL VPN and old RED devices are excluded or replaced. No-Go if a branch office still depends on them productively.
• Site-to-Site IPsec: Go if policy-based IPsec, NAT, and test traffic are documented. No-Go if Traffic Selectors, SNAT, or peer are unclear.
• Bridge VLANs: Go if bridge VLAN traffic to the firewall itself has been checked or modeled cleanly through VLAN interfaces. No-Go if AD, DNS, Device Access, or STAS runs through unclear bridge CLI VLAN tags.
• HA status: Go if the cluster is stable and synchronized. No-Go for degraded, unsynchronized, or unclear HA state.
• Access: Go if local admin access and maintenance network are checked. No-Go if access depends only on an insecure remote path.
• Rollback: Go if decision point and responsible parties are defined. No-Go if no one makes a binding decision on waiting or rolling back.

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.

7. 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.

8. 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.

9. 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.

10. Check Bridge VLANs and traffic to the firewall

Another SFOS 22 special case concerns bridge interfaces with VLAN tags that were previously set through the CLI. In SFOS 22.0 GA and 22.0 MR1, a Known Issue is documented: VLAN-tagged traffic that originates from the firewall itself or is destined to the firewall itself may not be processed correctly over such bridge configurations. Normal transit traffic through the bridge can continue to work at the same time.

This is tricky because exactly the wrong things can fail: Active Directory, DNS, Device Access, STAS, LDAP, RADIUS or management access. It can quickly look like an authentication, DNS or rule problem even though the cause is in the bridge/VLAN model.

Practical check:

1. Document bridges and VLAN usage under Network > Interfaces.
2. Clarify whether VLAN tags were previously set by CLI on a bridge interface.
3. Identify whether AD, DNS, RADIUS, LDAP, STAS, Device Access or management traffic uses these VLAN paths.
4. If the special case applies, plan VLAN interfaces with the bridge interface as parent before the upgrade.
5. After the upgrade, specifically test traffic from and to the firewall, not only client-to-server traffic through the bridge.

The special case is described in more detail in Check Sophos Firewall Bridge VLANs before SFOS 22. For normal zone, interface, VLAN and bridge planning, Configure Sophos Firewall zones and interfaces remains the better starting point.

11. 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.

12. 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 several places at once. First narrow down the issue with Log Viewer, Packet Capture and the affected service logs. Policy Test is useful, but should be read carefully with SFOS 22.0 GA and SFOS 22.0 MR1: Sophos documents a Known Issue where the tool can show blocked or incorrectly matched traffic even though production traffic flows correctly. In this case, real test packets, Log Viewer, Packet Capture, Rule ID and NAT Rule ID are more important than a single Policy Test result.

For structured troubleshooting, Test firewall rules with Log Viewer, Policy Test and Packet Capture and Sophos Firewall troubleshooting: services and logs are useful additions.

13. 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:

• Screenshot of Backup & Firmware > Firmware: shows target version, active firmware, and any available images.
• Screenshot of System services > High availability: shows HA role, synchronization, and cluster status after the upgrade.
• Export or screenshot of relevant audit logs: shows which changes were made during the maintenance window.
• Central or syslog check: shows whether logs and reports continue to arrive after the upgrade.
• List of open follow-ups: prevents temporary workarounds from being permanently forgotten.

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
• UTM9 SSL VPN tunnels and old RED devices excluded or migrated
• 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
• Bridge VLANs and traffic to the firewall itself checked, if bridges are 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
• Test bridge VLAN traffic to AD, DNS, Device Access, STAS, or management, if relevant
• 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