Zum Inhalt springen
Avanet

Sophos Firewall Packet Capture im WebAdmin verwenden

Packet Capture ist eines der wichtigsten Troubleshooting-Werkzeuge im WebAdmin der Sophos Firewall. Es zeigt, ob Pakete an einem Interface ankommen, ob sie weitergeleitet werden, welche Regel oder NAT-ID im Spiel ist und ob ein Paket verworfen wird.

Der Log Viewer zeigt die Entscheidung der Firewall. Packet Capture zeigt den Paketfluss. Beides zusammen ist oft der schnellste Weg zur Ursache.

Wichtig ist die Einordnung: Dieser Artikel beschreibt die WebAdmin-Version von Packet Capture. Für einen ersten Check ist sie ideal, weil man direkt im Browser sieht, ob Pakete ankommen, weitergeleitet oder verworfen werden. Für längere Mitschnitte, sehr genaue Filter, PCAP-Export oder Supportfälle ist ein tcpdump über SSH oft besser geeignet.

Wann Packet Capture sinnvoll ist

Packet Capture hilft besonders bei Fragen wie:

  • Kommt der Traffic überhaupt bei der Firewall an?
  • Geht der Traffic auf dem erwarteten Interface wieder raus?
  • Greift eine Firewall Rule?
  • Greift eine NAT Rule?
  • Wird ein Paket durch Policy, IPS oder Routing verworfen?
  • Kommt eine Antwort vom Zielsystem zurück?
  • Wird ein anderer Port oder ein anderes Protokoll verwendet als gedacht?

Wenn im Log Viewer gar nichts sichtbar ist, ist Packet Capture oft der nächste Schritt. Dann sieht man, ob das Problem vor der Firewall liegt oder ob die Firewall den Traffic verarbeitet.

Menüpfad

Man findet das Tool unter:

Diagnostics > Packet capture

Packet Capture öffnet sich direkt im WebAdmin. Je nach SFOS-Version und Browserdarstellung wirkt es wie ein eigenes Diagnosefenster innerhalb der WebAdmin-Ansicht.

Log Viewer oder Packet Capture?

Der Log Viewer und Packet Capture beantworten unterschiedliche Fragen.

ToolZeigt vor allem
Log ViewerWelche Firewall Regel, Web Policy, Application Control, IPS oder SSL/TLS inspection entschieden hat
Packet CaptureOb einzelne Pakete ankommen, weitergeleitet, konsumiert, erzeugt oder verworfen werden

Ein gutes Beispiel ist ein Ping. Im Log Viewer sieht man häufig nur einen Eintrag oder eine zusammengefasste Entscheidung zur Verbindung. Im Packet Capture sieht man dagegen die einzelnen ICMP-Pakete: Echo Request hin zum Ziel und Echo Reply zurück. Windows sendet mit ping standardmässig vier ICMP Echo Requests. Im Packet Capture erwartet man deshalb mehrere Hin- und Rückpakete. Wenn nur die Requests sichtbar sind, aber keine Replies zurückkommen, ist das ein anderes Problem als wenn gar kein Request bei der Firewall ankommt.

Für die Praxis bedeutet das:

  • Log Viewer beantwortet: Welche Regel oder welches Modul hat entschieden?
  • Packet Capture beantwortet: Sind die Pakete wirklich angekommen und welchen Weg nehmen sie?
  • Bei Routing-, NAT-, VLAN-, Gateway- oder Rückwegproblemen ist Packet Capture oft aussagekräftiger.
  • Bei Webfilter-, Application Control-, IPS- oder SSL/TLS inspection-Entscheidungen braucht man zusätzlich den Log Viewer.

Vor dem Start sauber eingrenzen

Packet Capture sollte nicht ungefiltert gestartet werden. In produktiven Netzen entstehen sonst sehr viele Daten, und die Ausgabe wird unübersichtlich.

Vorab sollte man notieren:

  • Source IP
  • Destination IP oder FQDN
  • Protokoll
  • Source Port, falls relevant
  • Destination Port
  • Interface oder Zone
  • Uhrzeit des Tests
  • betroffene Anwendung

Für einen Webtest könnte die Eingrenzung zum Beispiel so aussehen:

FeldBeispiel
Source IP172.16.10.25
Destination93.184.216.34
ProtocolTCP
Destination Port443
Erwartete RichtungLAN nach WAN

Capture Filter konfigurieren

Über Configure setzt man einen möglichst engen Filter.

Typische Filter:

  • Source IP des Clients
  • Destination IP des Servers
  • Destination Port
  • Protokoll TCP, UDP oder ICMP
  • Interface

Wenn man den Zielserver nicht kennt, kann man zuerst nur nach der Source IP filtern. Wenn danach zu viele Pakete sichtbar sind, weiter einschränken.

