Sophos Firewall Log Viewer richtig nutzen

Der Log Viewer ist in SFOS 22 oft der schnellste Einstieg in eine Störung: Welche Firewall-Regel hat den Traffic verarbeitet, welche NAT-Regel war beteiligt, welcher Benutzer wurde erkannt und welches Security-Modul hat blockiert? Damit die Antwort stimmt, müssen Modul, Zeitraum, Filter und Zeitpunkt des Logeintrags zusammenpassen.

Der Log Viewer zeigt protokollierte Ereignisse. Er ist kein Packet Capture und keine vollständige Verbindungshistorie. Ein fehlender Eintrag beweist deshalb weder einen Drop noch, dass das Paket die Firewall erreicht hat.

Für eine belastbare Analyse werden immer Source, Destination, Service, genaue Testzeit und erwartete Richtung notiert. Danach wird genau ein neuer Testflow erzeugt und in den passenden Modulen gesucht.

Einen Test in sieben Schritten auswerten

1. In der betroffenen Firewall-Regel Log firewall traffic beziehungsweise in der SSL/TLS-Regel Log connections prüfen.
2. Unter System services > Log settings sicherstellen, dass der benötigte Logtyp bei Local reporting aktiviert ist.
3. Oben rechts im WebAdmin Log viewer (SFOS 22) beziehungsweise Logs and policy test (SFOS 23) öffnen und danach das fachlich passende Logmodul wählen.
4. Zeitfilter setzen und über Add filter zuerst Source-IP, Destination-IP und Service eingrenzen.
5. Einen neuen, kurzen Testflow erzeugen und seine genaue Uhrzeit notieren.
6. In Detailed view Rule ID, NAT ID, Action, Interfaces, Benutzer und modulspezifische Felder prüfen.
7. Wenn Eintrag und beobachtetes Verhalten nicht zusammenpassen, denselben Test mit Packet Capture korrelieren, bevor eine Regel geändert wird.

Diese Reihenfolge trennt drei häufig vermischte Fragen: Wurde überhaupt ein Log erzeugt? Welche Policy hat entschieden? Und sind die Pakete tatsächlich ein- und wieder ausgegangen?

Event Logs erfassen neben Traffic auch Authentifizierung, Systemereignisse und Konfigurationsänderungen und werden standardmässig lokal gespeichert. Troubleshooting Logs sind dagegen detaillierte Dienstlogs, die man über WebAdmin oder CLI auswertet. Der Service-Log-Ablauf erklärt Zugriff und Debug-Erfassung. Debug belegt zusätzlichen Speicher und muss nach der benötigten Erfassung wieder ausgeschaltet werden; es ist kein Schalter für fehlende Event Logs.

Für die zentrale Übertragung muss die Firewall für Sophos Central Firewall Management registriert sein. Danach werden die Central Services und Send reports and logs to Sophos Central eingeschaltet und die benötigten Logtypen unter System services > Log settings ausgewählt. Die berücksichtigte SFOS-22-Dokumentation nennt das Ziel Sophos Fusion, die SFOS-23-Dokumentation Sophos Central; die genannten UI-Felder bleiben massgeblich. Der Central-Reporting-Ablauf führt durch Einrichtung und Empfangskontrolle.

Logeinträge richtig lesen

Warum Logeinträge nicht immer sofort erscheinen

Der Log Viewer aktualisiert die Ansicht automatisch. Eine Firewall-Session wird jedoch normalerweise erst protokolliert, wenn die Firewall ein Destroy-Event erhält und die Verbindung schliesst. Bei einer langen Sitzung kann der Logeintrag deshalb später erscheinen als der erste Request.

Bricht eine Verbindung ab, ohne dass die Firewall ein Destroy-Event erhält, etwa bei einem Verlust der Internetverbindung, kann der erwartete Sessionlog ganz fehlen. SSL/TLS-Verbindungen werden nach erfolgreichem Handshake und beim Schliessen protokolliert. Für einen kurzen Test ist daher eine bewusst beendete Verbindung besser als eine dauerhaft offene Browser-, Streaming- oder HTTP/2-Session.

