Sophos Firewall verworfene Pakete analysieren

Ein verworfenes Paket ist nicht automatisch ein Fehler. Die Firewall kann den Traffic wie vorgesehen blockieren, legitimen Traffic unerwartet verwerfen oder den Datenstrom gar nicht sehen. Mit dem folgenden Ablauf lässt sich schnell unterscheiden, ob Regel, NAT, Rückweg, ein Security-Modul oder ein System vor der Firewall verantwortlich ist.

Drops in wenigen Minuten eingrenzen

1. Testfall notieren: Source-IP, Destination-IP, Port, Protokoll, Uhrzeit und erwartete Richtung festhalten. Bei sporadischen Fehlern zusätzlich Benutzer, Anwendung und letzte Konfigurationsänderung notieren.
2. Log Viewer filtern: Im Firewall-Modul nach IP-Adresse, Port und Uhrzeit suchen. Je nach Fall auch Web, SSL/TLS inspection, Application filter, IPS, Active threat response, Web server protection oder VPN öffnen.
3. Packet Capture starten: Unter Diagnostics > Packet capture einen engen Filter setzen, Capture aktivieren und genau einen reproduzierbaren Test durchführen.
4. Paketstatus lesen: Incoming, Forwarded, Consumed, Generated oder Violation zeigen, ob das Paket ankommt, weitergeleitet, lokal verarbeitet, von der Firewall erzeugt oder verworfen wird.
5. Entscheidung zuordnen: Rule ID, NAT ID und Reason mit der erwarteten Firewall- und NAT-Regel vergleichen. Bei Web-, IPS- oder Application-Treffern zusätzlich die jeweilige Policy-ID prüfen.
6. Rückrichtung erfassen: Wird der Hinweg weitergeleitet, aber keine Antwort sichtbar, Rückroute, Zielsystem, NAT, SD-WAN und asymmetrisches Routing prüfen.
7. Erst danach ändern: Keine breite Allow-Regel oder globale Ausnahme erstellen, bevor das verantwortliche Modul und die tatsächliche Ursache feststehen.

Für allgemeines Regel-Matching und den Policy Tester gibt es die vertiefende Anleitung Sophos Firewall-Regel testen mit Log Viewer und Packet Capture.

Log Viewer und Packet Capture zusammen lesen

Log Viewer und Invalid traffic

Der Log Viewer öffnet sich oben rechts im WebAdmin. Er zeigt nicht nur Firewall-Entscheidungen, sondern auch Ereignisse der beteiligten Security-Module. Bei Web-Proxy-Traffic kann das Firewall-Modul beispielsweise Allowed und das Web-Modul gleichzeitig Blocked melden: Die Firewall-Regel lässt die Verbindung zum Proxy zu, während die Web Policy den Inhalt blockiert. Deshalb immer die Module desselben Testzeitpunkts korrelieren. Filter, Detailed view, Sessionzeitpunkt und Log occurrence erklärt Sophos Firewall Log Viewer richtig nutzen.

Für Firewall-Traffic müssen zwei Voraussetzungen getrennt geprüft werden:

• In der betreffenden Regel ist Log firewall traffic aktiviert. SSL/TLS-Regeln besitzen dafür die eigene Option Log connections.
• Unter System services > Log settings ist das benötigte Ausgabeziel für den Log Viewer unter Local reporting, Sophos Fusion (ehemals Sophos Central) oder Syslog aktiviert.

Firewall-Sessions erscheinen typischerweise, wenn die Firewall beim Schliessen ein Destroy-Event erhält. Bricht eine Verbindung ohne dieses Ereignis ab, kann der erwartete Eintrag fehlen. Für längere Aufbewahrung eignen sich Central Firewall Reporting oder Syslog an ein SIEM.

Invalid traffic bedeutet, dass Conntrack ein Paket keiner aktuellen Verbindung zuordnen kann. Eine abgelaufene Session oder zusätzliche TCP-RST- und FIN-Pakete können solche Ereignisse erzeugen und sind nicht automatisch ein Fehler. Treten gleichzeitig Verbindungsprobleme auf, beide Richtungen erfassen und mögliche Ursachen wie eine fehlende Rückroute, einen asymmetrischen Pfad oder einen HA-Rollenwechsel prüfen. Eine längere Conntrack-Zeit reduziert unter Umständen nur Logeinträge; sie behebt die Ursache nicht.