Sophos Firewall verwendet dafür Berkeley Packet Filter Syntax, kurz BPF. Der Capture Filter entscheidet, welche Pakete überhaupt in den Capture-Buffer geschrieben werden. Er sollte deshalb möglichst vor dem Test sauber gesetzt werden.

Typische BPF-Beispiele:

ZielBPF-Beispiel
bestimmter Hosthost 10.10.10.1
bestimmte Source IPsrc host 10.10.10.1
bestimmte Destination IPdst host 10.10.10.1
bestimmtes Netznet 10.10.10.0
bestimmter Portport 443
bestimmter Zielportdst port 443
bestimmter Host und Porthost 10.10.10.1 and port 443
ICMP/Pingproto ICMP
TCPproto TCP
UDPproto UDP

Für einen sehr gezielten Webtest kann ein Filter zum Beispiel so aussehen:

host 172.16.10.25 and host 93.184.216.34 and port 443

Für einen Ping-Test reicht oft:

host 172.16.10.25 and proto ICMP

In der WebAdmin-Ansicht sieht man nach dem Speichern den aktiven BPF String oberhalb der Paketliste. Der erste Screenshot zeigt die Filterkonfiguration, der zweite Screenshot die Ergebnisliste mit aktivem Filter.

Sophos Firewall Packet Capture Configure capture filter mit BPF String für Host und Port 443
Sophos Firewall - Packet Capture Filter mit BPF String konfigurieren
Sophos Firewall Packet Capture Ergebnisliste mit aktivem BPF Filter und erfassten TCP Paketen
Sophos Firewall - Packet Capture mit aktivem BPF Filter und erfassten Paketen

⚠️ PCAP-Daten können IP-Adressen, Hostnamen, Protokolldetails und je nach Protokoll auch Nutzdaten enthalten. Captures sollten nur mit Personen oder Partnern geteilt werden, die diese Daten sehen dürfen.

Capture starten und reproduzieren

  1. Filter setzen.
  2. Packet Capture über den Schieberegler einschalten.
  3. Problem gezielt reproduzieren.
  4. Capture wieder stoppen.
  5. Ergebnisse analysieren.
  6. Capture leeren, wenn ein neuer Test gestartet wird.

Sophos Firewall zeigt den Status und den Buffer an:

AnzeigeBedeutung
Trace OnPacket Capture läuft
Trace OffPacket Capture ist ausgeschaltet
Buffer sizeGrösse des Capture-Buffers, in der Sophos-Dokumentation 2048 KB
Buffer usedaktuell verwendeter Buffer

Wenn der Buffer voll ist, stoppt die Erfassung automatisch. Danach muss man mit Clear leeren, bevor erneut sinnvoll aufgezeichnet wird. Deshalb ist ein enger Filter wichtig.

In den Filtereinstellungen kann man zusätzlich festlegen, wie viele Bytes pro Paket erfasst werden. Für viele erste Analysen reichen Header-Informationen. Wenn man mehr Nutzdaten benötigt, muss man mehr Bytes erfassen, sollte aber Datenschutz und Buffergrösse im Blick behalten.

Wichtige Spalten verstehen

Packet Capture zeigt viele Felder. Für die Praxis sind diese besonders wichtig:

FeldBedeutung
TimeZeitpunkt des Pakets
In interfaceInterface, auf dem das Paket reinkam
Out interfaceInterface, über das das Paket rausgeht
Source IPQuelladresse
Destination IPZieladresse
Packet typeProtokoll oder Pakettyp
Ports [src, dst]Quell- und Zielport
NAT IDpassende NAT-Regel
Rule IDpassende Firewall Regel
StatusPaketstatus
ReasonGrund für Drop oder Violation
Connection statusZustand der Verbindung
Gateway IDverwendetes Gateway
Usernameerkannter Benutzer
IPS policy IDangewendete IPS Policy
Application filter IDangewendete Application Control Policy

Diese Felder sind wertvoll, weil sie die Lücke zwischen „Regel sieht richtig aus“ und „Traffic läuft wirklich so“ schliessen.

Über Show additional properties oder die Detailansicht sieht man je nach Version weitere Informationen wie Connection ID, Web filter ID, Application ID, Web category ID, Gateway ID, Username oder weitere Policy-IDs. Diese Details helfen, wenn ein Paket nicht nur durch eine Firewall Regel, sondern zusätzlich durch Web, Application Control, IPS oder andere Module verarbeitet wird.

Status richtig interpretieren

StatusBedeutung
IncomingPaket wurde auf einem Interface empfangen
ForwardedPaket wurde weitergeleitet
ConsumedPaket ist für die Firewall selbst bestimmt
GeneratedPaket wurde von der Firewall erzeugt
ViolationPaket wurde wegen einer Policy-Verletzung verworfen

Wenn man nur Incoming sieht und kein Forwarded, bleibt das Paket wahrscheinlich auf der Firewall hängen. Dann sollte man Firewall Regel, NAT, Routing und Security Features prüfen.

