Sophos Firewall Log Viewer zeigt keine neuen Logs

Zeigt der Log Viewer keine neuen Events, sollte man nicht sofort einen Dienst neu starten. Zuerst muss klar sein, ob nur ein erwarteter Eintrag fehlt oder ob die lokale Loganzeige insgesamt steht. Für normale Bedienung, Filter und Feldinterpretation gilt zuerst Sophos Firewall Log Viewer richtig nutzen. Der sichere Ausfall-Schnellweg ist:

Im Log Viewer Pause, Modul, Zeitraum und gesetzte Filter prüfen, danach Reset und Refresh ausführen.
In der betroffenen Firewall-Regel Log firewall traffic und unter System services > Log settings den Logtyp Firewall bei Local reporting kontrollieren.
Von einem bekannten Testclient eine kurze Verbindung erzeugen und den Zeitpunkt notieren.
Mit Packet capture prüfen, ob der Traffic die Firewall erreicht und welche Rule ID verarbeitet wird.
Nur wenn auch andere erwartete Events ausbleiben, SFOS-Version, vollständigen Build und den letzten sichtbaren Logzeitpunkt sichern.
Den Garner-Workaround nur auf SFOS 21.5 MR1 Build 261 und nur beim unten beschriebenen Fehlerbild verwenden.

So bleibt die Fehlersuche nachvollziehbar: Ein falscher Filter oder eine nicht protokollierende Regel wird nicht mit einem Logging-Datenbankfehler verwechselt.

Warum ein einzelner Logeintrag fehlen kann

Der Log Viewer aktualisiert sich normalerweise automatisch. Er zeigt aber nur Events, die das ausgewählte Modul lokal speichert und die nicht durch die aktuelle Ansicht ausgeblendet werden.

Häufige Ursachen ohne technischen Viewer-Ausfall sind:

Pause ist aktiv: Neue Events werden erst nach Fortsetzen oder manuellem Refresh sichtbar.
Modul, Zeitraum oder Filter passen nicht: Reset entfernt alle Filter; danach wird das fachlich passende Modul erneut gewählt.
Rule Logging ist deaktiviert: Firewall-Sessions erscheinen nur, wenn in der tatsächlich matchenden Regel Log firewall traffic aktiv ist.
Local reporting ist deaktiviert: Unter System services > Log settings muss der benötigte Logtyp in der Spalte Local reporting ausgewählt sein.
Die Verbindung ist noch offen: Firewall-Sessions werden normalerweise beim Destroy-Event protokolliert, wenn die Verbindung endet. Ein Eintrag kann deshalb später erscheinen als der erste Verbindungsaufbau.
Der Traffic erreicht die Firewall nicht: Ein fehlender Logeintrag beweist nicht, dass die Firewall das Paket verworfen hat. Der Client, ein vorgeschalteter Router, DNS oder ein anderer Pfad kann die Verbindung bereits vorher verhindern.
Firewall Log suppression fasst Wiederholungen zusammen: Unterdrückte Firewall-Folgeevents können in Log occurrence zusammengefasst sein, statt als viele einzelne Zeilen zu erscheinen.

Wenn der Log Viewer weiterhin neue System- oder Firewall-Events aus anderen Tests zeigt, arbeitet die Anzeige grundsätzlich. Dann liegt die Ursache eher bei Regel-Logging, Modulwahl, Filter, Sessionende oder dem tatsächlichen Paketpfad. Für diese Abgrenzung ist Firewall-Regel mit Log Viewer, Policy Tester und Packet Capture prüfen der passendere Ablauf.

Einen kontrollierten Testfluss erzeugen

Ein reproduzierbarer Test ist belastbarer als das Warten auf zufälligen Benutzertraffic. Im folgenden Beispiel hat der Testclient die anpassbare IP-Adresse 10.20.30.25. Auf dem Client – nicht in der Firewall-Shell – wird eine kurze HTTPS-Verbindung aufgebaut:

curl -I https://example.com/

example.com ist eine reservierte Beispieldomain. Für den Test kann auch ein eigener bekannter und erlaubter HTTPS-Dienst verwendet werden. Entscheidend ist, dass der Prozess die Verbindung wieder beendet und Zeitpunkt, Client-IP und Ziel bekannt sind.

Danach wird in dieser Reihenfolge geprüft:

In Rules and policies > Firewall rules kontrollieren, ob die erwartete Regel Log firewall traffic aktiviert hat.
Im Log Viewer Reset ausführen, das Modul Firewall und einen passenden Zeitraum auswählen und nach 10.20.30.25 filtern.
Einige Sekunden warten und einmal manuell aktualisieren, weil das Firewall-Event erst nach dem Sessionende erscheinen kann.
Fehlt der Eintrag, unter Diagnostics > Packet capture einen engen Filter wie host 10.20.30.25 verwenden und denselben Test wiederholen.

Die Beobachtung bestimmt den nächsten Schritt:

Packet Capture sieht keinen Testtraffic: Ursache vor der Firewall oder am Client suchen.
Packet Capture sieht eine andere Rule ID: Die tatsächlich matchende Regel und deren Logging prüfen.
Andere neue Log-Viewer-Events erscheinen: Der Viewer steht nicht vollständig; Filter, Logtyp und konkrete Regel weiter untersuchen.
Packet Capture bestätigt den Flow, Rule Logging und Local reporting stimmen, aber alle neuen Events bleiben aus: Build und lokale Logverarbeitung prüfen.

