Sophos Firewall vor SFOS 22 Upgrade prüfen

SFOS 22 bringt wichtige Architekturänderungen in die Sophos Firewall. Für Administratoren ist deshalb nicht nur interessant, welche neuen Funktionen nach dem Update verfügbar sind. Wichtiger ist zuerst die Frage, ob die eigene Firewall sauber auf SFOS 22 aktualisiert werden kann.

Diese Anleitung dient als Pre-Upgrade-Check. Der Artikel ersetzt nicht die allgemeine Anleitung zum Sophos Firewall Firmware Update, sondern ergänzt sie um die Punkte, die bei SFOS 22 besonders schnell zu Problemen führen: unterstützte Plattform, Interface-Namen, Speicherplatz, Backup, HA-Zustand, Legacy Remote Access IPsec, policy-based IPsec, NAT und Rollback-Plan.

Wann dieser Check sinnvoll ist

Der Check sollte vor jedem geplanten Upgrade auf SFOS 22 oder höher durchgeführt werden. Besonders wichtig ist er, wenn eine der folgenden Situationen zutrifft:

• die Firewall läuft noch auf XG- oder SG-Hardware
• die Appliance wurde schon über mehrere Major Releases aktualisiert
• es gibt viele VLANs, Aliases, Bridges, LAGs, RED- oder XFRM-Interfaces
• es handelt sich um eine kleine Desktop-Appliance, virtuelle Firewall oder Software-Appliance
• die Firewall läuft in einem HA-Cluster
• Remote Access IPsec VPN wird oder wurde in der Vergangenheit genutzt
• policy-based Site-to-Site IPsec, spezielle SNAT-Regeln oder VPN-NAT-Regeln sind im Einsatz
• STAS oder andere benutzerbasierte Authentifizierung steuert produktive Firewallregeln
• die Firewall wird über Sophos Central verwaltet oder soll darüber aktualisiert werden

Wenn die Firewall schon im Alltag instabil ist, Dienste regelmässig neu gestartet werden müssen oder Partitionen stark gefüllt sind, sollte das Upgrade nicht als Reparaturversuch verstanden werden. In diesem Fall zuerst den aktuellen Zustand stabilisieren und die Ursache klären.

1. Plattform und Upgradepfad prüfen

SFOS 22.0 und neuere Versionen unterstützen keine XG- und SG-Hardware-Appliances mehr. Wer noch solche Geräte betreibt, muss zuerst die Migration auf XGS, virtuelle Firewall, Software-Appliance oder Cloud Deployment planen. Für die Entscheidung zwischen alten und neuen Hardwaregenerationen hilft der Artikel Was ist der Unterschied zwischen einer XG und XGS Firewall?.

Auf unterstützten Plattformen sollte zusätzlich geprüft werden, von welcher Version aktualisiert wird. Die SFOS 22 Release Notes zeigen, welche Versionen direkt auf SFOS 22 migriert werden können. Wenn ein nicht unterstützter Pfad gewählt wird, kann die Firewall nach Bestätigung mit Factory-Konfiguration starten. Genau dieses Risiko muss vor einem Wartungsfenster ausgeschlossen sein.

Praktischer Ablauf:

1. Aktuelle Firmwareversion unter Backup & Firmware > Firmware notieren.
2. Modell, Seriennummer und Plattformtyp dokumentieren.
3. In den offiziellen Sophos Release Notes prüfen, ob der direkte Upgradepfad unterstützt ist.
4. Bei XG- oder SG-Hardware keine SFOS-22-Planung mehr als normales Update behandeln, sondern als Migrationsprojekt.

2. Interface-Namen vor dem Upgrade prüfen

Ein leicht zu übersehender Upgrade-Punkt betrifft die Namen von Interfaces. Physische oder logische Interfaces können in der WebAdmin-Ansicht unter Network > Interfaces nicht sichtbar oder nicht aufklappbar sein, wenn ein Interface-Name, Hardware-Name oder Branch-Name mit zehn oder mehr Ziffern endet.

Das ist unangenehm, weil der Traffic weiter verarbeitet werden kann, die Administration im WebAdmin aber plötzlich so aussieht, als ob Interfaces fehlen. Besonders bei Migrationen, automatisierten Namensschemata, importierten Konfigurationen oder VLAN-Namen mit Standort-, Kunden- oder Inventarnummern sollte man diesen Punkt vor dem Upgrade prüfen.