Ein Browser-Reload erzeugt nicht zwingend eine neue Verbindung. Für reproduzierbare Tests eignet sich je nach Anwendung ein privates Browserfenster, ein neu gestarteter Clientprozess oder ein kurzer Aufruf wie:

curl -I https://example.com/

Der Befehl läuft auf dem Testclient, nicht in der Firewall-Shell. example.com ist eine reservierte Beispieldomain und kann durch einen bekannten, erlaubten Dienst ersetzt werden.

Das richtige Modul wählen

Ein Datenstrom kann mehrere Logmodule berühren. Das Modul Firewall zeigt beispielsweise, dass eine LAN-to-WAN-Regel die Verbindung erlaubt. Ein Web filter, Application filter, IPS oder SSL/TLS inspection kann denselben Datenstrom später trotzdem blockieren oder anders behandeln.

Darum reicht ein einzelner grüner Firewall-Eintrag bei Web- oder Security-Problemen nicht. Die Module werden für denselben Testflow anhand des Testzeitraums und der Adressen korreliert:

• Firewall: Regelentscheidung, NAT, Interfaces, Ports und grundlegender Verbindungsstatus.
• Web filter: URL-, Kategorie- und Web-Policy-Entscheidungen.
• SSL/TLS inspection: Zertifikats-, Handshake- und Decryption-Entscheidungen.
• Application filter: erkannte Anwendung und Application-Control-Aktion.
• IPS: Signatur- oder Anomalieereignisse.
• VPN: Aufbau und Status der jeweiligen VPN-Komponente.
• Authentication: erkannter Benutzer sowie erfolgreiche oder fehlgeschlagene Anmeldung.
• System: System- und administratorausgelöste Ereignisse.
• SD-WAN: SD-WAN-Profil-, SLA- und Routennutzung.

Welche Logtypen lokal erscheinen, wird unter System services > Log settings in Local reporting festgelegt. Diese Event Logs sind nicht dasselbe wie On-box Reports. Central reporting und Syslog sind wiederum eigene Ziele und müssen separat aktiviert werden. Web-Policy-Ereignisse setzen ausserdem Log firewall traffic in der zugehörigen Firewall-Regel voraus. Wireless-Logs sind im Log Viewer nicht verfügbar; sie müssen an Sophos Fusion (ehemals Sophos Central) oder einen Syslog-Server gesendet werden.

Web-Proxy-Grenze: Die SFOS-22/23-Dokumentation zum Logverhalten beschreibt diesen Proxy-Pfad für HTTP/HTTPS auf den Ports 80 und 443: Eine passende Drop-Regel übergibt eingehende Pakete an den Web Proxy, der dem Benutzer eine Blockseite liefert; ohne passende Web Exception zeigt der Firewall-Log Allowed und der Web-Filter-Log Blocked. Web Exceptions gelten weiterhin und können Requests trotz Drop erlauben. Der dokumentierte Reject-Pfad beendet den Datenstrom vor der Proxy-Verarbeitung. Firewall-Regel, Web Policy und Web Exceptions werden gemeinsam geprüft; das ist ein dokumentiertes Szenario, keine allgemeine Blockseiten-Garantie für jeden Build oder Inspektionsmodus.

