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

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

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

df -kh

Erscheint auf der Firmwareseite eine Warnung, wird das Upgrade noch nicht gestartet. Der Referenzcode 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, ein öffentlicher Workaround fehlt. 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 die neuen Let’s-Encrypt-CAs YE Root, YE1, YE2, YR Root, YR1 und YR2. Unabhängig davon brach bei zwei öffentlich dokumentierten Upgrades von MR1 Build 490 auf MR2 Build 546 die Konfigurationsmigration im Zusammenhang mit einem verwendeten Let’s-Encrypt-Zertifikat ab. Die Firewall rollte automatisch auf MR1 zurück. Sophos bestätigte nach einer Support-Access-Prüfung einen bekannten Migrationsblocker für Zertifikate aus einem bestimmten, aber nicht öffentlich eingegrenzten Ausstellungszeitraum. Stand 9. August 2026 fehlen weiterhin eine öffentliche Issue-ID, ein verlässlicher Vorabtest und 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 Issuer und die Dienstzuweisung dokumentiert werden. Ein YE-/YR-Issuer oder die blosse Existenz dieser CAs unter Certificate authorities beweist den Migrationsfehler nicht und ist allein kein genereller Upgradeblocker. Bei einer kritischen Firewall ist es dennoch sinnvoll, den Fall vorab mit Sophos Support abzustimmen oder das Upgrade zu verschieben, solange kein öffentlicher Vorabtest oder Fix bestätigt ist. 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 bekannte 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 und Kontrolle

• Vorher: Blocker ausschliessen, Backup und SSMK bereitstellen, HA-Synchronisation prüfen sowie VPN-, Test- und Rückfallwege dokumentieren.
• Währenddessen: Keine parallelen Änderungen an Routing, VPN oder Switching durchführen; Status und HA-Failover beobachten.
• Nachher: Firmware, Interfaces, Internet, Firewallregeln, VPN, NAT, HA, STAS, DNS, DHCP, Central und Log Viewer prüfen.

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.

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

FAQ