Sophos Firewall SFOS 22 Upgrade-Check: Blocker prüfen

Vor einem Upgrade auf SFOS 22 muss geklärt sein, ob Plattform, Upgradepfad und Konfiguration das Zielrelease unterstützen. Dieser Check berücksichtigt SFOS 22.0 MR2 Build 546 vom 14. Juli 2026 und ergänzt die allgemeine Anleitung zum Sophos Firewall Firmware Update.

Harte Upgrade- und Restore-Blocker

• XG- oder SG-Hardware: SFOS 22 wird nicht unterstützt. Statt eines Upgrades ist eine Migration auf eine XGS Appliance, eine virtuelle oder eine Software- beziehungsweise Cloud-Plattform erforderlich.
• Legacy Remote Access IPsec: Ab SFOS 22.0 MR1 muss die Konfiguration vor dem Upgrade migriert oder entfernt werden.
• Legacy CLI VLAN Tagging auf einem Bridge-Interface: Ab SFOS 22.0 MR2 muss system vlan-tag durch unterstützte VLAN-Interfaces ersetzt werden.
• Backup mit Legacy VLAN Tagging: Für einen Restore auf SFOS 22.0 GA oder neuer muss die Quellkonfiguration bereinigt und ein neues Backup erstellt werden.
• Speicher oder Upgradepfad: Meldet die Firmwareseite zu wenig Speicher oder einen ungültigen Upgradepfad, muss die Ursache zuerst behoben werden.

Trifft ein Blocker zu oder bleibt ein Punkt unklar, sollte das Upgrade nicht gestartet werden.

Die Blocker oben sind von den folgenden Hinweisen zu unterscheiden: NC-177529, NC-181885 und NC-184583 betreffen nur die jeweils genannte Version oder Funktion. Der Let’s-Encrypt-Fall weiter unten ist dagegen ein nicht offiziell bestätigter Bericht und kein von Sophos veröffentlichter allgemeiner Blocker.

Direkter Upgradepfad auf SFOS 22.0 MR2

Für das hier behandelte Ziel SFOS 22.0 MR2 Build 546 unterstützt Sophos ein direktes Upgrade aus folgenden Versionen:

• SFOS 22.0: MR1 Build 490 sowie GA Build 411 oder 365
• SFOS 21.5: MR2 Build 323, MR1 Build 261 oder GA Build 171
• SFOS 21.0: MR2 Build 349, MR1 Build 277, 272 oder 237 sowie GA Build 169
• Ältere Versionen: jede SFOS-20.0-, 19.5- oder 19.0-Version

⚠️ Steht die aktuelle Version nicht in dieser Liste, darf die Warnung für eine nicht unterstützte Migration nicht bestätigt werden. Die Firewall startet sonst mit Werkseinstellungen neu und die aktuelle Konfiguration geht verloren. Ein Backup lässt sich ebenfalls nur aus einer Version wiederherstellen, deren Konfigurationsmigration unterstützt wird.

Bei einer älteren oder nicht aufgeführten Version muss zuerst ein unterstützter Zwischenpfad geplant werden. Die Versionsliste ersetzt ausserdem keine der übrigen Prüfungen: Plattform, Speicher, Altlasten und Restore-Plan müssen ebenfalls passen.

Vor dem Wartungsfenster prüfen

Plattform und Altlasten

• Modell und aktuelle Firmware dokumentieren, damit der oben genannte Upgradepfad und ein möglicher Restore nachvollziehbar bleiben.
• XG- und SG-Hardware nicht als normales Upgrade, sondern als Migration behandeln.
• UTM9-SSL-VPN-Tunnel sowie RED 15, RED 15w und RED 50 vor dem Upgrade ablösen.
• Unter Network > Interfaces Namen korrigieren, die mit zehn oder mehr Ziffern enden. Solche Namen können Interfaces nach dem Upgrade im WebAdmin ausblenden.

Speicher, Backup und Zugriff

Unter Backup & Firmware > Firmware zuerst Current firmware und die Versions- und Buildnummer des aktiven Slots dokumentieren. Unter Latest available firmware beziehungsweise beim manuell hochgeladenen Image muss als Ziel ausdrücklich SFOS 22.0 MR2 Build 546 stehen. Download lädt das angebotene Image nur herunter; Install startet den Versionswechsel. Beim manuellen Weg lädt Upload Firmware das Image nur in den inaktiven Slot, während Upload & Boot sofort neu startet. Vor dem Klick deshalb Zielbuild, Aktion und aktiven Slot ein zweites Mal prüfen.

Den Partitionsfüllstand kann man in der Advanced Shell ergänzend grob prüfen:

df -kh

Erscheint auf Backup & Firmware > Firmware eine Warnung, wird das Upgrade noch nicht gestartet. Der dort angezeigte Reference code nennt die Ursache und den nächsten Schritt:

• FWDS501: Die Primary Disk oder eine der Systempartitionen ist für SFOS 22 zu klein. Bei einer vor SFOS 18 bereitgestellten VM kann NC-151465 beim Upgrade auf SFOS 21.5 oder neuer zunächst nur als allgemeiner Firmwarefehler erscheinen. Diese Meldung allein bestätigt den Diskfehler nicht. Bei einer virtuellen Firewall zeigt Primary Disk vor SFOS 22 vergrössern, wie Hard disk 1 geprüft, vergrössert und das Ergebnis kontrolliert wird. Für eine Software Appliance stehen im selben Artikel die passenden Grenzwerte und Lösungen.
• FWDS502: In /var fehlt freier Speicher. In 4. Device Console zeigt system firmware check-disk-space den benötigten Platz und die beteiligten Datenbereiche. Reports oder Logs sollten erst nach der Sicherung benötigter Daten kontrolliert bereinigt werden; der Ablauf steht unter Speicherplatz prüfen und Reports verwalten.
• FWDS503: Die /content-Partition ist zu klein. Sophos verlangt einen Werksreset mit Ausfall und Verlust der aktuellen Konfiguration. Nach einem frischen Backup und der Sicherung des SSMK über die serielle Konsole RESET in Grossbuchstaben eingeben und Option 2 wählen; dadurch werden die eigenen Konfigurationen gelöscht und die Pattern-Signaturen auf den Stand der aktiven Firmware zurückgesetzt. Danach das Backup wiederherstellen, die Funktionen prüfen und erst dann aktualisieren. Lokale Reports werden nicht wiederhergestellt.
• FWDS504: Die SSD-Firmware ist veraltet und muss vor dem SFOS-Upgrade aktualisiert werden.
• FWDS505: Die SSD-Gesundheit muss durch Sophos Support geprüft werden. Ein eigener SMART-Check kann Werte für den Support dokumentieren, hebt den Blocker aber nicht auf.

In einem HA-Cluster muss jeder Node separat geprüft werden, da die beiden Appliances unterschiedliche Referenzcodes anzeigen können.

Vor dem Start müssen ausserdem vorhanden sein:

• frisches, extern gespeichertes Backup und der passende Secure Storage Master Key
• lokaler Admin-Zugang oder alternativer Zugriff ausserhalb des normalen VPN-Pfads
• definierter Rückfallweg mit verantwortlicher Person und Entscheidungspunkt
• bei HA ein gesunder, synchroner Cluster mit stabilen HA-Links und Monitored Ports

Details zu Backup und Wiederherstellung stehen in Sophos Firewall Backup erstellen oder wiederherstellen.

Konfigurationen mit besonderem Risiko

Legacy Remote Access IPsec

Ab SFOS 22.0 MR1 blockiert eine vorhandene Legacy-Remote-Access-IPsec-Konfiguration das Upgrade. Betroffene Benutzer, Pools und Profile müssen zuerst auf die aktuelle Remote-Access-IPsec-Konfiguration, SSL VPN, ZTNA oder ein anderes passendes Design migriert werden. Der Ablauf steht in Legacy Remote Access IPsec vor SFOS 22 MR1 migrieren.

Microsoft Entra ID SSO bei Same as firewall

SFOS 22.0 oder neuer aktiviert Microsoft Entra ID SSO für VPN Portal, Remote Access IPsec und SSL VPN automatisch, wenn deren Authentifizierungsmethode vor dem Upgrade auf Same as firewall steht. Vor dem Wartungsfenster werden deshalb die Einstellungen unter Authentication > Services sowie der tatsächlich erwartete Identity Provider dokumentiert.

Nach dem Upgrade werden die effektiven Methoden einzeln geprüft. Ist Entra SSO beabsichtigt, muss die exakte VPN portal and remote access URL aus dem Entra-Serverobjekt in der Entra-App als Redirect URI stehen; die Sophos-Central-Reverse-SSO-URL ist dafür falsch. Ein echter Pilot-Login bestätigt Portal, Client und MFA. Ist SSO nicht beabsichtigt, wird die gewünschte Methode ausdrücklich gesetzt. Den vollständigen Ablauf erklärt Microsoft Entra ID SSO für Sophos Firewall VPN einrichten.

Policy-based IPsec und NAT