Ungeklärter Dokumentationswiderspruch: Die SFOS-22/23-Hilfe zum Regelformular beschreibt die Authentifizierung unbekannter Webbenutzer bei aktiviertem Use web authentication for unknown users, erlaubt passende Web Exceptions und beschreibt ansonsten eine HTML-Blockseite. Die Anleitung zum Logging verworfenen Traffics beschreibt dagegen stilles Verwerfen und verknüpft die Web-Blockseite mit dieser Authentifizierungsoption. Daraus folgt nicht, dass die Option allein die Antwort bestimmt. Bevor man sich für Web-Blocking auf Drop verlässt, braucht es eine schriftliche Sophos-Klärung für die genaue Version, den Build und Verarbeitungspfad oder eine ausdrücklich autorisierte, isolierte Verifikation. Aktuelle Regel und Einstellungen für den Rollback festhalten; HTTP und HTTPS getrennt, bekannte/unbekannte Benutzer, Authentifizierung ein/aus und passende Exceptions vorhanden/nicht vorhanden prüfen. Neue Flows mit Rule ID, Logs, Packet Capture und Browserbefund korrelieren. Weder Blockseite noch Timeout allein beweisen Blocking. Bei unerwartetem Zugriff oder unklarem Ergebnis Teständerungen zurücknehmen und eskalieren; nicht produktiv ausrollen.

Bei anderen Ports verwirft eine passende Drop-Regel die Pakete direkt; der Firewall-Log zeigt dropped. Bei Reject zeigt der Firewall-Log rejected, sowohl auf den Ports 80/443 als auch auf anderen Ports. Voraussetzung für diese Beobachtungen ist Log firewall traffic in der passenden Regel. Eine Web Exception kann beispielsweise Windows-Updates von Microsoft trotz einer Drop-Regel erlauben; das ist kein Anlass, die Regel ungeprüft weiter zu öffnen.

Allow-Regel und fehlender Heartbeat

Ein anderer Fall als Drop liegt vor, wenn die tatsächlich passende Firewall-Regel die Action Allow hat, Block clients with no Heartbeat aktiviert ist und der Endpoint keinen Heartbeat sendet. Für die beschriebenen Logbeobachtungen muss Log firewall traffic in dieser Regel aktiviert sein. Vor der Suche prüft man zusätzlich unter System services > Log settings die benötigten Logtypen bei Local reporting; ein aktiviertes externes Logziel allein reicht für die lokale Anzeige nicht.

• Andere Ports als 80 und 443: Die Firewall verwirft die Pakete dieses Endpoints. Der Firewall-Log zeigt dropped.
• Ports 80 und 443 im dokumentierten Web-Proxy-Pfad: Die Firewall nimmt die eingehenden Pakete an und übergibt sie an den Web Proxy. Weil der Endpoint keinen Heartbeat sendet, entscheidet das Heartbeat-System auf Blockieren; der Proxy liefert dem Benutzer eine Blockseite. Der Firewall-Log zeigt allowed, ein weiterer Firewall-Log Heartbeat blocked und der Web filter-Log blocked. Heartbeat blocked gehört hier also ebenfalls zum Firewall-Modul, nicht zu einem separaten Heartbeat-Logmodul.

Allowed allein beweist keinen erfolgreichen Zugriff. Vor einer Regeländerung korreliert man die Einträge anhand desselben Testflows: Testzeitraum, Source und Destination, Ports und passende Regel werden gemeinsam geprüft. Dabei sucht man nach dem separaten Heartbeat blocked-Eintrag und dem Web filter-Eintrag mit blocked. Eine feste Ereignisreihenfolge, identische Zeitstempel oder eine universelle Anzahl von Logzeilen sind dafür keine Voraussetzung; fehlen erwartete Einträge, werden zuerst Logging, lokale Ziele und Filter geprüft und bei Bedarf Packet Capture herangezogen.

Diese Einordnung gilt für genau diese Regeloption, einen Endpoint ohne Heartbeat und den beschriebenen Proxy-Pfad. Sie ist keine allgemeine Aussage über jede Allow-Regel, rote oder anderweitig ungesunde Endpoints oder andere Inspektionsmodi. Heartbeat-Erzwingung wird nicht als pauschale Fehlerbehebung deaktiviert; zuerst werden Regelmatch und fehlender Heartbeat geklärt.

