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.
| Tool | Zeigt vor allem |
|---|---|
| Log Viewer | Welche Firewall Regel, Web Policy, Application Control, IPS oder SSL/TLS inspection entschieden hat |
| Packet Capture | Ob 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:
| Feld | Beispiel |
|---|---|
| Source IP | 172.16.10.25 |
| Destination | 93.184.216.34 |
| Protocol | TCP |
| Destination Port | 443 |
| Erwartete Richtung | LAN 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:
| Ziel | BPF-Beispiel |
|---|---|
| bestimmter Host | host 10.10.10.1 |
| bestimmte Source IP | src host 10.10.10.1 |
| bestimmte Destination IP | dst host 10.10.10.1 |
| bestimmtes Netz | net 10.10.10.0 |
| bestimmter Port | port 443 |
| bestimmter Zielport | dst port 443 |
| bestimmter Host und Port | host 10.10.10.1 and port 443 |
| ICMP/Ping | proto ICMP |
| TCP | proto TCP |
| UDP | proto 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.


⚠️ 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
- Filter setzen.
- Packet Capture über den Schieberegler einschalten.
- Problem gezielt reproduzieren.
- Capture wieder stoppen.
- Ergebnisse analysieren.
- Capture leeren, wenn ein neuer Test gestartet wird.
Sophos Firewall zeigt den Status und den Buffer an:
| Anzeige | Bedeutung |
|---|---|
Trace On | Packet Capture läuft |
Trace Off | Packet Capture ist ausgeschaltet |
Buffer size | Grösse des Capture-Buffers, in der Sophos-Dokumentation 2048 KB |
Buffer used | aktuell 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:
| Feld | Bedeutung |
|---|---|
| Time | Zeitpunkt des Pakets |
| In interface | Interface, auf dem das Paket reinkam |
| Out interface | Interface, über das das Paket rausgeht |
| Source IP | Quelladresse |
| Destination IP | Zieladresse |
| Packet type | Protokoll oder Pakettyp |
| Ports [src, dst] | Quell- und Zielport |
| NAT ID | passende NAT-Regel |
| Rule ID | passende Firewall Regel |
| Status | Paketstatus |
| Reason | Grund für Drop oder Violation |
| Connection status | Zustand der Verbindung |
| Gateway ID | verwendetes Gateway |
| Username | erkannter Benutzer |
| IPS policy ID | angewendete IPS Policy |
| Application filter ID | angewendete 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
| Status | Bedeutung |
|---|---|
| Incoming | Paket wurde auf einem Interface empfangen |
| Forwarded | Paket wurde weitergeleitet |
| Consumed | Paket ist für die Firewall selbst bestimmt |
| Generated | Paket wurde von der Firewall erzeugt |
| Violation | Paket 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:
- Log Viewer öffnen.
- Packet Capture mit engem Filter starten.
- Test reproduzieren.
- Im Packet Capture prüfen, ob Pakete ankommen und weitergehen.
- Im Log Viewer prüfen, welche Regel oder welches Modul entschieden hat.
- 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.