Sophos Firewall Packet Capture im WebAdmin verwenden

Unter Diagnostics > Packet capture lässt sich ein einzelner Netzwerkfluss direkt im WebAdmin verfolgen. Man setzt einen engen BPF-Filter, startet die Aufzeichnung, reproduziert das Problem einmal und prüft danach Interfaces, Rule ID, NAT ID, Status und Reason.

Packet Capture zeigt den tatsächlichen Paketfluss. Welche Policy entschieden hat, kontrolliert man zusätzlich im Log Viewer. Für längere Aufzeichnungen oder eine .pcap-Datei braucht man dagegen tcpdump über SSH, da der WebAdmin-Capture nicht als PCAP heruntergeladen werden kann.

Ist die Verbindung bereits aufgebaut und soll zuerst nur die aktive Session mit Benutzer, Interfaces, Rule ID, NAT ID oder Gateway gefunden werden, beginnt man mit Live Connections und Connection List. Packet Capture folgt, wenn der tatsächliche Hin- und Rückweg bewiesen werden muss.

Packet Capture in sechs Schritten

1. Source IP, Ziel, Protokoll, Port und Testzeit notieren. Beispiel: Client 172.16.10.25 zu 93.184.216.34 über TCP 443.
2. Diagnostics > Packet capture öffnen und Configure anklicken.
3. Einen BPF-String setzen, zum Beispiel host 172.16.10.25 and port 443, und speichern.
4. Packet Capture auf Trace On stellen. Unter SFOS 22 erscheinen die Paketdetails in einem neuen Browserfenster.
5. Genau einen Test reproduzieren und die Aufzeichnung danach mit Trace Off stoppen.
6. Den Ablauf von unten nach oben lesen und auf In/Out interface, Rule ID, NAT ID, Status, Reason sowie Antwortpakete achten.

Wird der BPF-String während einer laufenden Aufzeichnung geändert, Packet Capture zuerst auf Trace Off und danach wieder auf Trace On stellen, damit der neue Filter angewendet wird.

⚠️ Ein breiter Dauermitschnitt macht die Auswertung unübersichtlich und erfasst unnötig viele Betriebsdaten. Filter eng setzen, Test kurz halten und Packet Capture danach ausschalten.

Capture Filter gezielt setzen

Der Capture Filter bestimmt vor der Aufzeichnung, welche Pakete in den 2048-KB-Buffer gelangen. Der Display Filter schränkt nur die bereits erfasste Anzeige ein. Ein Interface wählt man deshalb nicht im Capture Filter, sondern später im Display Filter aus.

Für einen HTTPS-Test sollten mindestens Source, Ziel und Port bekannt sein. Wenn das Ziel wegen DNS, CDN oder NAT noch unklar ist, beginnt man besser nur mit der Source IP und grenzt den sichtbaren Flow danach weiter ein.

Vor dem Start sollten diese Punkte feststehen:

• Source IP und aktuelle Destination IP
• Protokoll sowie Source- und Destination-Port, soweit relevant
• erwartetes Eingangs- und Ausgangsinterface beziehungsweise die Zonen
• erwartete Firewall Rule und NAT Rule
• erwartetes Ergebnis, etwa erlaubt, blockiert, DNAT, SNAT oder VPN
• genaue Testzeit und eine einzelne reproduzierbare Aktion

BPF-Beispiele

• Host: host 10.10.10.1
• Source IP: src host 10.10.10.1
• Destination IP: dst host 10.10.10.1
• Netz: net 10.10.10.0
• Source-Netz: src net 10.10.10.0
• Destination-Netz: dst net 10.10.10.0
• Port: port 443
• Source-Port: src port 443
• Zielport: dst port 443
• Protokoll: proto TCP, proto UDP oder proto ICMP

Ein enger Webtest kann so aussehen:

host 172.16.10.25 and host 93.184.216.34 and port 443

Für einen Ping-Test reicht meistens:

host 172.16.10.25 and proto ICMP

Sophos dokumentiert diese BPF-Grundformen. Nicht jede beliebige tcpdump-Expression ist damit automatisch für den WebAdmin garantiert.

Zwei weitere dokumentierte Formen helfen bei gezielten Varianten:

