Sophos Firewall SFOS 22 Upgrade Check: Find Blockers

Before upgrading to SFOS 22, confirm that the platform, upgrade path, and configuration support the target release. This check covers SFOS 22.0 MR2 Build 546 from July 14, 2026 and complements the general Sophos Firewall firmware update guide.

Hard upgrade and restore blockers

• XG or SG hardware: SFOS 22 is not supported. Instead of upgrading, migrate to XGS or to a virtual, software, or cloud platform.
• Legacy Remote Access IPsec: From SFOS 22.0 MR1, the configuration must be migrated or removed before the upgrade.
• Legacy CLI VLAN Tagging on a bridge interface: From SFOS 22.0 MR2, system vlan-tag must be replaced with supported VLAN interfaces.
• Backup with Legacy VLAN Tagging: To restore to SFOS 22.0 GA or later, clean up the source configuration and create a new backup.
• Storage or upgrade path: If the firmware page reports insufficient storage or an invalid upgrade path, resolve the cause first.

If a blocker applies or any point remains unclear, do not start the upgrade.

Direct upgrade path to SFOS 22.0 MR2

For the target covered here, SFOS 22.0 MR2 Build 546, Sophos supports a direct upgrade from the following versions:

• SFOS 22.0: MR1 Build 490 and GA Build 411 or 365
• SFOS 21.5: MR2 Build 323, MR1 Build 261, or GA Build 171
• SFOS 21.0: MR2 Build 349, MR1 Build 277, 272, or 237, and GA Build 169
• Older versions: any SFOS 20.0, 19.5, or 19.0 version

⚠️ If the current version is not on this list, do not confirm the warning for an unsupported migration. Otherwise, the firewall restarts with factory settings and the current configuration is lost. A backup can likewise be restored only from a version whose configuration migration is supported.

For an older or unlisted version, a supported intermediate path must be planned first. The version list also does not replace the other checks: platform, storage, legacy dependencies, and the restore plan must all be suitable.

Check before the maintenance window

Platform and legacy dependencies

• Document the model and current firmware so that the upgrade path listed above and a possible restore remain traceable.
• Treat XG and SG hardware as a migration, not a normal upgrade.
• Replace UTM9 SSL VPN tunnels and RED 15, RED 15w, and RED 50 before the upgrade.
• Under Network > Interfaces, correct names that end in ten or more digits. Such names can hide interfaces in WebAdmin after the upgrade.

Storage, backup, and access

Partition usage can be checked roughly in the Advanced Shell:

df -kh

If the firmware page shows a warning, do not start the upgrade yet. The reference code identifies the cause and the next step:

• FWDS501: The Primary Disk or one of its system partitions is too small for SFOS 22. On a VM deployed before SFOS 18, the same legacy condition may initially appear only as a generic firmware failure when upgrading to SFOS 21.5 or later (NC-151465); however, the message alone does not prove a disk issue. For a virtual firewall, enlarge the Primary Disk before SFOS 22 shows how to check and expand Hard disk 1, then verify the result. The same article provides the relevant thresholds and resolutions for a Software Appliance.
• FWDS502: /var does not have enough free space. In 4. Device Console, system firmware check-disk-space shows the required space and the data areas involved. Reports or logs should only be cleaned up in a controlled manner after required data has been secured; the procedure is described under Check disk space and manage reports.
• FWDS503: The /content partition is too small. Sophos requires a factory reset with downtime and loss of the current configuration. After creating a fresh backup and securing the SSMK, enter RESET in uppercase through the serial console and select option 2; this deletes the custom configuration and resets the pattern signatures to the state of the active firmware. Then restore the backup, test the functions, and only then perform the upgrade. Local reports are not restored.
• FWDS504: The SSD firmware is outdated and must be updated before the SFOS upgrade.
• FWDS505: Sophos Support must verify the SSD health. A local SMART check can document values for Support, but it does not clear the blocker.

In an HA cluster, check each node separately because the two appliances may show different reference codes.

Before starting, also ensure the following are available:

• a fresh backup stored externally and the matching Secure Storage Master Key
• local administrator access or alternative access outside the normal VPN path
• a defined fallback path with an owner and decision point
• for HA, a healthy, synchronized cluster with stable HA links and Monitored Ports

Details on backup and recovery are available in Create or restore a Sophos Firewall backup.

Configurations with particular risk

Legacy Remote Access IPsec

From SFOS 22.0 MR1, an existing Legacy Remote Access IPsec configuration blocks the upgrade. Affected users, pools, and profiles must first be migrated to the current Remote Access IPsec configuration, SSL VPN, ZTNA, or another suitable design. The procedure is described in Migrate Legacy Remote Access IPsec before SFOS 22 MR1.

Microsoft Entra ID SSO with Same as firewall

SFOS 22.0 or later automatically turns on Microsoft Entra ID SSO for VPN Portal, Remote Access IPsec, and SSL VPN when their authentication method is set to Same as firewall before the upgrade. Therefore, record the settings under Authentication > Services and the Identity Provider that is actually expected before the maintenance window.

After the upgrade, check each effective method separately. If Entra SSO is intended, the exact VPN portal and remote access URL from the Entra server object must be configured as a redirect URI in the Entra app; the Sophos Central reverse SSO URL is incorrect for this purpose. A real pilot login verifies the portal, client, and MFA. If SSO is not intended, explicitly set the required method. The complete procedure is described in Set up Microsoft Entra ID SSO for Sophos Firewall VPN.

