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

Warnungen auf der Firmwareseite müssen vor dem Upgrade geklärt werden. Der Referenzcode zeigt, was das Upgrade blockiert:

• FWDS501: Die Primary Disk oder eine ihrer Partitionen ist für SFOS 22 zu klein. FWDS501: Primary Disk vor SFOS 22 vergrössern erklärt, wie man die betroffene Partition erkennt und ob die bestehende Installation vergrössert werden kann oder die Firewall neu bereitgestellt werden muss.
• 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.

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.

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.

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.

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