Standard view und Detailed view unterscheiden

Die Standardansicht ist gut zum schnellen Lesen. Spalten können ein- und ausgeblendet werden, und ein Klick auf einen Wert kann ihn direkt als Filter übernehmen. Für technische Abnahmen ist die Detailed view wichtiger, weil sie die zugrunde liegenden Feldnamen und zusätzliche Werte zeigt.

In Standard view zeigt auch das Bewegen des Mauszeigers über ein Modulicon weitere Details. Mit der Kopierfunktion lassen sich Loginformationen in die Zwischenablage übernehmen. Der Viewer öffnet sich in einem neuen, bildschirmfüllenden Browserfenster; bleibt es aus, prüft man zuerst den Popup-Blocker des Browsers.

Eine wichtige NAT-Besonderheit: Wird eine andere übersetzte Source-Adresse als die standardmässige MASQ-Adresse verwendet, kann die Standardansicht trotzdem die MASQ-Adresse als ausgehende Adresse anzeigen. Die tatsächlich übersetzte Source steht in der Detailed view im Feld src_trans_ip.

Typische Felder für einen Firewall-Test sind:

• Source- und Destination-IP sowie Source- und Destination-Port
• In interface und Out interface
• Firewall Rule ID und NAT Rule ID
• Action beziehungsweise Status
• Benutzername, falls eine Identität erkannt wurde
• übersetzte Source und Destination
• Log component und Log subtype

Ein Feldname oder eine ID erklärt die Ursache noch nicht automatisch. Die Rule ID wird mit der aktuellen Regelbasis abgeglichen, die NAT ID mit der passenden NAT-Regel und eine Security-Policy-ID mit dem jeweiligen Modul.

Ist unter Diagnostics > Packet capture gleichzeitig ein Packet Capture aktiv, kann Open PCAP beim passenden Logeintrag die zugehörigen Paketinformationen öffnen. Die Funktion verbindet Logentscheidung und Paketdetails, ersetzt aber keinen sauber begrenzten Capture-Filter: Source, Destination, Port und Testzeit müssen weiterhin zum untersuchten Flow passen.

Den richtigen Flow eingrenzen

Filter so setzen, dass der richtige Flow übrig bleibt

Im Log Viewer stehen vier Filterebenen zur Verfügung:

1. Module: Begrenzt die Ansicht auf Firewall, Web, IPS, VPN oder ein anderes Fachgebiet.
2. Time / Timer filter: Begrenzt die Ereignisse auf den Testzeitraum; über Timer filter wird die passende Zeitoption gewählt.
3. Add filter: Verknüpft ein konkretes Feld, eine Bedingung und einen Wert.
4. Free text search: Sucht beispielsweise nach Port, IP-Adresse, Benutzer oder Regelname und funktioniert auch mit anonymisierten Informationen.

Für einen normalen Verbindungstest beginnt man mit Source-IP, Destination-IP und Destination-Port. Danach wird mit Rule ID, Benutzer oder Action weiter eingegrenzt. Reset entfernt alle gesetzten Filter. Das ist wichtig, weil ein alter Zeit- oder Feldfilter leicht den Eindruck erweckt, der Viewer erhalte keine neuen Events.

Die Anzahl verfügbarer Einträge hängt von der Festplattengrösse und lokalen Aufbewahrung ab. Der Log Viewer ist deshalb kein Ersatz für eine langfristige, manipulationsgeschützte Ablage. Dafür passen Central Firewall Reporting oder Syslog an ein SIEM senden.

Das lokale Event-Log-Kontingent hängt vom Appliance-Modell ab: Für grössere Modelle nennt Sophos bis zu 15 Prozent der gesamten /var-Partition oder 50 Prozent ihres freien Speichers, je nachdem, welcher Wert kleiner ist. Das ist keine garantierte Aufbewahrungsdauer und keine Quote für jedes Modell. Die Speicherplatzanalyse trennt Event Logs, Reports und Troubleshooting Logs; Dateien werden nicht auf Verdacht gelöscht.