• Mehrere Ports mit OR: port 80 or port 443 erfasst Pakete mit einem der beiden Ports, etwa für einen kurzen HTTP-/HTTPS-Vergleich. Ohne Host-Bedingung gilt der Filter für alle Hosts; deshalb nur kurz aufzeichnen.
• Einen Port für einen Host ausschliessen: host 172.16.10.25 and port not 22 erfasst diesen Host, lässt aber Pakete mit Source- oder Destination-Port 22 aus. Das kann den SSH-Verwaltungsverkehr ausblenden, erfasst jedoch weiterhin alle anderen Ports dieses Hosts.

Die Operatoren or, and und port not gehören zur Syntax. IP-Adressen und Portnummern sind dagegen Beispielwerte: Man ersetzt die Host-IP durch den eigenen Testhost und die Ports durch die tatsächlich untersuchten Dienste. Auch das bestehende Webtest-Ziel 93.184.216.34 ist kein bestätigter Testendpunkt und muss durch die aktuelle Ziel-IP ersetzt werden. Nach einem kurzen Test prüfen, ob die gewünschten Pakete sichtbar sind und ausgeschlossene Ports fehlen; der Filter ändert keine Firewall-Regeln.

Bei NAT ist die Blickrichtung wichtig: Ein Filter auf die interne Client-IP kann den WAN-seitigen Eintrag nach MASQ ausblenden. Fehlen Pakete, zuerst nur auf Source, Destination oder Port filtern und prüfen, ob Hin- und Rückrichtung sichtbar bleiben.

Buffer und Aufzeichnungsoptionen

• Number of bytes to capture (per packet) legt fest, wie viele Bytes pro Paket gespeichert werden. Für einen ersten Test reichen oft Headerdaten.
• Ohne Wrap capture buffer once full stoppt die Aufzeichnung bei 2048 KB automatisch. Mit Wrap werden die ältesten Daten überschrieben.
• Clear leert den Buffer vor einem neuen Test.
• Buffer used zeigt die aktuelle Belegung von 0 bis 2048 KB, nicht die feste Gesamtkapazität. So erkennt man, wie nahe die Aufzeichnung am Buffer-Limit liegt.
• Die Details der erfassten Pakete lassen sich aktualisieren. Für den aktuellen Stand die Paketdetails aktualisieren und Buffer used ablesen; das ist nicht dasselbe wie das Leeren mit Clear.
• Die Aufzeichnung läuft weiter, wenn man im WebAdmin auf eine andere Seite wechselt. Deshalb nach dem Test bewusst auf Trace Off stellen.

Ergebnisse richtig lesen

Ein Paketfluss erscheint mehrfach, weil die Firewall Ingress und Egress an den Interfaces erfasst. Ein Ping-Roundtrip besteht typischerweise aus vier Zeilen: Request kommt am LAN an, verlässt das WAN, Reply kommt am WAN an und verlässt das LAN. Die neuesten Einträge stehen oben; für den zeitlichen Ablauf liest man die Liste von unten nach oben.

Die wichtigsten Felder

• In interface / Out interface: Wo das Paket ankommt und über welches Interface es weitergeht.
• Source IP / Destination IP / Ports: Welcher Flow gerade betrachtet wird.
• Rule ID: Welche Firewall-Regel den Traffic verarbeitet.
• NAT ID: Welche NAT-Regel beteiligt ist.
• Status: Was die Firewall mit diesem Paketschritt macht.
• Reason: Warum ein Paket verworfen wird.

Zeit, Ethernet Type und Packet Type helfen, einzelne Zeilen zeitlich und nach Protokoll einzuordnen. Die Paketliste enthält ausserdem Connection ID, Connection status, Gateway ID, Username sowie die IDs angewendeter Web-, Application-, IPS-, Remote-Access- und Bandwidth-Policies. Für das ausgewählte Paket zeigt die Detailansicht zusätzlich Header sowie Hex- und ASCII-Daten.

Für eine genauere Zuordnung sind die zusätzlichen Metadaten getrennt zu lesen:

• Connection flags: Systemflags der Verbindung; nicht mit dem Paketfeld Status verwechseln.
• User group: Gruppenzugehörigkeit des Benutzers, nicht dessen Username.
• Master connection ID: ID der primären Verbindung zur aktuellen Verbindung; Connection ID bezeichnet dagegen die aktuelle Verbindung selbst.
• Application ID / Application category ID: Kennung der Anwendung beziehungsweise ihrer Kategorie.
• Application filter ID: Kennung der auf den Verbindungsverkehr angewendeten Application-Filter-Policy, nicht die Kennung der Anwendung.
• Web category ID / Web filter ID: Webkategorie beziehungsweise angewendete Webfilter-Policy. Kategorie- und Policy-ID sind unterschiedliche Zuordnungen.

