Sophos Firewall startet unerwartet neu: Ursache prüfen

Startet eine Sophos Firewall ohne geplanten Eingriff neu, sollte man nicht sofort nochmals rebooten oder vorsorglich Services neu starten. Zuerst muss klar sein, ob wirklich die ganze Appliance neu gestartet hat oder nur WebAdmin, ein einzelner Dienst beziehungsweise die aktive HA-Rolle ausgefallen ist. Ein erfolgreicher Neustart stellt den Betrieb möglicherweise wieder her, erklärt aber noch nicht die Ursache.

⚠️ Beweise vor weiteren Eingriffen sichern: Keine Logs löschen, keinen weiteren Reboot provozieren, den Status von auto-reboot-on-hang nicht verändern und weder Debug, Service-Aktionen, fsck, Factory Reset noch Reimage auf Verdacht starten. Solche Eingriffe können Hinweise verändern, neue Unterbrüche verursachen oder den eigentlichen Fehler verdecken.

Der sichere Schnellweg ist:

Zeitpunkt mit Zeitzone, Ausfalldauer und letzte bekannte funktionierende Beobachtung notieren.
Festhalten, ob Traffic, WebAdmin, SSH und lokale Konsole gleichzeitig betroffen waren.
Im Control Center die Uptime, Services, Interfaces, VPNs und bei HA den Clusterstatus sichern.
Unter Log viewer > System passende Ereignisse exportieren und unter Diagnostics > System graphs den Verlauf sichern.
Unter Diagnostics > Tools einen CTR sowie sysinit.log, syslog.log und bei HA die lokalen Node-Logs herunterladen.
In der Device Console Uptime, Build und Auto-Reboot-Status lesen:

system diagnostics show uptime
system diagnostics show version-info
system auto-reboot-on-hang show

Bei HA Rollen, Status, Last status change und Uptime beider Nodes vergleichen.
Erst danach den passenden Ursachenast prüfen und den produktiven Betrieb vollständig testen.

system auto-reboot-on-hang show verändert nichts. SFOS aktiviert diese Funktion standardmässig und kann die Firewall automatisch neu starten, wenn der Kernel nicht mehr reagiert. Ein angezeigtes enable beweist jedoch nur die konfigurierte Recovery-Policy und nicht, dass ein Kernel-Hang diesen konkreten Neustart ausgelöst hat.

Prüfen, was tatsächlich ausgefallen ist

Die beobachtete Unterbrechung allein beweist noch keinen vollständigen Reboot. Diese vier Fälle benötigen unterschiedliche nächste Schritte:

Vollständiger Appliance-Reboot: Die Uptime beginnt neu, mehrere Dienste und Verbindungen waren gleichzeitig unterbrochen und SFOS hat den Systemstart erneut durchlaufen. Jetzt zählt die Reboot-Triage in diesem Artikel.
Nur WebAdmin oder ein Dienst war betroffen: Die Uptime läuft weiter und produktiver Traffic kann teilweise unverändert funktionieren. Dann passen der gezielte Neustart der WebAdmin GUI oder die Prüfung eines einzelnen Services besser als ein Appliance-Reboot.
HA-Failover: Benutzer sehen möglicherweise eine kurze Unterbrechung, obwohl nur die Rollen gewechselt haben. Uptime, Rolle und Logs jedes Nodes zeigen, ob ein Gerät tatsächlich rebootet hat. Die HA-Prüfung folgt weiter unten.
Failsafe-Modus: Die Firewall startet nicht normal und zeigt an der Konsole einen Recovery-Zustand. Dann ist show failure-reason aus dem Runbook zum Sophos Firewall Failsafe-Modus der richtige erste Befehl.

Die Uptime ist damit ein starker Beleg für den Neustartzeitraum, aber kein Ursachenbeweis. Auch ein kurzer Stromunterbruch, ein Kernel-Hang, ein Firmwarefehler und ein geplanter Admin-Neustart setzen sie zurück.

Beweise nach dem Neustart sichern

Nach einem ungeplanten Reboot können flüchtige Daten bereits fehlen. Trotzdem sollte man den erreichbaren Zustand vollständig sichern, bevor weitere Änderungen folgen.

Zum Incident gehören mindestens:

