Sophos Firewall im Failsafe-Modus: Ursache prüfen

Startet eine Sophos Firewall im Failsafe-Modus, hat SFOS einen kritischen Fehler erkannt und den normalen Betrieb nicht aufgenommen. Paketverarbeitung, Interfaces und Managementzugang können je nach Ursache vollständig oder teilweise ausfallen. Deshalb darf man aus einem noch erreichbaren Management-Port nicht schliessen, dass die Firewall weiterhin zuverlässig schützt.

Der wichtigste erste Schritt ist nicht ein Factory Reset oder Reimage, sondern die von SFOS erkannte Ursache zu sichern:

1. Über die lokale, serielle oder Hypervisor-Konsole verbinden.
2. Im Failsafe-Menü Device Console öffnen.
3. Den folgenden lesenden Befehl ausführen:

show failure-reason

Die Konsole kann danach beispielsweise so aussehen:

failsafe> show failure-reason
Unable to apply Firewall Framework

failsafe> ist nur der Prompt und wird nicht mit eingegeben. Die genaue Meldung kann anders lauten. Entscheidend ist, die unveränderte Ausgabe und die ersten sichtbaren Konsolenzeilen zu fotografieren oder zu kopieren. Falls SSH im Fehlerzustand noch funktioniert, ist die Device Console auch darüber erreichbar; die lokale, serielle oder Hypervisor-Konsole bleibt bei einem Ausfall der robustere Weg.

⚠️ Vor einem Neustart sichern: Ein Reboot kann die sichtbare Fehlersituation verändern oder vorübergehend beseitigen. Vorher mindestens Fehlermeldung, SFOS-Version mit Build, Appliance-Rolle und Zeitpunkt dokumentieren. Reset to Factory Defaults, Remove Firewall Rules und manuelle Datenbank- oder Dateisystemeingriffe sind keine Diagnose und können wichtige Konfiguration oder Beweise zerstören.

Was der Failsafe-Modus bedeutet

Failsafe ist ein Schutz- und Recovery-Zustand. SFOS startet ihn, wenn eine für den sicheren Firewall-Betrieb notwendige Komponente nicht korrekt hochkommt. Bekannte Meldungen und reale Fehlerfälle betreffen beispielsweise die Konfigurationsdatenbank, das Firewall-Framework, das Regelwerk, den Logging- oder Netzwerkdienst, die Signaturdatenbank oder bei einem entsprechend ausgestatteten XGS-Modell die Network Processing Unit (NPU). Das ist keine vollständige Reparaturmatrix; die konkrete Konsolenausgabe bleibt massgebend.

Ein nicht erreichbares WebAdmin allein beweist noch keinen Failsafe-Zustand. Wenn der Traffic weiterläuft und nur die Oberfläche hängt, passt zuerst die gezielte Prüfung beziehungsweise der Neustart der WebAdmin GUI. Echten Failsafe erkennt man an der Konsole. Ob daneben ein Managementzugang oder einzelne Interfaces noch funktionieren, hängt von der Ursache ab und ist kein Gesundheitsnachweis.

Diese Unterscheidung ist wichtig: Bei einem einzelnen ausgefallenen Dienst kann ein gezielter Service-Neustart sinnvoll sein. Im Failsafe-Modus fehlt dagegen eine kritische Startvoraussetzung. Mehrere Dienste auf Verdacht neu zu starten verschleiert dann eher die Ursache, als sie zu beheben.

Failsafe-Ursache mit show failure-reason prüfen

show failure-reason gehört in die Device Console, nicht in die Advanced Shell. Der Befehl verändert keine Konfiguration. Er zeigt die Fehlerklasse, die SFOS beim Start erkannt hat.

Die Ausgabe ist ein Ausgangspunkt und noch keine vollständige Reparaturanweisung. Die folgenden Meldungsgruppen helfen bei der Einordnung:

• Configuration database: Die Firewall konnte ihre Konfigurationsdatenbank nicht korrekt starten. Vor manuellen Reparaturen werden Fehlermeldung, Build, letzte Änderung und vorhandenes Backup gesichert. Datenbankdateien nicht löschen oder verändern.
• Firewall framework oder firewall rules: SFOS konnte die Basis für Paketverarbeitung oder das Regelwerk nicht anwenden. Relevant sind letzte Regel-, Objekt-, Restore- oder Firmwareänderungen. Ein pauschales Entfernen aller Firewall-Regeln wäre ein Datenverlust, keine saubere Erstdiagnose.
• Logging daemon: Ein kritischer Logging-Dienst startete nicht. Neben der Fehlermeldung werden Speicherzustand, Build und Logs geprüft. Reports oder Logs nicht blind leeren, bevor benötigte Daten gesichert sind.
• Network daemon: Netzwerkkomponenten konnten nicht korrekt starten. Bei virtuellen Appliances gehören vorhandene vNICs, Adapterreihenfolge und Hypervisor-Änderungen in die Prüfung.
• Signature database: Eine notwendige Signaturdatenbank konnte nicht geladen werden. Patternstatus, Speicher und zeitlicher Zusammenhang mit Updates sind relevant; Signaturdateien werden nicht manuell gelöscht.
• NPU: Bei einem XGS-Modell mit NPU kann bereits die erste Konsolenzeile Network processing unit error melden. Auch wenn show failure-reason danach keine brauchbare Ausgabe liefert, wird die gesamte Konsole gesichert und ein Support- beziehungsweise Hardwarefall vorbereitet.

Die Schreibweise einer konkreten Meldung kann je nach SFOS-Version abweichen. Für den Support ist deshalb die unveränderte Ausgabe wertvoller als eine selbst formulierte Zusammenfassung wie Firewall startet nicht.

Plattform und letzten Change prüfen

Der nächste Schritt hängt davon ab, ob Hardware, eine virtuelle beziehungsweise Software-Appliance oder ein HA-Cluster betroffen ist. Dieselbe Fehlermeldung darf nicht automatisch zur gleichen Massnahme führen.

Virtuelle Firewall und Software-Appliance

Eine virtuelle Firewall kann bereits wegen unpassender Ressourcen in Failsafe wechseln. Für lokal betriebene SFOS-22-Appliances unter VMware, Hyper-V, KVM und Citrix nennt Sophos aktuell mindestens:

• 1 vCPU
• 4 GB vRAM
• 2 vNICs
• 32 GB Primary Disk
• 80 GB Report Disk

Zusätzlich dürfen konfigurierte vCPU und vRAM die gekaufte Lizenz nicht überschreiten. Die Mindestwerte sind nur technische Startgrenzen und kein produktives Sizing für IPS, TLS Inspection oder hohen Durchsatz.

Die Auxiliary Disk aus den VM-Images ist diese separate Report Disk. Sie ist nicht optional und ersetzt die Primary Disk nicht. Für AWS und Azure gelten stattdessen die unterstützten Cloud-Instanztypen und plattformspezifischen Grössen.

Im Hypervisor wird geprüft, ob beide Disks und alle vorgesehenen vNICs noch vorhanden, verbunden und in der erwarteten Reihenfolge zugewiesen sind. Auch eine nachträgliche Änderung an CPU, RAM, Disk-Controller oder virtuellem Netzwerk gehört in die Incident-Zeitleiste. Die Plattformunterschiede und Ressourcenanforderungen sind im eigenen Artikel ausführlicher eingeordnet.

Für eine SFOS-22-Software-Appliance sind x86-64, Legacy BIOS, mindestens 4 GB RAM und zwei Netzwerkkarten unstrittig. Beim Datenträger widersprechen sich jedoch zwei aktuelle Sophos-Seiten: Die allgemeine Plattformübersicht nennt 10 GB Minimum, die neuere spezifische Software-Appliance-Seite 32 GB Minimum und 64 GB empfohlen. Es gibt damit keine einheitliche publizierte Sophos-Grenze. Für neue Installationen empfiehlt Avanet konservativ mindestens 32 GB und nach Möglichkeit 64 GB; damit folgt man der spezifischeren Produktseite und vermeidet ein bereits beim Start knappes System.

Ressourcen werden nicht während eines unklaren Recovery-Versuchs beliebig mehrfach verändert. Zuerst wird der Istzustand dokumentiert, dann erfolgt eine geplante Korrektur mit definiertem Starttest.