Produktive policy-based Site-to-Site-Tunnel sollten vor und nach dem Upgrade mit einem konkreten Testfluss geprüft werden. Dazu gehören Source, Destination, Service, Traffic Selectors, Gegenstelle sowie die erwartete Firewall- und NAT-Regel. Bei Fehlern helfen IPsec VPN Troubleshooting und NAT auf Sophos Firewall verstehen.

Zusätzlich muss vor dem Upgrade geklärt werden, ob OSPF oder BGP entfernte policy-based VPN-Netze bisher über redistribute kernel ankündigt. Ab SFOS 22 stehen diese Netze nicht mehr als normale Kernel-Routen bereit; SFOS 22: IPsec-Routen und redistribute kernel zeigt, welche Präfixe vor und nach dem Upgrade geprüft werden und warum ein route-based XFRM-Design für dynamisches Routing besser passt.

SMTP über DNAT

Wird ein interner Mailserver über DNAT veröffentlicht, sollte der Wartungsplan mehrere echte eingehende Testnachrichten und nicht nur einen Porttest enthalten. Sophos führt unter NC-184583 sporadisch abgebrochene SMTP-Verbindungen nach einem Upgrade auf SFOS 22.x; als betroffene Version ist ausdrücklich GA Respin Build 411 aufgeführt. Die offizielle Known-Issues-Liste verweist für den Workaround an Sophos Support, veröffentlicht die Schritte aber nicht. Die genaue Versionsabgrenzung, Beweissicherung und Support-Eskalation stehen unter Server per DNAT auf Sophos Firewall veröffentlichen.

Let’s Encrypt und MR2-Migrationsrollback

MR2 Build 546 unterstützt laut Release Notes die neuen Let’s-Encrypt-CAs YE Root, YE1, YE2, YR Root, YR1 und YR2. Davon getrennt berichten zwei öffentlich dokumentierte Community-Fälle von einer abgebrochenen Konfigurationsmigration bei Upgrades von MR1 Build 490 auf MR2 Build 546, während ein Let’s-Encrypt-Zertifikat verwendet wurde; die Firewalls rollten automatisch auf MR1 zurück. Dieser Zusammenhang ist in den öffentlichen Release Notes und der Known-Issues-Liste nicht als Issue bestätigt. Stand 5. September 2026 gibt es deshalb weder eine offizielle Issue-ID noch einen verlässlichen Vorabtest oder eine bestätigte Fix-Version.

Vor dem Upgrade sollte bei einer MR1-Firewall mit kürzlich ausgestelltem oder erneuertem Let’s-Encrypt-Zertifikat unter Certificates > Certificates der Wert Issued by sowie jede Dienstzuweisung dokumentiert werden. Ein YE-/YR-Issuer oder die blosse Existenz dieser CAs unter Certificates > Certificate authorities beweist den gemeldeten Migrationsfehler nicht und ist allein kein Upgradeblocker. Bei einer kritischen Firewall kann Sophos Support den Einzelfall vorab bewerten; ohne offizielle Bestätigung bleibt auch eine Verschiebung eine betriebliche Risikoentscheidung. Zertifikate und CAs dürfen nicht auf Verdacht gelöscht oder umbenannt werden: Ein dokumentierter Löschversuch aus der Community beseitigte den Fehler nicht zuverlässig, und das Zertifikat kann WAF, WebAdmin, Portale, Hotspot oder SMTP TLS absichern. Wie sich Zuweisungen und ein sicherer Ersatz mit Rückweg prüfen lassen, erklärt Zertifikate auf Sophos Firewall verwalten.

Dieser Migrationsrollback ist nicht derselbe Fehler wie eine unvollständig ausgelieferte Zertifikatskette nach der Erneuerung. Die Prüfung dieses zweiten Fehlerbilds und den dazu ausgerollten Hotfix beschreibt Let’s-Encrypt-Zertifikate auf Sophos Firewall.

Nach einem automatischen Rollback passt das gemeldete Fehlerbild, wenn dbv22.004 und tblvpncertificate_caid_fkey in migration.log erscheinen und die umgebende Löschanweisung YE-/YR-Objekte nennt. Diese Suchbegriffe helfen beim Auffinden:

dbv22.004
tblvpncertificate_caid_fkey
Lets_Encrypt_YE
Lets_Encrypt_YR

Treffen sie zu, sollten migration.log, migrationhash.log, Firmwaremeldung, Uhrzeit sowie Ausgangs- und Zielbuild gesichert und keine unveränderten Upgradeversuche wiederholt werden. Danach Ausgangsfirmware, HA, WAN, Routing, VPN, Central-Verbindung und alle zertifikatsabhängigen Dienste prüfen. Sophos-Firewall-Logs für Support sichern zeigt den passenden Beweisweg; mit diesen Daten kann Sophos Support den Migrationsfehler abgrenzen.

