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 ergänzt den bisherigen Stand SFOS 22.0 MR2 Build 546 vom 14. Juli 2026 um die Release-Hinweise zu 22.0 MR3 Build 576 vom 16. Oktober 2026 und begleitet 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.

Zielrelease und Upgradepfad festlegen

Stand 21. Oktober 2026: SFOS 22.0 MR3 Build 576 ist veröffentlicht. Von diesem Build ist ein Upgrade auf SFOS 23.0 EAP1 ausdrücklich nicht möglich. Wer einen v23-Piloten plant, muss deshalb vor dem MR3-Wechsel den weiteren Versionspfad klären; ein pauschales «erst auf die neueste v22, danach auf v23» ist für EAP1 falsch. Daraus folgt keine Empfehlung, notwendige Produktionskorrekturen zugunsten eines EAP-Tests auszulassen.

Die folgende Liste dokumentiert weiterhin nur den direkten Pfad auf MR2 Build 546. Für MR3 oder ein späteres Ziel muss die zum genauen Zielbuild gehörende Upgrade-Matrix geprüft werden; diese MR2-Liste ist keine Freigabe dafür.

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 genau der zuvor freigegebene Zielbuild stehen. Soll ausdrücklich der zuvor dokumentierte MR2-Pfad verwendet werden, ist dies SFOS 22.0 MR2 Build 546; für MR3 muss dessen eigene Upgrade-Matrix freigegeben sein. 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 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

Unterbruch und HA-Ablauf planen

Bei einer einzelnen Firewall wird die neue Firmware installiert und durch einen Neustart aktiviert; bis der Neustart abgeschlossen ist, ist der Verkehr unterbrochen. Auch HA ist kein Versprechen für ein unterbruchfreies Upgrade. Beide Nodes müssen erreichbar, gesund und synchron sein und jeweils die Speicher- und SSD-Anforderungen erfüllen. Schon ein nicht geeigneter Node kann den gesamten Wechsel blockieren.

Den HA-Upgradevorgang nur auf dem Primary starten, nicht separat auf dem Auxiliary. Der Cluster aktualisiert zuerst den Auxiliary, schaltet den Verkehr auf ihn um und aktualisiert danach den bisherigen Primary. Abhängig vom Preferred Primary kann anschliessend ein Failback erfolgen. Für beide Umschaltungen kurze Unterbrüche einplanen. Die konkrete Durchführung und der manuelle Upload für Offline-Umgebungen stehen in der Firmware-Update-Anleitung.

Ein zusätzlicher Neustart vor dem Upgrade ist nur eine optionale Möglichkeit, den Memory Cache zu leeren, keine Voraussetzung und keine Reparatur ungeklärter Instabilität. Er erzeugt einen weiteren Unterbruch; vorher relevante Logs sichern und den Management-Rückweg prüfen. Die allgemeine Update-Vorbereitung erklärt die Systemzustandskontrolle. Die Speicher- und SSD-Prüfungen gelten auch für SFOS 22.0 und spätere Versionen; der oben aufgeführte direkte Upgradepfad gilt dagegen ausschliesslich für MR2 Build 546, nicht für SFOS 23 oder andere Zielbuilds.

Fehlgeschlagenes Upgrade sicher einordnen

Ab SFOS 20.0 kann die Firewall bei bestimmten Fehlern der Konfigurationsmigration automatisch auf die bisherige Firmware und deren Konfiguration zurückkehren. Das schützt den funktionierenden Stand, garantiert aber weder einen Rückfall bei jedem Fehler noch einen erfolgreichen nächsten Versuch. Zunächst den Vorgang beziehungsweise einen möglichen automatischen Rückfall abwarten, danach aktive Version, Systemzustand, Speicher und bei HA beide Nodes prüfen. Migrationslogs sichern, Ursache und unterstützten Pfad klären und erst dann einen neuen Versuch planen; bei unklarem Befund Sophos Support einbeziehen. Die Firmware-Update-Anleitung beschreibt die Grenzen des automatischen Rollbacks und die Fehlersuche, auch wenn Firmware, Patterns oder Hotfixes wegen Verbindungsproblemen oder blockierter Update-Dienste nicht ankommen.

Vor einem manuellen HA-Rückfall muss auf beiden Nodes dieselbe kompatible inaktive Firmware vorhanden sein. Fehlt sie, nicht blind Boot firmware image ausführen, sondern den gesonderten HA-Rückweg aus der Firmware-Update-Anleitung planen. War im vorherigen Konfigurationsstand kein HA eingerichtet, starten beide Geräte nach dem Rückfall im Standalone-Status und HA muss neu eingerichtet werden.

Abnahme und Rückfallentscheidung

• 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 den zuvor freigegebenen Zielbuild zeigt (beim ausdrücklich gewählten MR2-Pfad Build 546); 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