Kritische Beispiele:

Praktischer Ablauf:

1. Network > Interfaces öffnen.
2. Physische Interfaces, VLANs, Aliases, Bridges, LAGs, RED-Interfaces und XFRM-Interfaces prüfen.
3. Namen suchen, die mit zehn oder mehr Ziffern enden.
4. Betroffene Namen vor dem Upgrade auf eine kürzere oder klar getrennte Schreibweise ändern.
5. Nach der Änderung prüfen, ob Firewall-Regeln, NAT-Regeln, SD-WAN-Routen, DHCP, VPN und Dokumentation noch verständlich sind.

Besser sind Namen, bei denen Zahlen nicht als langer Block am Ende stehen. Statt VLAN_1234567890 ist zum Beispiel VLAN-1234567890-Client oder ein fachlicher Name wie Client-VLAN-100 lesbarer und betrieblich robuster.

Wenn nach einem Upgrade Interfaces in der WebAdmin-Ansicht fehlen, sollte man nicht sofort annehmen, dass die Netzwerkkonfiguration verloren ist. Zuerst prüfen, ob das Verhalten zur Interface-Namensproblematik passt, ob Traffic weiterhin läuft und ob die betroffenen Namen angepasst werden müssen. Für die generelle Interface-Planung passt Sophos Firewall Zonen und Interfaces konfigurieren.

3. Speicherplatz und Firmware-Hinweise prüfen

SFOS 22 benötigt zusätzlichen Speicherplatz für neue Funktionen und Architekturänderungen. Die meisten Appliances erfüllen die Anforderungen, einzelne Desktop-, Virtual- und Software-Deployments können aber eine manuelle Prüfung oder Korrektur benötigen. Wenn die Firewall auf der Control Center- oder Firmware-Seite eine Meldung zu Speicherplatzanforderungen zeigt, sollte diese nicht ignoriert werden.

Über SSH lässt sich der Füllstand der Partitionen grob prüfen:

df -kh

Die Ausgabe ersetzt keine Sophos-Kompatibilitätsprüfung, hilft aber bei der Einschätzung, ob /, /var, /content oder andere Partitionen auffällig voll sind. Wenn eine Partition sehr knapp ist, sollte nicht einfach blind aktualisiert werden. Zuerst klären, welche Daten dort liegen, ob Logs oder alte Dateien bereinigt werden können und ob ein Sophos-Hinweis für die betroffene Appliance existiert.

Wichtig ist auch die Zeitplanung: Wenn die Firewall während des Upgrades Partitionen anpassen muss, kann das Update länger dauern als ein normales Maintenance Release. Das Wartungsfenster sollte deshalb nicht zu knapp geplant werden.

4. Backup und Recovery vorbereiten

Vor dem Upgrade braucht es ein frisches Backup. Das klingt banal, ist aber bei Major Releases entscheidend. Das Backup sollte nicht nur erzeugt, sondern auch auffindbar, entschlüsselbar und einem konkreten Gerät zuordenbar sein. Der Artikel Sophos Firewall Backup erstellen oder wiederherstellen erklärt die wichtigsten Punkte rund um Backup, Restore und Secure Storage Master Key.

Vor SFOS 22 sollten mindestens diese Punkte erledigt sein:

• aktuelles Konfigurationsbackup erstellen und extern speichern
• Secure Storage Master Key dokumentieren, falls verschlüsselte Backups verwendet werden
• Admin-Zugang lokal und über das Wartungsnetz prüfen
• Lizenzstatus und Sophos Central Zugriff prüfen
• aktuelles Firmware-Image und Ziel-Firmware griffbereit halten
• Rollback-Entscheidung definieren: wann wird gewartet, wann wird zurückgerollt

Bei kritischen Standorten sollte zusätzlich klar sein, wer vor Ort Zugriff auf die Appliance hat und wie man bei Bedarf ein Reimage durchführen würde. Die Neuinstallation ist ein anderes Verfahren als ein normales Firmware-Update. Dafür gibt es die separate Anleitung Sophos Firewall OS neu installieren.