Legacy VLAN Tagging auf Bridges

Legacy CLI VLAN Tagging auf Bridge-Interfaces hat drei Folgen:

• Unter GA und MR1 kann Traffic von oder zur Firewall ausfallen, während Transit-Traffic weiterläuft.
• Ab MR2 wird das Upgrade blockiert.
• Ein betroffenes Backup lässt sich nicht auf SFOS 22.0 GA oder neuer wiederherstellen.

Vor einer Bereinigung müssen Bridge, VLAN IDs, IP-Adressen, Zonen, Switch-Trunks und abhängige Dienste dokumentiert werden. Danach werden unterstützte VLAN-Interfaces mit der Bridge als Parent erstellt und ein neues Backup erzeugt. Der Spezialfall ist in Sophos Firewall Bridge-VLANs vor SFOS 22 prüfen beschrieben.

STAS

Bei einem Upgrade auf MR1 muss unter Authentication > STAS die Option Restrict client traffic during identity probe auf No stehen. MR2 behebt den MR1-Fehler und verwendet für neue Konfigurationen No als Standard; bestehende Werte und benutzerbasierte Regeln sollten trotzdem geprüft werden. Mehr dazu steht in STAS auf Sophos Firewall einrichten.

Malware-Scan beim Upgrade auf GA Build 411

Nur bei einem gezielten Upgrade auf SFOS 22.0 GA Respin Build 411 kann NC-177529 während der Migration vorübergehend Malware Unscannable melden, häufig für www.msftconnecttest.com, weil die neue Sophos-Scan-Engine noch nicht verfügbar ist. Vor diesem GA-Upgrade unter Web > General settings von Single engine auf Dual engine wechseln und nach abgeschlossenem Upgrade wieder die vorherige Single Engine einstellen. Die Massnahme gilt nicht pauschal für MR1, MR2 oder spätere Releases; die Hintergründe und Scan-Engine-Auswahl erklärt Sophos Firewall Malware-Scanning konfigurieren und testen.

Wartungsfenster, Abnahme und Rückfall

• Vorher: Blocker ausschliessen, Backup und SSMK bereitstellen, HA-Synchronisation prüfen sowie Ausgangsversion, aktiven Slot, Zielbuild, VPN-, Test- und Rückfallwege dokumentieren.
• Währenddessen: Keine parallelen Änderungen an Routing, VPN oder Switching durchführen; Status und HA-Failover beobachten. Nach der Neuanmeldung unter Backup & Firmware > Firmware prüfen, dass Current firmware tatsächlich MR2 Build 546 zeigt; in HA zusätzlich Version, Rolle und Synchronisation beider Nodes kontrollieren.
• Nachher: Interfaces und WAN, Internet, DNS, DHCP, Central, HA, STAS, Authentifizierung, Firewallregeln, VPN, NAT und veröffentlichte Dienste mit den vorher definierten Testflüssen prüfen. Log Viewer und Packet Capture müssen dabei die erwartete Firewall- und NAT-Rule-ID zeigen.

Ein grüner Tunnel oder ein erfolgreicher Policy Test beweist noch keinen funktionierenden Nutztraffic. Kritische Verbindungen deshalb mit echten Paketen, Log Viewer, Packet Capture sowie Firewall- und NAT Rule ID prüfen. Bei Problemen nicht mehrere Bereiche gleichzeitig ändern.

Vor dem Fenster wird ein Zeitpunkt festgelegt, bis zu dem ein Ausfall analysiert werden darf. Bleiben WAN, HA, zentrale VPNs oder produktionskritische Veröffentlichungen danach instabil, unter Backup & Firmware > Firmware beim vorherigen kompatiblen Slot Boot firmware image wählen. Dieser manuelle Rückfall aktiviert die Firmware und den zugehörigen älteren Konfigurationsstand dieses Slots; Änderungen seit dem Upgrade können verloren gehen. Er ist weder bei einem nicht unterstützten Upgradepfad noch als Ersatz für Backup, SSMK und einen Reimage-Weg einzuplanen. Nach dem Rückfall aktive Version, HA, WAN, Routing, VPN, NAT, DNS, DHCP, Central und Logging erneut testen und die Migrationslogs vor einem neuen Versuch sichern.

Das Upgrade ist abgeschlossen, wenn die definierten Tests erfolgreich sind und Zielversion, HA-Status, Testergebnisse sowie offene Nacharbeiten dokumentiert wurden.

FAQ