Pause, Refresh und CSV-Export richtig verwenden

Pause stoppt die automatische Aktualisierung der Ansicht. Das ist hilfreich, wenn eine Zeile in Ruhe gelesen oder kopiert werden soll. Es stoppt nicht die Protokollierung auf der Firewall. Refresh lädt die Ansicht manuell neu, und der Export lädt die aktuell verfügbaren Logs als CSV herunter.

Vor einem Export werden Modul, Zeitbereich und Filter dokumentiert. Die CSV kann interne IP-Adressen, Benutzernamen, URLs und Kommunikationsbeziehungen enthalten und gehört deshalb in einen geschützten Support- oder Analysepfad.

Wenn Data anonymization aktiv ist, werden identifizierende Werte wie Benutzername, IP-, MAC- und E-Mail-Adresse geschützt dargestellt. Sophos empfiehlt mindestens zwei berechtigte Personen: Ist die angemeldete Person selbst als Authorizer eingetragen, muss mindestens eine andere Person die Deanonymisierung freigeben. Ein Screenshot oder Export sollte trotzdem nur die für den Fall nötigen Zeilen enthalten.

Zum Anzeigen der Identitäten über die Deanonymisierungsfunktion braucht man die entsprechende Berechtigung und muss seine Authentifizierungsdaten angeben. Das Kopieren einer Zeile ist kein Ersatz für diese Freigabe.

Log suppression und Log occurrence verstehen

Unter System services > Log settings kann die Firewall aufeinanderfolgende, gleiche Firewall-Events unterdrücken. Das spart Speicher und Verarbeitung. Die Unterdrückung wirkt nicht nur lokal, sondern auch auf Sophos Fusion und konfigurierte Syslog-Ziele.

Im Log Viewer zeigt Log occurrence, wie oft ein zusammengefasstes Event aufgetreten ist. Eine einzelne Zeile kann deshalb viele Wiederholungen repräsentieren. Sie darf nicht automatisch als ein einzelnes Paket oder eine einzelne Verbindung gezählt werden.

Vor einer Änderung an Log suppression wird geprüft, ob das aktuelle Loggingvolumen wirklich die Ursache eines Problems ist. Für eine kurze Diagnose genügt meistens, Log occurrence bewusst zu lesen. Eine globale Abschaltung oder Aktivierung verändert auch die externen Logziele und sollte nicht nur für einen Screenshot erfolgen.

Befunde sicher einordnen

Invalid traffic richtig einordnen

Invalid traffic bedeutet, dass Conntrack ein Paket keiner aktuellen Verbindung zuordnen konnte. Das kann bei einem asymmetrischen Pfad, einer abgelaufenen Session, unerwarteten TCP-Flags oder zusätzlichen RST- und FIN-Paketen auftreten. Es ist nicht automatisch ein Angriff und nicht automatisch ein Firewall-Defekt.

Invalid-Traffic-Logging ist standardmässig eingeschaltet. Conntrack verfolgt TCP-Sessions sowie bestimmte UDP- und ICMP-Sessions; initialisierende Pakete wie ein TCP-SYN oder ein ICMP Echo Request legen den Verbindungsbezug an. Für die Analyse der TCP-Flags hilft folgende Einordnung:

• SYN: fordert die Synchronisierung an.
• SYN-ACK: bestätigt sie und stimmt Verbindungsparameter ab.
• ACK: bestätigt die Vereinbarung; die Datenübertragung kann beginnen.
• PSH: fordert die unmittelbare Datenweitergabe an.
• FIN: fordert das geordnete Ende an; beide Seiten bestätigen den Abschluss.
• RST: beendet die Verbindung ohne auf eine Antwort zu warten, etwa nach einem unerwarteten Paket.