Lautet der Drop-Grund konkret Invalid TCP reserved bit, kann Accurate ECN statt einer Firewall-Regel die Ursache sein. Der Artikel Invalid TCP reserved bit durch Accurate ECN beheben erklärt den Nachweis und die Sicherheitswirkung des globalen CLI-Workarounds.

Status, Rule ID, NAT ID und Reason

Packet Capture zeigt Pakete, die ein Interface passieren, und ergänzt die Verarbeitung durch Firewall, NAT und Security-Module. Die aktuelle SFOS-22-Hilfe definiert diese Statuswerte:

• Incoming: Das Paket kommt an einem Interface an. Das beweist noch nicht, dass es weitergeleitet wird.
• Forwarded: Die Firewall leitet das Paket an ein Ausgangsinterface weiter. Fehlt die Antwort, liegt der nächste Fokus auf Zielsystem und Rückweg.
• Consumed: Das Paket ist für die Firewall selbst bestimmt, beispielsweise für WebAdmin, SSH, DNS oder ein VPN-Portal.
• Generated: Die Firewall erzeugt das Paket selbst, etwa als Antwort oder Systemtraffic.
• Violation: Eine Policy-Verletzung führt zum Drop. Rule ID, Reason und zuständiges Modul zeigen den nächsten Prüfpunkt.

Wichtig sind ausserdem Rule ID, NAT ID, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID und Username. Ein unerwarteter Wert kann bedeuten, dass eine allgemeinere Regel weiter oben greift, NAT die sichtbaren Adressen verändert oder der Benutzer nicht erkannt wurde.

Reason ist ein Wegweiser, kein vollständiger Root-Cause-Bericht. Werte wie Firewall, LOCAL_ACL, INVALID_TRAFFIC, APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION oder VIRTUAL_HOST können je nach Version zum zuständigen Modul führen. Zuerst Status und IDs lesen, dann den passenden Log-Viewer-Bereich öffnen. Die Bedienung und Filterung erklärt Sophos Firewall Packet Capture.

Capture-Filter gezielt setzen

Unter Diagnostics > Packet capture > Configure begrenzt Enter BPF string die Aufzeichnung; Number of bytes to capture (per packet) bestimmt die erfasste Paketlänge. Wrap capture buffer once full überschreibt bei vollem Puffer die ältesten Daten, statt die Aufzeichnung zu stoppen. Nach Save lässt sich die Liste über Display filter nach Interface name, Ethernet type, Packet type, Source IP/port, Destination IP/port, Reason, Status, Rule ID, User oder Connection ID eingrenzen. Ein enger BPF-Filter schont den 2048-KB-Puffer und erfasst weniger sensible Daten.

Firewall ID 0 und fehlende Drop-Logs

Wenn keine explizite Firewall-Regel passt, greift die eingebaute Drop all-Regel mit Policy beziehungsweise Firewall ID 0; sie erzeugt keinen normalen Firewall-Traffic-Logeintrag. Für nachvollziehbare Drops erstellt man unter Rules and policies > Firewall rules > Add firewall rule > New firewall rule eine Regel an letzter Position. Relevant sind Rule name, Action: Drop, Source zones and networks, Destination zones and networks, Services und Log firewall traffic. Für einen einzelnen Test werden Zonen, Netze und Service eng begrenzt. Um die eingebaute Schlussregel vollständig abzubilden, nennt Sophos eine any-any-Drop-Regel als Workaround. Vorher Logvolumen und vorhandene Schlussregeln prüfen.

Bei SFOS 22.0.1 MR1 Build 490 tritt NC-178387 auf: Default-Drops mit ID 0 fehlen in Dropped Packet Capture und drppkt; Packet Capture zeigt nur Incoming ohne Violation Firewall. Der Traffic wird trotzdem verworfen. Für NC-178387 ist weiterhin keine bestätigte Fix-Version bekannt; aus der Veröffentlichung von MR2 allein darf kein Fix abgeleitet werden. Vor der Wahl eines anderen Builds gehört diese Prüfung in den Firmware-Update-Plan.