Modell, Seriennummer und Plattform: Hardware, VM oder Cloud
vollständige SFOS-Version mit MR und Build
exakter Zeitpunkt, Zeitzone, Ausfalldauer und Häufigkeit
betroffene Funktionen: Traffic, WebAdmin, SSH, Konsole, VPN und veröffentlichte Dienste
letzte Firmware-, Konfigurations-, Hypervisor-, Storage- oder Stromänderung
aktuelle Uptime und Status von Services, Interfaces, VPN und HA
bei HA: betroffener Node, Rollen vor und nach dem Ereignis sowie Peer-Status
vorhandene UPS-, PDU-, Hypervisor-, Cloud-, Switch- und Monitoring-Ereignisse im selben Zeitfenster

Unter Diagnostics > System graphs werden CPU, Memory, Load und Disk um den vermuteten Zeitpunkt geprüft. Eine Auffälligkeit kann die Suche eingrenzen. Ein normaler aktueller Wert beweist dagegen nicht, dass die Last vor dem Reboot ebenfalls normal war.

Unter Log viewer > System werden Start-, Restart-, Shutdown- und HA-Ereignisse auf dasselbe Zeitfenster eingegrenzt und exportiert. Der Log Viewer ist eine hilfreiche Zeitquelle, aber kein vollständiger Crash-Nachweis. Noch nicht gespeicherte Ereignisse können bei einem Hang fehlen.

Systemzustand in der Device Console lesen

Zusätzlich zu Uptime und Build zeigen diese lesenden Befehle den aktuellen Zustand:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk

Die Werte gehören zusammen mit dem Abfragezeitpunkt in die Incident-Notiz. Sie beschreiben den Zustand nach dem Neustart und dürfen nicht rückwirkend als Ursache interpretiert werden.

Start- und Systemlogs prüfen

In der Advanced Shell lassen sich die wichtigsten Dateien vollständig und ohne Änderung lesen:

cd /log
less sysinit.log
less syslog.log
less applog.log
less csc.log

Mit q wird less beendet. Innerhalb der Datei startet /Suchbegriff eine Suche, beispielsweise /error; mit n springt man zum nächsten Treffer.

sysinit.log dokumentiert den Systemstart.
syslog.log enthält Kernel- und Systemereignisse.
applog.log und csc.log helfen, interne Aktionen und zeitnahe Änderungen einzuordnen.

Unter Diagnostics > Tools > Troubleshooting logs sollten dieselben Dateien zusätzlich heruntergeladen werden, damit die Originaldaten ausserhalb der Appliance erhalten bleiben. Welche zusätzliche Logdatei zu einem Dienst gehört, erklärt die Zuordnung der Sophos Firewall Service-Logs.

Zusätzlich wird unter Diagnostics > Tools > Consolidated troubleshooting report ein CTR mit System snapshot und All log files erzeugt. Der CTR enthält den aktuellen Systemzustand und viele Logs in einem verschlüsselten Archiv. Bei Service-Subsystem-Logs sind standardmässig höchstens 10'000 Zeilen enthalten; für längere Zeiträume bleiben vollständige Einzel-Logs wichtig. Der komplette Ablauf steht unter Sophos Firewall Logs für Support sichern.

Ein leerer Logabschnitt schliesst einen Crash oder Stromunterbruch nicht aus. Noch nicht auf den Datenträger geschriebene Informationen können bei einem Hang verloren gehen, und lokale Logs können rotieren. Deshalb sind externe Zeitquellen und eine genaue Incident-Zeitleiste so wichtig.

HA-Failover und Node-Reboot unterscheiden

Unter System services > High availability werden Health, Mode, Rollen, Status, Seriennummern und Last status change gesichert. In der Device Console zeigt zusätzlich:

system ha show details

Danach wird die Uptime auf beiden Nodes geprüft. Hat nur ein Node eine kurze Uptime, spricht das für einen Neustart dieses Geräts. Sind die Uptimes unverändert, aber die Rollen wechselten, muss zuerst der HA-Auslöser wie ein Monitored Port oder ein Peer-Problem untersucht werden. Ein manueller Wechsel der aktiven Rolle kann die bisherige Primary ebenfalls neu starten; deshalb gehört auch ein möglicher Admin-Eingriff in die Zeitleiste.

Die HA-Logs liegen lokal auf dem jeweiligen Node und werden nicht synchronisiert. Auf beiden Appliances sind deshalb mindestens diese Dateien relevant:

cd /log
less ha.log
less msync.log