Packet Capture zeigt den Paketfluss, repariert aber keine Loganzeige. Die Bedienung und Statuswerte erklärt Packet Capture im Sophos Firewall WebAdmin.

`NC-175936` auf SFOS 21.5 MR1 Build 261 prüfen

Sophos dokumentiert für SFOS 21.5 MR1 Build 261 den Fehler NC-175936: Die Datei /tmp/eventlogs/active.db kann fehlen, wodurch der Log Viewer keine neuen Daten mehr anzeigt. Laut Sophos verarbeitet die Firewall den Traffic dabei weiter; die Sicherheitsfunktionen bleiben aktiv. Diese Aussage beschreibt den bekannten Fehler und ist kein allgemeiner Gesundheitsnachweis für eine Firewall ohne Logs.

Die aktuelle Sophos Known Issues List nennt für 21.5 MR2 kein eindeutiges Fix-Versionsfeld. Deshalb wird der folgende Workaround nicht allein aufgrund eines ähnlichen Symptoms auf anderen Builds eingesetzt.

Lesende Pre-Checks in der Advanced Shell

Zuerst werden vollständiger Build, Zeitpunkt, letzter sichtbarer Event und bei HA der betroffene Node notiert. Wenn WebAdmin noch funktioniert, werden garner.log und möglichst ein Consolidated Troubleshooting Report vor der Änderung gesichert.

Danach verbindet man sich über den dokumentierten SSH-Zugang zur Sophos Firewall und öffnet die Advanced Shell. Die folgenden Befehle lesen nur Speicherzustand, Datei und Log:

df -kh /tmp
ls -l /tmp/eventlogs/active.db
tail -n 200 /log/garner.log

df -kh /tmp zeigt, ob auf dem Dateisystem noch Platz frei ist. ls -l bestätigt, ob active.db existiert; fehlt sie, kann die Shell je nach Build eine Meldung wie No such file or directory ausgeben. garner.log wird nach Fehlern zum dokumentierten Testzeitpunkt geprüft. Weitere Dienstnamen und Logdateien ordnet Sophos Firewall Service-Logs richtig zuordnen ein.

Ist /tmp voll, die Datei vorhanden, der Build abweichend oder das Symptom nicht eindeutig, wird der folgende Neustart nicht ausgeführt. Dateien unter /tmp/eventlogs werden weder gelöscht, kopiert noch manuell angelegt.

Garner einmal kontrolliert neu starten

⚠️ Zustandsverändernder Befehl: Dieser Workaround gilt nur für das belegte Fehlerbild auf SFOS 21.5 MR1 Build 261. Vorher Logs und Systemzustand sichern. In einem HA-Cluster den Befehl nicht ungeprüft auf beiden Nodes ausführen. Garner nicht wiederholt neu starten und active.db niemals manuell reparieren oder löschen.

Sophos nennt für NC-175936 in der Advanced Shell exakt diesen Befehl:

service garner:restart -ds nosync

Der Befehl wurde in diesem Artikel aus der aktuellen Sophos Known Issues List übernommen, aber nicht auf einer Appliance lab-getestet. Nach dem einmaligen Neustart werden Datei und letzte Garner-Meldungen erneut lesend geprüft:

ls -l /tmp/eventlogs/active.db
tail -n 50 /log/garner.log

Anschliessend im Log Viewer Reset und Refresh ausführen und denselben kurzen Testfluss wiederholen. Erfolgreich ist die Massnahme erst, wenn ein neuer Event mit passendem Zeitstempel erscheint. Eine vorhandene active.db allein beweist noch nicht, dass der komplette Logpfad wieder funktioniert.

Andere Builds und wiederkehrende Ausfälle

Sophos hat weitere, aber nicht identische Fehler rund um die Log-Viewer-Datenbank behoben. SFOS 22.0 MR1 Build 490 enthält mit NC-152553 einen Fix für einen fehlgeschlagenen Recovery-Mechanismus von active.db; NC-169237 zu verlorenen Log-Viewer-Events durch Datenbankkorruption ist für SFOS 21.5 MR2 Build 323 und SFOS 22.0 GA Build 411 aufgeführt. Diese Issue-IDs beweisen weder einen Fix für NC-175936 noch automatisch die Ursache eines aktuellen Ausfalls.

Auf einem älteren Build wird zuerst ein unterstützter SFOS-Firmware-Updatepfad geplant. Auf einem aktuellen Build oder nach einem erfolglosen Garner-Neustart werden keine weiteren Datenbank- oder Serviceeingriffe ausprobiert.

Für einen Support Case werden mindestens gesichert:

Appliance-Modell, SFOS-Version und vollständiger Build;
bei HA der betroffene Node und seine Rolle;
letzter sichtbarer Log-Viewer-Zeitstempel und Zeitpunkt des Testflusses;
Modul, Filter, Rule ID, Source, Destination und Service des Tests;
Zustand von Log firewall traffic und Local reporting;
Packet-Capture-Ergebnis;
Ausgabe von df -kh /tmp und ls -l /tmp/eventlogs/active.db;
garner.log, bei Bedarf fwlog.log und iview.log sowie nach Möglichkeit ein CTR vor weiteren Änderungen;
Information, ob der Garner-Neustart einmal ausgeführt wurde und was sich danach änderte.

So kann Sophos zwischen Anzeige-, Datenbank-, Speicher-, Dienst- und versionsspezifischem Fehler unterscheiden, ohne dass wiederholte Reparaturversuche die ursprüngliche Ursache verdecken.