Policy-based IPsec and NAT

Production policy-based Site-to-Site tunnels should be checked before and after the upgrade with a specific test flow. This includes Source, Destination, Service, Traffic Selectors, the peer, and the expected firewall and NAT rule. For problems, see IPsec VPN troubleshooting and Understand NAT on Sophos Firewall.

Before the upgrade, also determine whether OSPF or BGP has been advertising remote policy-based VPN networks through redistribute kernel. Starting with SFOS 22, these networks are no longer available as ordinary kernel routes; SFOS 22: IPsec routes and redistribute kernel shows which prefixes to check before and after the upgrade and why a route-based XFRM design is better suited to dynamic routing.

SMTP via DNAT

If an internal mail server is published via DNAT, the maintenance plan should include several actual incoming test messages, not just a port test. Under NC-184583, Sophos lists sporadically dropped SMTP connections after an upgrade to SFOS 22.x; GA Respin Build 411 is explicitly listed as affected, and there is no public workaround. The exact version scope, evidence collection and Support escalation are described under Publishing a Server via DNAT on Sophos Firewall.

Let’s Encrypt and MR2 migration rollback

MR2 Build 546 supports the new Let’s Encrypt CAs YE Root, YE1, YE2, YR Root, YR1, and YR2. Independently of this, configuration migration failed in connection with a Let’s Encrypt certificate in use during two publicly documented upgrades from MR1 Build 490 to MR2 Build 546. The firewall automatically rolled back to MR1. After a Support Access review, Sophos confirmed a known migration blocker for certificates from a specific but not publicly defined issuance period. As of August 9, 2026, a public issue ID, a reliable pre-upgrade test, and a confirmed fix version are still unavailable.

Before upgrading an MR1 firewall with a recently issued or renewed Let’s Encrypt certificate, document the Issuer and service assignment under Certificates > Certificates. A YE/YR Issuer or the mere presence of these CAs under Certificate authorities does not prove the migration failure and, on its own, is not a general upgrade blocker. For a critical firewall, it is nevertheless advisable to coordinate the case with Sophos Support beforehand or postpone the upgrade until a public pre-upgrade test or fix is confirmed. Certificates and CAs must not be deleted or renamed on suspicion: a documented deletion attempt from the Community did not reliably resolve the failure, and the certificate may secure WAF, WebAdmin, portals, Hotspot, or SMTP TLS. Manage certificates on Sophos Firewall explains how to check assignments and prepare a safe replacement with a rollback path.

This migration rollback is not the same issue as an incomplete certificate chain delivered after renewal. Let’s Encrypt certificates on Sophos Firewall describes how to check this second symptom and the hotfix rolled out for it.

After an automatic rollback, the behavior matches the known issue if dbv22.004 and tblvpncertificate_caid_fkey appear in migration.log and the surrounding delete statement names YE/YR objects. These search terms help locate the relevant lines:

dbv22.004
tblvpncertificate_caid_fkey
Lets_Encrypt_YE
Lets_Encrypt_YR

If they appear, save migration.log, migrationhash.log, the firmware message, the time, and the source and target builds, and do not repeat the same upgrade attempt unchanged. Then check the source firmware, HA, WAN, routing, VPN, Central connection, and every certificate-dependent service. Save Sophos Firewall logs for Support describes the appropriate evidence path; with this information, Sophos Support can isolate the migration failure.

Legacy VLAN Tagging on bridges

Legacy CLI VLAN Tagging on bridge interfaces has three consequences:

• On GA and MR1, traffic from or to the firewall can fail while transit traffic continues.
• From MR2, the upgrade is blocked.
• An affected backup cannot be restored to SFOS 22.0 GA or later.

Before cleanup, document the bridge, VLAN IDs, IP addresses, zones, switch trunks, and dependent services. Then create supported VLAN interfaces with the bridge as Parent and generate a new backup. The special case is described in Check Sophos Firewall bridge VLANs before SFOS 22.

STAS

For an upgrade to MR1, set Restrict client traffic during identity probe to No under Authentication > STAS. MR2 fixes the MR1 issue and uses No as the default for new configurations; existing values and user-based rules should still be checked. See Configure STAS on Sophos Firewall for details.

Malware scanning when upgrading to GA Build 411

Only during a targeted upgrade to SFOS 22.0 GA Respin Build 411 can NC-177529 temporarily report Malware Unscannable during the migration, often for www.msftconnecttest.com, because the new Sophos scan engine is not yet available. Before this GA upgrade, switch from Single engine to Dual engine under Web > General settings, and switch back to the previous Single Engine after the upgrade has completed. This measure does not apply generally to MR1, MR2, or later releases; Configure and test Sophos Firewall malware scanning explains the background and scan engine selection.

Maintenance window and validation

• Before: Rule out blockers, have the backup and SSMK available, check HA synchronization, and document VPN, test, and fallback paths.
• During: Do not make parallel changes to routing, VPN, or switching; monitor status and HA failover.
• After: Check firmware, interfaces, internet access, firewall rules, VPN, NAT, HA, STAS, DNS, DHCP, Central, and Log Viewer.

A green tunnel or a successful Policy Test does not prove that production traffic works. Test critical connections with real packets, Log Viewer, Packet Capture, and the Firewall and NAT Rule ID. When problems occur, do not change several areas at the same time.

The upgrade is complete when the defined tests succeed and the target version, HA status, test results, and outstanding follow-up work have been documented.

FAQ