1. Regelreihenfolge und Policy Test prüfen.
2. Ergebnis mit Packet Capture abgleichen.
3. Bei Bedarf die geloggte Schlussregel erstellen und die neue Rule ID bestätigen.
4. Wird sie nicht dauerhaft benötigt, deaktivieren oder löschen und erneut testen: ID 0 muss weiterhin verwerfen; nur der zusätzliche Logeintrag entfällt.

Der Policy tester unter Diagnostics > Tools im Bereich Pop-out tools bildet keine SD-WAN-Routen ab. NC-177587 betraf SFOS 22.0 GA Build 411 und wurde in MR1 Build 490 behoben; bei abweichenden Builds muss der aktuelle Status von NC-177587 im Rahmen der Firmware-Update-Planung geprüft werden. Policy Test und Policy Route Test konnten falsche Ergebnisse anzeigen. Produktive Logs und Packet Capture bleiben für den tatsächlichen Flow massgeblich.

Ursache nach Befund eingrenzen

Regel, NAT und Rückweg

Passt die Rule ID nicht zur erwarteten Regel, Source- und Destination-Zone, Netzobjekte, Service, Protokoll, Benutzer, Zeitplan und Regelreihenfolge prüfen. Bei DNAT ist entscheidend, ob der Test gegen die öffentliche Adresse erfolgt und welche NAT ID tatsächlich greift. Grundlagen stehen unter Firewall-Regeln verstehen und Server per DNAT veröffentlichen.

Zeigt Packet Capture Forwarded, aber keine Antwort, ist eine weitere Allow-Regel selten die Lösung. Häufig fehlen SNAT/MASQ oder Rückroute, eine verlinkte NAT-Regel ist deaktiviert, das Zielsystem blockiert lokal oder SD-WAN sendet die Antwort über einen anderen Pfad. Hin- und Rückrichtung müssen dieselbe zustandsbehaftete Firewall passieren.

Session, asymmetrisches Routing und HA

Meldungen wie Could not associate packet to any connection bedeuten, dass kein passender Conntrack-Eintrag gefunden wurde. Mögliche Ursachen sind eine abgelaufene Session, unerwartete TCP-Flags, ein asymmetrischer Rückweg oder ein Datenstrom, den die Firewall nur in einer Richtung sieht. Nach einem HA-Rollenwechsel kann ausserdem relevant sein, auf welchem Knoten die Verbindung aufgebaut wurde.

Ein einzelnes RST- oder FIN-Ereignis ohne Benutzerproblem braucht nicht sofort eine Änderung. Wiederholbare Abbrüche werden dagegen mit identischem Filter in beide Richtungen geprüft; danach folgen Routing, SD-WAN, VPN-Pfade und HA-Status.

Consumed und lokale Firewall-Dienste

Consumed ist kein normaler Durchgangs-Drop. Das Ziel ist die Firewall selbst, beispielsweise WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN oder SNMP. Für diese Verbindungen sind meist Administration > Device access und Local service ACL zuständig, nicht eine normale Firewall-Regel. Die sichere Konfiguration zeigt Sophos Firewall Device Access absichern.

Security-Module, VPN und MTU

Eine Firewall-Regel kann Traffic zulassen, bevor ein nachgelagertes Modul blockiert. Deshalb bei passenden IDs oder Reasons auch Web Policy, SSL/TLS inspection, Application Control, IPS, Active Threat Response und WAF prüfen. Bei einem IPS-Treffer Signatur und Regelkontext bewerten, bevor eine Ausnahme erstellt wird; den Ablauf beschreibt Sophos Firewall IPS sicher testen.

Bei Web- und TLS-Problemen kann QUIC über UDP 443 die erwartete Verarbeitung verändern. Der Artikel QUIC und HTTP/3 blockieren zeigt die passende Kontrolle.

Bei VPN, PPPoE, SD-WAN oder verschachtelten Tunneln verursachen MTU, MSS und Fragmentierung eher Hänger oder Teilabbrüche als einen klaren Drop. Dafür gibt es die Anleitungen zu MTU und MSS und zum IPsec VPN Troubleshooting.

Connection List für bestehende Sessions

Unter Diagnostics > Connection list zeigt die Liste aktive Verbindungen. Display filter grenzt sie nach In interface, Out interface, User, Network protocol, Source IP, Destination IP, Packet type, Source port, Destination port und Rule ID ein. Spalten wie NAT ID, Protocol, Application name, Connection status, Connection ID, Gateway ID und die Policy-IDs helfen bei der Zuordnung. Ein Klick auf Connection ID zeigt bei Proxy-, FTP-, SIP- und ähnlichen Verbindungen zugehörige Sessions, sofern vorhanden.