Wenn Forwarded sichtbar ist, aber keine Antwort zurückkommt, liegt das Problem oft beim Zielsystem, Rückweg, NAT oder einer Gegenstelle.

Bei einem erfolgreichen Ping sieht man typischerweise Pakete in beide Richtungen. Wenn Windows vier Pings sendet, sieht man mehrere ICMP Echo Requests vom Client zum Ziel und mehrere Echo Replies zurück. Fehlen die Replies, prüft man Rückroute, Zielsystem, lokale Firewall des Zielsystems, NAT oder eine Gegenstelle. Fehlen schon die Requests, prüft man Client, Gateway, VLAN, Switch-Port oder ob der Traffic die Sophos Firewall überhaupt erreicht.

Display Filter verwenden

Der Capture Filter begrenzt, welche Pakete aufgezeichnet werden. Der Display filter filtert dagegen die bereits aufgezeichnete Ansicht. Das ist praktisch, wenn man den Capture absichtlich etwas breiter gestartet hat und danach nur bestimmte Pakete anzeigen möchte.

Im Display Filter kann man unter anderem nach diesen Feldern filtern:

  • Interface name
  • Ethernet type, zum Beispiel IPv4, IPv6 oder ARP
  • Packet type
  • Source IP und Source port
  • Destination IP und Destination port
  • Reason
  • Status
  • Rule ID
  • User
  • Connection ID

Für die Fehlersuche sind besonders Status, Reason, Rule ID, Source IP, Destination IP und Destination port hilfreich. Wenn sehr viele Pakete im Capture stehen, kann man damit schnell auf den relevanten Teil reduzieren, ohne den Test sofort neu starten zu müssen.

NAT im Packet Capture lesen

Bei NAT muss man beachten, dass ein Paket vor und nach NAT unterschiedlich aussieht. Packet Capture kann NAT ID, Rule ID und die veränderten Adressen sichtbar machen.

Bei NAT-Problemen sollte man prüfen:

  • Sieht man das Paket mit der Original-Adresse?
  • Sieht man das Paket nach der Übersetzung?
  • Wird die erwartete NAT ID angezeigt?
  • Geht das Paket über das erwartete Out interface?
  • Kommt eine Antwort zurück?

Für DNAT gilt zusätzlich: Die Firewall Regel verwendet die Zielzone nach NAT, aber die Ziel-IP vor NAT. Das sieht im ersten Moment ungewohnt aus.

Mehr dazu: NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.

Packet Capture und Log Viewer kombinieren

Der beste Ablauf ist:

  1. Log Viewer öffnen.
  2. Packet Capture mit engem Filter starten.
  3. Test reproduzieren.
  4. Im Packet Capture prüfen, ob Pakete ankommen und weitergehen.
  5. Im Log Viewer prüfen, welche Regel oder welches Modul entschieden hat.
  6. Bei Bedarf in die passende Logdatei wechseln.

Der Log Viewer zeigt zum Beispiel Firewall, Web, SSL/TLS inspection, IPS oder Application Control Events. Packet Capture zeigt dagegen den Paketfluss auf Interface-Ebene.

Gerade bei Ping oder einfachen TCP-Verbindungen ist die Kombination wichtig. Der Log Viewer kann nur zeigen, dass eine Verbindung erlaubt oder blockiert wurde. Packet Capture zeigt zusätzlich, ob die Antwortpakete zurückkommen, ob NAT greift, ob das richtige Out interface verwendet wird und ob der Rückweg stimmt.

Häufige Beispiele

Client erreicht Internet nicht: Capture auf Source IP und TCP 443 setzen. Wenn kein Paket ankommt, Client, VLAN, Gateway oder Switch prüfen. Wenn Paket reinkommt, aber nicht rausgeht, Firewall Regel, NAT oder Routing prüfen.

DNAT funktioniert nicht: Capture auf öffentliche Ziel-IP und externen Port setzen. Wenn kein Paket ankommt, Provider-Router, Portweiterleitung, Cloud Security Group oder WAN prüfen. Wenn Paket ankommt, aber nicht zum internen Server geht, DNAT-Regel und Firewall Regel prüfen.

VPN-Traffic läuft nicht: Capture auf Tunnel-Interface, XFRM-Interface oder relevante Quell-/Zielnetze setzen. Zusätzlich strongswan.log, charon.log oder xfrmi.log prüfen.

Webfilter blockiert unerwartet: Im Packet Capture sieht man meist nur den Paketfluss. Die Entscheidung selbst besser im Log Viewer unter Web, Application Control oder SSL/TLS inspection prüfen.

Wann tcpdump besser ist

Das WebAdmin Packet Capture ist ideal für schnelle Analysen. Für längere Mitschnitte, sehr genaue Filter oder Supportfälle ist CLI-basiertes tcpdump oft besser.

Mehr dazu: Sophos Firewall - Logs mit TCPDump für Analyse sammeln.

Weitere Informationen