Zusätzliche RST- und FIN-Pakete können verworfen und als Invalid traffic protokolliert werden. Ein einzelner solcher Eintrag wird deshalb mit dem tatsächlichen Verbindungsproblem abgeglichen, statt als eigenständiger Angriff gewertet zu werden.

Wenn gleichzeitig ein Verbindungsproblem besteht, werden beide Richtungen mit Packet Capture geprüft. Source, Destination, TCP-Flags, Interfaces und Zeitstempel müssen zum selben Flow gehören. Eine Erhöhung von Tcp Connection Establishment Idle Timeout kann die Anzahl solcher Logs reduzieren, behebt aber die zugrunde liegende Pfad- oder Sessionursache nicht. Der Wert wird deshalb nicht auf Verdacht geändert.

Den aktuellen globalen Wert zeigt in der Device Console der lesende Befehl show advanced-firewall; Sophos dokumentiert 10800 Sekunden beziehungsweise drei Stunden als Standard. Eine Änderung wirkt auf alle entsprechenden TCP-Sessions der Firewall. Vorher werden deshalb betroffene Anwendung, tatsächliche Leerlaufzeit und das Invalid-Traffic-Ereignis eindeutig korreliert. Ein höherer Timeout ist nur eine begründete Betriebsanpassung und keine Reparatur für asymmetrisches Routing oder verlorene Pakete.

Die Quelle bezeichnet das Feld als Tcp Connection Establishment Idle Timeout, beschreibt aber ablaufende Conntrack-Einträge nach Leerlauf und verwendet den Setter tcp-est-idle-timeout. Diese Benennung ist missverständlich; sie ist kein Beleg für einen separaten Handshake-Timeout. Massgeblich sind die tatsächliche Ausgabe und die CLI-Hilfe des eigenen Builds.

Die CLI-Referenz für SFOS 22/23 ordnet tcp-est-idle-timeout ausdrücklich bereits aufgebauten TCP-Verbindungen zu und erlaubt 2700 bis 432000 Sekunden. Die abweichende Feldbenennung wird daher nicht als Empfehlung zum Verändern eines Verbindungsaufbau-Timeouts verwendet.

Nur wenn ein bestätigter Idle-Timeout-Fall eine globale Anpassung rechtfertigt, wird an der CLI 4. Device Console gewählt, der bisherige Wert mit show advanced-firewall gesichert und ein Wartungsfenster vereinbart. Das dokumentierte Beispiel erhöht auf sechs Stunden, nicht auf einen allgemein empfohlenen Wert:

set advanced-firewall tcp-est-idle-timeout 21600
show advanced-firewall

Danach wird der neue Wert geprüft und dieselbe Anwendung über die relevante Leerlaufphase erneut getestet. Weniger Invalid-Traffic-Einträge allein beweisen keine Reparatur. Für den Rückweg setzt man mit demselben Setter die zuvor gesicherte Sekundenzahl und kontrolliert erneut mit show advanced-firewall; 10800 ist nur dann der Rückwert, wenn dies der ursprüngliche Wert war. Bei unklarer CLI-Ausgabe oder weiter bestehendem Fehler stoppt man die Anpassung und prüft den Paketpfad beziehungsweise zieht Support hinzu.

Den vollständigen Drop-Ablauf mit Reason, Rule ID und der besonderen Firewall ID 0 erklärt Verworfene Pakete auf Sophos Firewall analysieren.

Regeln aus dem Log Viewer nur kontrolliert ändern

Der Log Viewer kann je nach Ereignis direkt zu Web Policies, NAT-, Firewall- oder SSL/TLS-Regeln führen. Ein Klick auf die Web Policy, NAT-Regel oder Firewall-Regel bietet den Link zurück zur Bearbeitung im WebAdmin. Das ist praktisch, verkürzt aber nicht die technische Prüfung. Vor dem Bearbeiten werden Rule ID, Regelname, Position, Zonen, Objekte, Service, Benutzerbezug und vorhandene Sessions kontrolliert; zusätzlich werden die aktuellen Werte der zu ändernden Felder für den Rollback dokumentiert.