Status richtig einordnen

• Incoming: Das Paket wurde auf einem Interface empfangen; eine spätere Entscheidung ist damit noch nicht bewiesen.
• Forwarded: Die Firewall hat das Paket über ein Ausgangsinterface weitergeleitet.
• Consumed: Das Paket ist für die Firewall selbst bestimmt, etwa für WebAdmin, VPN Portal, SSH, DNS oder einen VPN-Dienst.
• Generated: Die Firewall hat das Paket selbst erzeugt, beispielsweise als Antwort oder durch einen Systemdienst.
• Violation: Die Firewall hat das Paket wegen einer Policy-Verletzung verworfen.

Bei Consumed sind häufig Administration > Device access, eine Local Service ACL oder der betroffene Firewall-Dienst entscheidend. Die passende Konfiguration erklärt Sophos Firewall Device Access absichern.

Rule ID, NAT ID und Reason zusammen prüfen

Eine unerwartete Rule ID ist kein Beweis für eine defekte Regel. Zuerst Regelreihenfolge, Zonen und Matching im Log Viewer kontrollieren. Der vollständige Ablauf steht in Sophos Firewall-Regel sauber testen.

Bei NAT kann derselbe Flow vor und nach der Übersetzung mit anderen Adressen erscheinen. Entscheidend sind erwartete NAT ID, In/Out interface und Antwortpakete. Die Übersetzungslogik erklärt NAT auf Sophos Firewall verstehen.

Zeigt Reason beispielsweise LOCAL_ACL, IPS, APPLICATION_FILTER, USER_IDENTITY oder IP_SPOOF, sollte das genannte Modul im Log Viewer geprüft werden. Eine ausführliche Einordnung steht in Sophos Firewall verworfene Pakete analysieren.

Für den Abgleich mit dem Log Viewer:

1. Log Viewer und Packet Capture parallel öffnen.
2. Capture Filter setzen und genau einen Test reproduzieren.
3. Im Packet Capture Interfaces, Antwortpakete, Rule ID und NAT ID prüfen.
4. Im passenden Log-Viewer-Modul kontrollieren, welche Regel oder Security Policy entschieden hat.
5. Erst danach gezielt Regel, NAT, Routing oder das betroffene Security-Modul untersuchen.

Unter SFOS 22 bietet der Log Viewer bei eingeschaltetem Packet Capture zusätzlich Open PCAP, um Paketinformationen zu öffnen. Ein fehlender Firewall-Logeintrag während eines laufenden Tests beweist noch keinen Capture-Fehler: Firewall-Sessions werden regulär erst beim Connection-Destroy-Ereignis protokolliert. Für die unmittelbare Weganalyse bleibt deshalb die Paketliste massgeblich.

Display Filter verwenden

Der Display Filter hilft bei einer bereits gefüllten Paketliste. Er kann unter anderem nach Interface, IPv4/IPv6/ARP, Packet type, Source/Destination IP und Port, Reason, Status, Rule ID, User oder Connection ID filtern. Allowed steht dort zusätzlich als Filterwert für erlaubte Pakete zur Auswahl; die Paketzeilen selbst zeigen die Verarbeitungsschritte wie Incoming oder Forwarded.

Unter User wählt man einen Benutzer aus der Liste der bereits vorhandenen Benutzer. Der Dropdown Reason bietet neben den oben erläuterten Beispielen weitere dokumentierte Werte: DOS_ATTACK, INVALID_FRAGMENTED_TRAFFIC, ICMP_REDIRECT, SOURCE_ROUTED_PACKET, FRAGMENTED_TRAFFIC, MAC_FILTER, IPMAC_FILTER, NEIGHBOR_POISONING und ICMP ERROR MESSAGE. Die Schreibweise einschliesslich Leerzeichen bleibt unverändert. Man wählt den zum beobachteten Eintrag passenden Wert, um die Anzeige einzugrenzen; der Name allein ersetzt keine Ursachenprüfung im zuständigen Log-Viewer-Modul.

Bei ARP- oder NDP-Problemen zeigt ARP- und NDP-Neighbor-Cache prüfen, wie man die Capture-Anzeige mit dem lokalen Neighbor-Cache und statischen Bindungen abgleicht.

Mit Save wird der Filter angewendet, mit Clear wird er zurückgesetzt. Für VPN-Traffic setzt man den Capture Filter beispielsweise auf Host oder Netz. Falls das erwartete Tunnel- oder XFRM-Interface im Display Filter angeboten wird, lässt sich die Anzeige darauf eingrenzen. Andernfalls liest man In/Out interface direkt in den Paketzeilen.