Eine aktive Session mit erwarteter Rule ID und NAT ID bestätigt die Werte des aktuellen Flows. Ihr Fehlen beweist keinen Drop: Die Liste ist nur eine Momentaufnahme; verworfene oder beendete Verbindungen können fehlen. Deshalb während des Tests prüfen und mit Log Viewer und Packet Capture korrelieren.

Wenn die Standardprüfung nicht reicht

Kein Eintrag im Log Viewer oder Packet Capture

Fehlt ein Logeintrag, zuerst Regel-Logging, Log settings, Zeitfilter und zuständiges Modul prüfen. Fehlt auch im Packet Capture jedes Paket, vor einer Netzwerkdiagnose kontrollieren:

• Packet Capture ist wirklich aktiv und der Test wurde erst danach ausgeführt.
• Der Filter enthält die richtigen Adressen, Ports, Richtung und das richtige Interface; testweise etwas erweitern.
• Der 2048-KB-Puffer ist nicht voll. Ohne Wrap capture buffer once full stoppt die Aufzeichnung bei vollem Puffer und muss nach Clear neu gestartet werden; mit aktivierter Option werden stattdessen die ältesten Daten überschrieben.
• Unter System services > Services laufen Packet capture and Live connections; bei einem Startproblem diesen Dienst kontrolliert neu starten.

Erst wenn ein reproduzierbarer Test mit funktionsfähigem Capture keinen Eingang zeigt, liegt der Fokus vor der Firewall: Client, VLAN, Switch, Gateway, vorgeschalteter Router oder falsches Testziel.

tcpdump, Drop Capture und Logarchive

Für längere Mitschnitte, PCAP-Dateien oder genaue BPF-Filter per SSH anmelden und Option 4: Device Console wählen. Ein enger Beispielmitschnitt für zwei Hosts und HTTPS lautet:

tcpdump 'host 192.0.2.10 and host 198.51.100.20 and port 443'

Für Pakete, die Firewall-Regeln verwerfen, kann derselbe Filter mit drop-packet-capture verwendet werden:

drop-packet-capture 'host 192.0.2.10 and host 198.51.100.20 and port 443'

drop-packet-capture hilft nicht bei Application-Layer-Problemen. Die Beispiele entsprechen der dokumentierten Device-Console-Syntax von SFOS 22; sie wurden für diesen Artikel nicht auf einer Firewall ausgeführt. Für eine PCAP-Datei unterstützt tcpdump die Option filedump; die Datei liegt temporär unter /tmp. Capture so kurz und eng wie möglich halten, weil Pakete sensible Inhalte enthalten können, und die Datei nach der Analyse löschen. Weitere Beispiele stehen unter tcpdump auf der Sophos Firewall.

Braucht der Support zusätzlich Dienstlogs, zuerst das zuständige Log bestimmen und nur den erforderlichen Zeitraum sichern. Dabei helfen Sophos Firewall Services und Logs sowie Logs für Support und Analyse sichern.

Sicher beheben und dokumentieren

Eine Ausnahme ist erst sinnvoll, wenn Modul, legitimer Zweck und engster Geltungsbereich feststehen. Keine globale TLS-Ausnahme, Any-Allow-Regel oder ganze Netze freigeben, nur weil der Dienst danach funktioniert. Besser sind konkrete Hosts, Dienste und Benutzer sowie ein Review- oder Ablaufdatum.

Vor dem Abschluss dokumentieren:

• Source, Destination, Port, Protokoll, Uhrzeit und Benutzer.
• Erwartete und tatsächlich sichtbare Rule ID sowie NAT ID.
• Status, Reason und beteiligtes Security-Modul.
• Hin- und Rückrichtung oder der Punkt, an dem der Flow endet.
• Änderung, Owner, Ticket und Review-Termin; auch festhalten, wenn bewusst nichts geändert wurde.

Danach denselben Test wiederholen. Die erlaubte Verbindung muss funktionieren, und eine nicht erlaubte Vergleichsquelle muss weiterhin blockiert bleiben. So wird aus einer schnellen Fehlerbehebung keine dauerhafte Sicherheitslücke.

Häufige Fragen