Für eine SSL/TLS-Ausnahme wählt man das Modul SSL/TLS inspection, scrollt zur Spalte Manage, wählt Exclude, prüft die Option im Dialog und bestätigt erst danach mit Exclude. Domain und Subdomain werden zur URL-Gruppe Local TLS exclusion list hinzugefügt, die unter Categories and websites der SSL/TLS-Regeln erscheint. Web category landet in Exclusions by website or category, sichtbar auf der SSL/TLS-Regellistenseite. Für Other properties wählt man die SSL/TLS-Regel und passende Objekte wie Benutzername oder IP-Adresse. Vor dem Bestätigen werden Zielobjekt und Ausnahmeumfang geprüft; Domain-Ausnahmen dürfen nicht mit einer nur für einen Benutzer gedachten Ausnahme verwechselt werden. Für 19004 (erlaubter Traffic) und 19005 (durch Web Policy blockiert) bietet der Log Viewer Exclude nicht an.

Ein Klick auf eine IPS Signature ID kann Disable signature for this IPS policy anbieten. Das ändert die aktive IPS Policy und nicht nur die Anzeige. Vorher werden betroffene Regel, Policy, Signatur, Schutzwirkung und Ausnahmeumfang dokumentiert; danach wird genau der bestätigte Flow erneut getestet.

Eine breite Allow-Regel, eine globale Web-Ausnahme oder deaktivierte TLS Inspection kann das Symptom verstecken und gleichzeitig eine neue Sicherheitslücke schaffen. Änderungen werden deshalb auf den bestätigten Flow begrenzt, in einem Wartungsfenster getestet und danach mit einem neuen Flow erneut im Log Viewer sowie bei Bedarf in Packet Capture abgenommen. Schlägt der Test fehl oder wird der Ausnahmeumfang zu gross, stellt man im verlinkten Regel- oder Policy-Objekt den zuvor dokumentierten Zustand wieder her und prüft erneut mit einem neuen Flow.

Wenn Logs fehlen oder auf dem anderen HA-Knoten liegen

Wenn erwartete Logs fehlen

Ein leerer Treffer wird in dieser Reihenfolge geprüft:

1. Pause, Modul, Zeitbereich und Filter kontrollieren, danach Reset und Refresh.
2. Rule Logging und Local reporting für den benötigten Logtyp prüfen.
3. Eine neue, bewusst beendete Verbindung mit bekannter Uhrzeit erzeugen.
4. Mit Packet Capture bestätigen, dass der Traffic die Firewall erreicht und welche Rule ID verarbeitet wird.
5. Andere Module auf Ereignisse desselben Flows prüfen.
6. Erst wenn die gesamte lokale Anzeige keine neuen Events erhält, den Viewer- oder Logdienstpfad untersuchen.

Der versionsgebundene Diagnosepfad für einen vollständig stehenden Viewer steht in Log Viewer zeigt keine neuen Logs. Ein Service-Restart oder Eingriff in die lokale Logdatenbank gehört nicht zu den allgemeinen Bedienungsschritten.

Log Viewer in HA-Umgebungen

Jeder HA-Node speichert nur die Logs und Reports des Traffics, den er selbst verarbeitet. Besonders bei Active-Active oder nach einem Failover kann der erwartete Eintrag deshalb auf dem anderen Node liegen. Zeitpunkt, Node-Rolle und Connection served by werden gemeinsam dokumentiert.

Für eine zentrale Sicht eignen sich Central Firewall Reporting oder Syslog. Sie ersetzen aber nicht die nodebezogene Prüfung, wenn es um einen konkreten HA-Rollenwechsel, einen lokalen Dienstfehler oder den Datenpfad zum Ereigniszeitpunkt geht.