Hardware-Appliance und NPU

Bei einer physischen XGS werden zusätzlich Stromereignisse, Temperatur, Lüfter, SSD- beziehungsweise I/O-Fehler und die ersten Bootmeldungen berücksichtigt. Ein NPU-Fehler auf einem entsprechend ausgestatteten XGS-Modell ist kein Anlass, nicht dokumentierte Reset- oder Servicebefehle auszuprobieren. Wenn die Meldung wiederkehrt oder die Diagnose selbst fehlschlägt, ist der richtige nächste Weg ein Support Case mit möglicher RMA-Vorbereitung.

Ein einzelner erfolgreicher Neustart beweist noch nicht, dass ein Hardwareproblem behoben ist. Bei wiederholten Ausfällen helfen zusätzlich die vorhandenen Prüfungen für Temperatur und Lüfter sowie den SSD-Zustand.

Failsafe in einem HA-Cluster

Bei HA wird zuerst festgestellt, welcher Node betroffen ist und ob der Peer den produktiven Traffic stabil verarbeitet. Dokumentiert werden Primary oder Auxiliary, Clusterstatus, letzter Rollenwechsel und derselbe Zeitpunkt auf beiden Appliances.

Nicht beide Nodes gleichzeitig neu starten und HA nicht auf Verdacht deaktivieren. Eine unkoordinierte Änderung kann den noch funktionierenden Pfad gefährden, die Rollenlage verändern oder einen Neuaufbau erzwingen. Der Artikel Sophos Firewall High Availability einrichten erklärt Rollen, Synchronisation und Node-spezifische Logs; die konkrete Failsafe-Ursache wird trotzdem am betroffenen Node gesichert.

Nach Firmware-Update oder Restore

Wenn Failsafe unmittelbar nach einem Upgrade, Rollback oder Restore auftritt, zählen Ausgangsversion, Zielversion und vollständige Buildnummer. Bei SFOS 22 hat Sophos mit MR2 Build 546 mehrere konkrete Failsafe-Ursachen behoben, darunter Fehler nach dem Upgrade auf GA, einen nicht startenden Logging-Daemon, eine volle Konfigurationspartition und bestimmte fehlerhafte Serviceobjekte. Der SFOS-22-MR2-Überblick nennt die behobenen Issue-IDs.

Das bedeutet nicht, dass jedes Failsafe-Ereignis mit einem Update gelöst ist. Zuerst wird geprüft, ob Fehlermeldung und eingesetzter Build überhaupt zu einem bekannten Fix passen. Ein Firmwarewechsel benötigt weiterhin Backup, Wartungsfenster, HA-Plan und Rückweg. Dafür dienen die Vorbereitung eines Firmware-Updates und der SFOS-22-Upgrade-Check.

Failed to start Red server service

Zeigt die Firewall im Failsafe-Modus exakt diese Meldung, passt das Fehlerbild zu NC-178906. Sophos hat diesen Failsafe-Fehler mit SFOS 22.0 MR2 Build 546 behoben. Auf einem älteren Build wird nach der Beweissicherung ein kontrollierter Recovery- und Upgrade-Pfad zu Build 546 oder neuer geprüft. Tritt die Meldung mit Build 546 oder neuer auf, ist die Issue-ID allein kein Ursachennachweis; dann wird mit den gesicherten Logs ein Support Case eröffnet.

Vor Neustart oder Firmwarewechsel werden vollständiger Build, Zeitpunkt, betroffener HA-Node sowie sysinit.log, red.log und syslog.log zum Fehlerzeitpunkt gesichert. RED-Interfaces, RED-Firmware-Pattern oder RED-Konfiguration werden nicht auf Verdacht gelöscht und der RED-Dienst nicht wiederholt neu gestartet. Startet die Firewall normal und nur ein RED-Tunnel bleibt offline, passt stattdessen die RED-Fehlerbehebung.

Beweise vor Recovery oder Neustart sichern

Für eine belastbare Analyse werden möglichst vor der ersten zustandsverändernden Massnahme gesammelt:

• vollständige Ausgabe von show failure-reason und sichtbare erste Bootzeilen
• Modell, Seriennummer, Hardware-, Virtual- oder Software-Plattform
• genaue SFOS-Version inklusive MR und Build
• Zeitpunkt des Ausfalls und letzte bekannte funktionierende Zeit
• letzte Änderungen an Firmware, Restore, Regeln, Objekten, Interfaces, VM-Ressourcen oder Storage
• bei HA: betroffener Node, Rolle, Peer-Status und Zeitpunkt des letzten Failovers
• vorhandenes aktuelles Backup und zugehöriger Secure Storage Master Key
• bei VMs: vCPU, vRAM, vNICs, Primary Disk, Report Disk und Lizenzgrenze
• wiederkehrende Symptome wie Reboots, I/O-, NPU-, Temperatur- oder Speicherfehler

Wenn die Advanced Shell noch erreichbar ist, können passende Logauszüge zusätzlich gesichert werden. Diese Beispiele lesen nur die letzten 200 Zeilen und verändern das System nicht:

tail -n 200 /log/sysinit.log
tail -n 200 /log/syslog.log
tail -n 200 /log/postgres.log

sysinit.log ist das zentrale Log für den Systemstart, syslog.log enthält Kernel- und Systemereignisse und postgres.log hilft bei der Konfigurationsdatenbank. Je nach show failure-reason wird derselbe lesende tail-Befehl auf das passende Detail-Log angewendet, zum Beispiel:

tail -n 200 /log/networkd.log
tail -n 200 /log/sigdb.log
tail -n 200 /log/npu-startup.log

networkd.log gehört zu physischen und virtuellen Interfaces, sigdb.log zur Signaturdatenbank und npu-startup.log nur zu Hardwaremodellen mit NPU. Nicht jede Datei existiert auf jeder Plattform. Die weitere Zuordnung steht in Sophos Firewall Services und Logdateien. Logauszüge können vertrauliche Daten enthalten und werden geschützt übertragen.

Wenn WebAdmin wieder erreichbar ist, sollte zusätzlich ein CTR beziehungsweise Troubleshooting-Archiv gesichert werden. Der Ablauf steht in Sophos Firewall Logs für Support sichern.

Sicheren nächsten Schritt wählen

Nach der Beweissicherung lässt sich der Recovery-Pfad sauberer entscheiden:

1. Klare Ressourcenabweichung bei VM oder Software-Appliance: Istzustand dokumentieren, Lizenzgrenzen und aktuelle Mindestwerte prüfen, VM kontrolliert herunterfahren, genau die bestätigte Abweichung korrigieren und den nächsten Start beobachten.
2. Speicher- oder Logging-Hinweis: Partition und betroffene Datenart lesend prüfen. Keine Dateien mit rm löschen. Die Anleitung Speicherplatz und Reports sicher prüfen zeigt die vorgesehenen Diagnose- und Bereinigungswege.
3. Fehler direkt nach Firmwareänderung: Build gegen bekannte Probleme prüfen und erst dann kontrolliert zwischen aktuellem Maintenance Release, Rollback oder Support entscheiden.
4. NPU-, I/O- oder wiederkehrender Hardwarehinweis: Support Case und gegebenenfalls RMA vorbereiten. Ein temporär erfolgreicher Reboot schliesst einen Defekt nicht aus.
5. Datenbank-, Framework-, Regel- oder unbekannter Startfehler: Ausgabe und Logs sichern und einen Sophos Support Case mit vollständigem Fehlerbild eröffnen. Keine Datenbankdateien, Regelwerke oder Signaturen manuell entfernen.
6. Reimage als Recovery: Nur einsetzen, wenn Betriebssystemschaden, Support oder der dokumentierte Recovery-Plan diesen Weg begründen. Vorher müssen Backup, Passwort und SSMK verfügbar sein. Der vollständige Ablauf steht unter Sophos Firewall OS neu installieren.

Nach jeder Massnahme wird nicht nur WebAdmin geprüft. Entscheidend sind normaler Konsolenstart, korrekter HA-Status, Interface- und Routingzustand, Internet- und VPN-Verbindungen sowie das erneute Auftreten derselben Fehlermeldung. Wenn die Ursache unklar bleibt oder wiederkehrt, wird sie nicht durch weitere spontane Änderungen überdeckt.