5. Go/No-Go vor dem Wartungsfenster festlegen

Ein SFOS-22-Upgrade sollte nicht erst während des Wartungsfensters entschieden werden. Vorher muss klar sein, unter welchen Bedingungen gestartet, gewartet, abgebrochen oder zurückgerollt wird. Das reduziert hektische Entscheidungen, wenn die Firewall länger braucht, ein HA-Node nicht synchronisiert oder ein kritischer Dienst nach dem Neustart nicht funktioniert.

Sinnvolle Go/No-Go-Punkte:

Für verteilte Standorte sollte ausserdem feststehen, wer während des Wartungsfensters erreichbar ist: technische Ansprechperson, Standortkontakt, Person mit physischem Zugriff und Entscheidungsträger für Rollback. Wenn das Upgrade remote durchgeführt wird, sollte man zusätzlich prüfen, ob ein alternativer Zugriff vorhanden ist, falls VPN, WAN oder Central Management vorübergehend nicht funktioniert.

Ein Rückfallplan ist keine Schwäche des Changes. Er verhindert, dass in einer Störung gleichzeitig Firmware, Routing, VPN, HA und Switching geändert werden. Wenn nach dem Upgrade ein kritischer Dienst ausfällt, sollte zuerst der definierte Validierungsplan abgearbeitet werden. Erst danach wird entschieden, ob ein Rollback, ein Restore, ein Reimage oder eine gezielte Fehlerbehebung sinnvoller ist.

6. HA-Cluster sauber vorbereiten

Bei HA-Clustern darf nicht nur die aktive Firewall betrachtet werden. Beide Nodes müssen unterstützt sein, denselben sinnvollen Ausgangszustand haben und sauber synchronisieren. Ein Upgrade auf einem bereits angeschlagenen HA-Cluster erhöht das Risiko für unnötige Ausfälle.

Vor dem Wartungsfenster prüfen:

• System services > High availability zeigt einen gesunden HA-Status.
• Beide Appliances sind dasselbe Modell beziehungsweise eine unterstützte HA-Kombination.
• Firmwarestand, Lizenzstatus und Subscription sind plausibel.
• HA-Link, Monitored Ports und angeschlossene Switchports sind stabil.
• Es ist dokumentiert, welches Gerät vor dem Upgrade aktiv war.

Für die generelle HA-Planung und die Besonderheiten von Active-Passive, Active-Active, Lizenzierung und Wartung passt der Artikel Sophos Firewall HA-Cluster Varianten.

7. Legacy Remote Access IPsec suchen

Ab SFOS 22.0 MR1 ist Legacy Remote Access IPsec VPN nicht mehr unterstützt. Firewalls mit dieser Legacy-Konfiguration können nicht auf SFOS 22.0 MR1 oder neuer aktualisiert werden. Das ist ein typischer Upgrade-Blocker, weil Remote Access IPsec in älteren Umgebungen oft einmal eingerichtet und danach lange nicht mehr angefasst wurde.

Vor dem Upgrade sollte man deshalb prüfen, ob alte Remote-Access-IPsec-Konfigurationen vorhanden sind. Falls ja, muss zuerst auf die aktuelle Remote-Access-IPsec-Konfiguration, SSL VPN, ZTNA oder ein anderes passendes Remote-Access-Design migriert werden. Der konkrete Ablauf steht in Legacy Remote Access IPsec vor SFOS 22 MR1 migrieren. Für allgemeines IPsec-Troubleshooting hilft zusätzlich Sophos Firewall IPsec VPN Troubleshooting.

Praktischer Ablauf:

1. Im WebAdmin den Bereich Remote access VPN öffnen.
2. Kontrollieren, ob eine Legacy-Remote-Access-IPsec-Konfiguration vorhanden ist.
3. Betroffene Benutzer, Profile, Pools, Authentifizierung und verteilte Sophos-Connect-Konfigurationen dokumentieren.
4. Ersatzkonfiguration planen und mit wenigen Testbenutzern prüfen.
5. Erst nach erfolgreicher Migration die Legacy-Konfiguration entfernen und das Firmware-Upgrade erneut prüfen.

