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.

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 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.

Firewall ID 0 und fehlende Drop-Logs

Wenn keine explizite Firewall-Regel passt, greift am Ende der Regelbasis die eingebaute Drop all-Regel mit Policy beziehungsweise Firewall ID 0. Sie erzeugt keinen normalen Firewall-Traffic-Logeintrag. Sollen diese Drops in Log Viewer, Central Reporting oder Syslog nachvollziehbar sein, erstellt man am Ende der Regelbasis eine eigene Regel mit Action: Drop und aktiviertem Log firewall traffic.

Dabei die benötigten Source- und Destination-Zonen einzeln auswählen und für die Zonen nicht pauschal Any verwenden. So bleiben lokale Dienste korrekt erreichbar. Erzeugt die Schlussregel viel legitimen Traffic, fehlt weiter oben wahrscheinlich eine passende Allow-Regel oder ein Netz wurde falsch eingeordnet.

Für SFOS 22.0.1 MR1 Build 490 dokumentiert Sophos zusätzlich das Known Issue NC-178387: Default-Drops mit ID 0 fehlen im Dropped Packet Capture und in drppkt; im normalen Packet Capture kann nur Incoming ohne zugehörigen Violation Firewall-Eintrag erscheinen. Der Traffic wird trotzdem verworfen. Sophos nennt in der Known-Issues-Liste keine eindeutig bestätigte Fix-Version, deshalb darf dieses Verhalten ausserhalb des genannten Builds nicht vorausgesetzt werden.

Bei einem vermuteten Default-Drop:

1. Regelreihenfolge und Policy Test prüfen.
2. Ergebnis mit einem echten Packet Capture abgleichen.
3. Falls Logging benötigt wird, eine gezielt zonierte Schlussregel mit eigener Rule ID erstellen.
4. Test wiederholen und die neue Rule ID im Log beziehungsweise Capture bestätigen.

Der Policy Tester unter Diagnostics > Tools bildet keine SD-WAN-Routen ab und ist daher nie der alleinige Beweis. Auf SFOS 22.0 GA konnte ausserdem NC-177587 falsche Regelresultate anzeigen; produktive Logs und Packet Capture bleiben 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.

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. Bei vollem Puffer stoppt die Aufzeichnung automatisch und muss nach Clear neu gestartet werden.
• 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. 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