ha.log zeigt Aufbau und Statuswechsel, msync.log die Synchronisierung. Keinen gleichzeitigen Neustart beider Nodes auslösen und keinen weiteren Failover zur Reproduktion erzwingen. Die vollständige Rollen- und Linkdiagnose steht unter Sophos Firewall High Availability.

Ursache nach dem Kontext eingrenzen

Geplanter Admin- oder Firmware-Neustart

Zuerst werden Change-Kalender, Wartungsfenster, Adminaktionen, Sophos-Central-Tasks und Benachrichtigungen mit dem Ereigniszeitpunkt verglichen. Vorausgehende Konfigurationsänderungen lassen sich über die Audit Trail Logs einordnen. Sophos Firewall erzeugt Systemereignisse für einen Start sowie für Restart oder Shutdown über WebAdmin. Wenn E-Mail-Benachrichtigungen eingerichtet sind, kann die Meldung im Postfach den Zeitpunkt und die sendende Firewall zusätzlich bestätigen.

Trat der Neustart während eines Firmware- oder Hotfix-Prozesses auf, werden Ausgangsversion, Zielversion, Build, Updatezeitpunkt und fwmgmt.log gesichert. Ein Neustart gehört zu einem normalen Firmwarewechsel; mehrere ungeplante Reboots oder ein unerwarteter Build dagegen nicht. Für die weitere Einordnung dient der Ablauf Sophos Firewall Firmware Update durchführen.

Kernel-Hang oder Softwarefehler

Mit aktivem auto-reboot-on-hang kann SFOS nach einem nicht mehr reagierenden Kernel selbst neu starten. Die Funktion verbessert die Verfügbarkeit, hinterlässt aber nicht in jedem Fall einen eindeutigen lokalen Ursachenbeweis. Der angezeigte Status wird dokumentiert und während der Triage nicht verändert. Der Fall wird über Zeitpunkt, Logs, System graphs, CTR und exakten Build eingegrenzt.

Sophos hat in SFOS 22.0 MR2 Build 546 mehrere voneinander unabhängige Crash- und Restart-Fälle behoben, beispielsweise:

NC-180974: Kernel-Crash in sdwan_profile mit HA-Failover
NC-178354: Kernel-Crash beim Matching von SD-WAN-Regeln
NC-178745: automatischer Neustart eines HA-Geräts wegen Out-of-Memory
NC-180433: wiederholter Crash bei Multicast-Traffic durch einen VPN-Tunnel

Diese Issue-IDs zeigen, warum Die Firewall ist rebootet noch keine Diagnose ist. Nur wenn Build, Funktion, Traffic und Fehlerzeitpunkt zum dokumentierten Fall passen, wird der unterstützte Upgradepfad zu MR2 Build 546 oder einer neueren freigegebenen Version geprüft. Tritt der Fehler auf diesem oder einem neueren Build erneut auf, wird er nicht weiterhin automatisch derselben alten Issue-ID zugeordnet. Die übrigen Fixes sind im Überblick zu SFOS 22.0 MR2 eingeordnet.

Ein Kernel-Crash wird nicht absichtlich durch Lasttests, Multicast, SD-WAN-Änderungen oder einen erzwungenen Failover reproduziert. Konfiguration und Traffic-Muster werden dokumentiert und danach mit Sophos Support ausgewertet.

Last, Speicherplatz oder Storage

CPU-, Memory-, Load- und Disk-Verlauf können zeigen, ob vor dem Reboot bereits eine länger anhaltende Auffälligkeit bestand. Zusätzlich nennt Sophos /log/system-monitor/cpu_trigger.log für automatisch erfasste Systemzustände bei hoher CPU-Auslastung. In der SFOS-22-Dokumentation kommt /log/system-monitor/memory_trigger.log für hohe Speicherauslastung hinzu; auf SFOS 21.5 sollte man diese Datei nicht voraussetzen.

Ein voller Datenträger, starke I/O-Last oder ein SSD-Fehler sind unterschiedliche Probleme. Reports oder Logs werden deshalb nicht auf Verdacht gelöscht. Für die lesende Prüfung und vorgesehene Bereinigung dient Sophos Firewall Speicherplatz und Reports prüfen; den Hardwarezustand des Datenträgers erklärt Sophos Firewall SSD-Gesundheit per SMART prüfen.

Strom, Temperatur oder Hardware