Wenn Sophos Connect eingesetzt wird, sollten auch die bestehenden Anleitungen zur Sophos Connect Firewall-Konfiguration, zur Windows-Installation und zur macOS-Installation einbezogen werden.

8. Policy-based IPsec und NAT prüfen

SFOS 22.0 GA und neuere Versionen ändern das Verhalten von policy-based Site-to-Site IPsec VPN. Zusätzlich ist in den SFOS-22-Release-Notes ein behobenes Problem dokumentiert, bei dem policy-based IPsec Traffic fehlschlagen konnte, wenn die Default-SNAT-Regel mit einer statischen IP-Adresse statt MASQ konfiguriert war.

Das ist kein Grund, jedes IPsec-Setup vorab umzubauen. Es ist aber ein guter Grund, policy-based IPsec vor und nach dem Upgrade bewusst zu testen. Besonders wichtig ist das, wenn die Firewall mehrere VPNs, überlappende Netze, spezifische SNAT-Regeln, eine angepasste Default-SNAT-Regel oder Partnernetze mit festen Source-IP-Erwartungen nutzt.

Vor dem Upgrade prüfen:

1. Policy-based Site-to-Site-Tunnel identifizieren.
2. Lokale und entfernte Netze beziehungsweise Traffic Selectors dokumentieren.
3. NAT-Regeln auf VPN-Traffic prüfen, besonders Default-SNAT, MASQ, spezifische SNAT-Regeln und Regelreihenfolge.
4. Pro wichtigem Tunnel einen Testfall mit Source, Destination, Service und erwarteter Richtung definieren.
5. Gegenstelle und Rückweg dokumentieren, damit ein Post-Upgrade-Test nicht nur “Ping geht nicht” heisst.

Nach dem Upgrade sollte man diese Tests nicht mit breiten Sammelchecks vermischen. Besser ist ein enger Test pro Tunnel: Log Viewer, Packet Capture, Firewall Rule ID, NAT Rule ID und Byte-Zähler in ipsec statusall vergleichen. Wenn der Tunnel grün ist, aber kein Nutztraffic fliesst, passt Sophos Firewall IPsec VPN Troubleshooting. Für die NAT-Einordnung hilft NAT auf Sophos Firewall verstehen.

9. STAS und benutzerbasierte Regeln prüfen

Wenn STAS aktiv ist, sollte es vor SFOS 22.0 MR1 oder neuer nicht nur als “funktioniert im Alltag” abgehakt werden. In der Known-Issues-Liste ist ein Problem dokumentiert, bei dem die Option Restrict client traffic during identity probe ein Upgrade auf SFOS 22.0 MR1 blockieren oder nach dem Upgrade zu wiederholten Identity Probes mit kurzzeitigen Traffic-Unterbrüchen führen kann.

Das betrifft vor allem Umgebungen, in denen STAS nicht nur für Reporting, sondern für produktive benutzerbasierte Firewallregeln verwendet wird. Wenn die Benutzer-IP-Zuordnung kurz aussetzt, sieht das im Betrieb schnell wie ein Regel-, DNS- oder Applikationsproblem aus.

Vor dem Upgrade prüfen:

1. Authentication > STAS öffnen.
2. STAS-Status und verwendete Collectors kontrollieren.
3. Kontrollieren, ob Restrict client traffic during identity probe aktiv ist.
4. Benutzerbasierte Regeln identifizieren, die von STAS abhängen.
5. Testbenutzer anmelden und Live Users sowie Log Viewer prüfen.

Wenn diese Option aktiv ist oder bereits kurze Unterbrüche auffallen, sollte der Punkt vor dem Wartungsfenster geklärt werden. Der detaillierte Ablauf steht in STAS auf Sophos Firewall einrichten.

10. Nach dem Upgrade gezielt validieren

Nach dem Neustart ist das Upgrade nicht automatisch abgeschlossen. Erst wenn die wichtigsten Betriebsfunktionen geprüft wurden, ist das Wartungsfenster sauber beendet.

Mindestens prüfen:

• richtige Firmwareversion ist aktiv
• Network > Interfaces zeigt physische und logische Interfaces plausibel an
• Internetzugang und zentrale Firewall-Regeln funktionieren
• Site-to-Site VPN und Remote Access VPN funktionieren
• policy-based IPsec Tests zeigen die erwartete Source-IP und passende NAT-Regel
• HA-Status ist wieder synchron
• STAS, AD SSO oder andere Benutzerzuordnung funktioniert, falls produktiv genutzt
• Sophos Central Management und Reporting senden Daten
• Log Viewer zeigt keine neuen kritischen Fehler
• wichtige Dienste wie DNS, DHCP, Web Protection, IPS und Authentifizierung laufen erwartungsgemäss

Wenn VPN, Routing oder Regeln nicht wie erwartet funktionieren, nicht sofort an mehreren Stellen gleichzeitig ändern. Zuerst mit Log Viewer, Policy Test, Packet Capture und den betroffenen Service-Logs eingrenzen. Für strukturiertes Troubleshooting sind Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture und Sophos Firewall Troubleshooting: Services und Logs hilfreiche Ergänzungen.

11. Nachweis und Betriebsdokumentation sichern

Ein Upgrade ist erst dann sauber abgeschlossen, wenn das Ergebnis nachvollziehbar dokumentiert ist. Das hilft bei späteren Störungen, Audits, Supportfällen und beim nächsten Wartungsfenster. Direkt nach dem Upgrade sollte man deshalb nicht nur “läuft wieder” notieren, sondern konkrete Nachweise sichern.

Sinnvolle Nachweise:

Wenn Änderungen an Regeln, Interfaces, Hosts oder Services vorgenommen wurden, sollte man zusätzlich die Audit Trail Logs prüfen. Bei Umgebungen mit längerer Logaufbewahrung gehört auch eine Kontrolle von Central Firewall Reporting oder Syslog zum Abschluss.

Bei mehreren Firewalls ist ausserdem wichtig, dass Backups eindeutig zugeordnet werden können. In neueren SFOS-Versionen enthalten Backup-E-Mails mehr Identifikationsdaten wie Hostname, Firmwareversion, Seriennummer und Modell. Trotzdem sollte man intern weiterhin eine einfache Upgrade-Notiz führen: Firewall, Standort, alte Version, neue Version, Zeitfenster, verantwortliche Person, Testergebnis und offene Punkte.

Wenn nach dem Upgrade Speicher-, Hardware- oder SSD-Hinweise auffallen, sollte das nicht im Firmware-Ticket untergehen. Für diese Prüfung passt SSD-Gesundheitszustand auf Sophos Firewall prüfen.

Checkliste für das Wartungsfenster

Vor dem Upgrade

• Plattform und Upgradepfad geprüft
• Release Notes und bekannte Hinweise gelesen
• Interface-Namen mit zehn oder mehr abschliessenden Ziffern ausgeschlossen
• Speicherplatz und Firmware-Hinweise geprüft
• Backup erstellt und extern gespeichert
• Secure Storage Master Key verfügbar
• Go/No-Go-Entscheidung, Rückfallweg und Verantwortliche festgelegt
• HA-Zustand dokumentiert
• Policy-based IPsec, VPN-NAT und Testtraffic dokumentiert, falls genutzt
• STAS und benutzerbasierte Regeln geprüft, falls genutzt
• Legacy Remote Access IPsec ausgeschlossen oder migriert
• Rollback-Plan definiert

Während des Upgrades

• Statusmeldungen dokumentieren
• Keine parallelen Änderungen an Routing, VPN oder Switching durchführen
• Bei HA-Clustern Failover und Synchronisation beobachten
• Entscheidungspunkt für Warten, Fehleranalyse oder Rollback einhalten
• Bei unerwarteten Meldungen nicht blind bestätigen, sondern Ursache prüfen

Nach dem Upgrade

• Firmwareversion und Lizenzstatus prüfen
• VPN, Routing, DNS, DHCP und zentrale Firewall-Regeln testen
• Policy-based IPsec mit definiertem Source-/Destination-Test prüfen, falls genutzt
• STAS, AD SSO und benutzerbasierte Regeln mit Testbenutzer prüfen
• HA-Sync und Sophos Central Verbindung prüfen
• Log Viewer und relevante Service-Logs kontrollieren
• Firmware-, HA- und Audit-Nachweise sichern
• Ergebnis und offene Punkte im Betriebsjournal dokumentieren

FAQ