Schnelle Fehleranalyse

Keine Pakete sichtbar: Capture- und Display-Filter prüfen. Bei FQDNs und CDNs die aktuelle Ziel-IP kontrollieren; bei NAT zunächst nur auf die Source IP filtern. Bleibt die Liste leer, Client-Gateway, VLAN, Switch-Port und vorgeschaltete Geräte prüfen.

Client erreicht das Internet nicht: Auf die Client-IP und beispielsweise TCP 443 filtern. Kommt nichts an, liegt die Ursache vor der Firewall. Kommt der Request an, aber nicht weiter, Firewall-Regel, NAT und Routing prüfen.

Nur Incoming sichtbar: Nach Forwarded, Consumed oder Violation suchen und sicherstellen, dass der Filter Folgeschritte nicht ausblendet. Unter SFOS 22.0.1 MR1 Build 490 können Default-Drops mit Firewall ID 0 wegen Known Issue NC-178387 ohne Violation Firewall-Zeile erscheinen. Sophos plant laut Known-Issues-Eintrag eine Korrektur im nächsten Maintenance Release; eine konkrete bestätigte Fix-Version oder ein Fix-Build wird dort nicht genannt. Aus der Veröffentlichung von MR2 allein darf deshalb kein Fix abgeleitet werden. Solange die Korrektur für den eingesetzten Build nicht bestätigt ist, mit dem Policy tester gegenprüfen oder für den betroffenen Flow eine explizite protokollierte Drop-Regel am Ende der Firewall-Regelliste verwenden. Source- und Destination-Zonen dabei gezielt setzen; Details stehen in Sophos Firewall verworfene Pakete analysieren.

Forwarded, aber keine Antwort: Rückroute, NAT, Zielsystem, lokale Firewall des Ziels und Gegenstelle prüfen. Forwarded beweist nur, dass die Sophos Firewall das Paket weitergegeben hat.

Unerwartete Rule ID oder NAT ID: IDs mit Log Viewer und Regelposition abgleichen. Nicht mehrere Regeln gleichzeitig ändern; für ein Matching-Problem hilft Sophos Firewall-Regel greift nicht.

DNAT funktioniert nicht: Prüfen, ob der Request am WAN ankommt, mit welcher NAT ID er verarbeitet wird und ob er zum internen Server weitergeht. Wenn am WAN nichts erscheint, liegt die Ursache häufig vor der Firewall. Den vollständigen Aufbau zeigt Server per DNAT veröffentlichen.

VPN-Traffic fehlt: Mit Host, Netz oder Protokoll erfassen. Das erwartete Tunnel- oder XFRM-Interface im Display Filter wählen, sofern es dort angeboten wird. Sonst die In/Out-interface-Werte der Paketzeilen prüfen. Für die weitere Analyse passt Sophos Firewall IPsec Troubleshooting.

Webfilter blockiert unerwartet: Packet Capture zeigt den Paketfluss, aber nicht die vollständige Web-, Application-Control- oder SSL/TLS-Entscheidung. Diese im passenden Log-Viewer-Modul gegenprüfen.

Kleine Tests funktionieren, grosse Transfers hängen: Im WebAdmin auf fehlende Antworten und Paketgrössen achten. Retransmits lassen sich belastbar über eine PCAP-Datei in Wireshark untersuchen. Zusätzlich MTU und MSS prüfen.

Packet Capture startet nicht: Zuerst Buffer leeren und das neue Browserfenster prüfen. Bleibt der Fehler bestehen, unter System services > Services den Dienst Packet capture and Live connections neu starten. Der Neustart unterbricht vorübergehend auch die Live-Connections-Anzeige.

Datenschutz und Wechsel zu tcpdump

Capture-Daten können interne IP-Adressen, Hostnamen, Benutzernamen, Kommunikationsbeziehungen und bei unverschlüsselten Protokollen auch Nutzdaten enthalten. Vor der Weitergabe Empfänger, Umfang und Aufbewahrung prüfen; oft reichen wenige relevante Zeilen statt des gesamten Mitschnitts.

Für längere Aufzeichnungen, ein bestimmtes Interface, feste Paketanzahl, Snap Length oder eine .pcap-Datei verwendet man tcpdump auf der Sophos Firewall. Die Datei danach sicher übertragen und von der Firewall entfernen.