Bei einer physischen XGS werden Stromversorgung, Netzteile, UPS/PDU, Racktemperatur, Luftstrom, Lüfter, LEDs, SSD und die lokale Konsole geprüft. Eine fehlende saubere Shutdown-Spur kann zu einem abrupten Stromereignis passen, beweist es aber nicht. Massgebend ist die gemeinsame Zeitlinie aus Firewall, UPS/PDU, Monitoring und Umgebung.

Eine aktuelle Temperatur nach dem Reboot ist ebenfalls nur ein Momentwert. Die Prüfung von Temperatur, Lüftern und xgs-healthmond.log erklärt den thermischen Ursachenast. Wiederkehrende Boot-, I/O-, Netzteil-, NPU- oder Lüfterfehler gehören mit den gesicherten Daten in die Vorbereitung eines Hardware- und RMA-Falls.

Virtuelle Firewall oder Cloud-Appliance

Bei einer VM werden zusätzlich Hypervisor-Events, Host-Neustarts, Datastore-Latenz, Snapshot- oder Backup-Jobs, vCPU, RAM, Disks und vNICs zum selben Zeitpunkt geprüft. Bei AWS oder Azure gehören Plattformereignisse, Instanzstatus und geplante Wartungen in die Incident-Zeitleiste.

Ein Host- oder Plattformereignis kann die VM neu starten, ohne dass SFOS selbst die Ursache gesetzt hat. Umgekehrt beweist ein unauffälliger Hypervisor noch keinen fehlerfreien Gast. Beide Zeitlinien werden deshalb gemeinsam bewertet. Die aktuellen Plattform- und Ressourcenunterschiede erklärt Sophos Firewall als Hardware, VM oder Cloud-Appliance.

Betrieb nach dem Neustart kontrollieren

Eine erreichbare Loginseite ist noch kein vollständiger Abnahmetest. Nach der Beweissicherung werden passend zur Umgebung geprüft:

Control Center ohne neue Service-, Interface-, VPN- oder Performance-Warnung; zusätzlich System graphs und Notifications auf Memory- und Disk-Auffälligkeiten prüfen
WAN, Routing, DNS und Internetzugang über den erwarteten Pfad
wichtige Site-to-Site- und Remote-Access-VPN-Verbindungen
zentrale DNAT-, WAF- oder Serverpublikationen
DHCP, RED und Wireless, wenn die Firewall diese Dienste bereitstellt
bei HA: Health, Rollen, Synchronisierung und Uptime beider Nodes
neue System-, Kernel- oder Hardwarefehler seit dem Start

Die wichtigsten realen Geschäftsflüsse sollten bewusst getestet und mit Uhrzeit dokumentiert werden. Bleibt die Uptime stabil, zeigt das nur, dass kein weiterer Reboot aufgetreten ist. Die ursprüngliche Ursache gilt erst als geklärt, wenn Zeitlinie, Logs und Plattformbeobachtungen eine belastbare Erklärung ergeben.

Supportfall und künftige Erkennung vorbereiten

Ein Sophos Supportticket ist sinnvoll, wenn der Reboot ungeklärt bleibt, erneut auftritt, einen HA- oder Standortausfall verursacht hat oder Hinweise auf Kernel, Speicher, Storage, NPU beziehungsweise Hardware vorliegen. In den Case gehören Incident-Zeitpunkt mit Zeitzone, Plattform, vollständiger Build, Uptime, betroffene Funktionen, letzte Änderungen, HA-Rollen, CTR, vollständige relevante Logs und die externe Strom- oder Hypervisor-Zeitlinie.

Für den nächsten Vorfall verbessert eine vorbereitete Überwachung die Beweislage:

E-Mail-Benachrichtigungen für System started, Restart/Shutdown und HA-Statusänderungen zustellen lassen.
System- und HA-Events an Syslog oder SIEM senden, damit die Zeitlinie ausserhalb der Firewall erhalten bleibt.
Uptime und Hardwarezustand per SNMP Monitoring überwachen.
UPS/PDU-, Hypervisor- und Cloud-Alarme mit demselben Zeitserver und einer klaren Standortzuordnung betreiben.

Damit lässt sich beim nächsten Ereignis schneller entscheiden, ob SFOS selbst, ein einzelner Node, die Plattform oder die Strom- und Hardwareumgebung den Ausfall ausgelöst hat.