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. Wenn eine Firewall-Regel gezielt getestet werden soll, passt zusätzlich der Ablauf in Sophos Firewall Regel testen mit Log Viewer, Policy tester und Packet Capture.

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.

Werkzeugwahl

Vor dem Mitschnitt sollte klar sein, welche Frage beantwortet werden soll. Packet Capture ist stark beim Paketfluss, der Log Viewer bei Policy-Entscheidungen und tcpdump bei längeren oder exportierbaren Mitschnitten.

Welcher Artikel passt?

Packet Capture ist besonders stark, wenn der echte Paketfluss unklar ist. Für verwandte Fragen ist manchmal ein anderer Einstieg schneller:

Diese Trennung ist wichtig: Packet Capture zeigt Pakete und Status auf Paketebene. Es ersetzt aber nicht den Log Viewer für Policy-Entscheidungen, nicht den NAT-Artikel für Übersetzungslogik und nicht tcpdump, wenn eine auswertbare PCAP-Datei gebraucht wird.

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.

Wenn der Fokus auf Drops, Violation, Rule ID, NAT ID oder verworfenen Paketen liegt, passt zusätzlich Sophos Firewall verworfene Pakete analysieren.

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.

Vor dem Öffnen sollte der Testfall bereits feststehen. Das Tool ist am stärksten, wenn man einen einzelnen Flow reproduziert und nicht erst während des Mitschnitts überlegt, wonach gesucht wird.

Nach dem Öffnen sollte man zuerst Configure verwenden und den Capture Filter setzen, bevor der Test ausgelöst wird. Wenn Destination, CDN-Ziel oder NAT-Sicht noch unklar sind, ist ein erster Filter auf die Source IP oft besser als ein zu enger Filter mit falscher Zieladresse. Nach dem reproduzierten Test sollte der Mitschnitt wieder gestoppt werden, damit die Ansicht nicht mit Hintergrundtraffic vollläuft.

Log Viewer, Packet Capture oder tcpdump?

Log Viewer, Packet Capture im WebAdmin und tcpdump beantworten unterschiedliche Fragen. Wer das falsche Werkzeug zuerst nimmt, sucht oft an der falschen Stelle.

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.
• Für Mitschnitte, die an Sophos Support oder externe Analysepartner gehen, ist tcpdump meistens besser als ein Screenshot aus dem WebAdmin.

Capture vorbereiten

Ein guter Packet Capture beginnt vor dem Klick auf den Startschalter. Je genauer Source, Ziel, Port und erwartete Richtung bekannt sind, desto schneller erkennt man, ob die Firewall den Traffic sieht und wie sie ihn verarbeitet.

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.

⚠️ Packet Capture sollte auf produktiven Firewalls nie als breiter Dauer-Mitschnitt laufen. Ein enger Filter, ein kurzer Test und ein klarer Zeitpunkt reduzieren Datenmenge, Datenschutzrisiko und Fehlinterpretationen.

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
• erwartete Firewall Rule oder NAT Rule, falls bekannt
• erwartetes Ergebnis: erlaubt, blockiert, DNAT, SNAT, VPN, Web Policy oder IPS

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

In der Praxis sollte man immer nur einen Testfall auf einmal reproduzieren. Mehrere parallele Änderungen an Firewall-Regel, NAT, Routing und Client-Konfiguration machen die Capture-Ausgabe schwer auswertbar. Wenn der Test ein Benutzerproblem betrifft, sollte man zusätzlich den angemeldeten Benutzer, das betroffene Gerät und die genaue Uhrzeit notieren.

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:

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

Wenn der Filter zu eng ist

Ein enger Capture Filter ist wichtig, aber er darf den Fehler nicht ausblenden. Besonders bei DNS, NAT, CDNs und Rückwegen sollte man bewusst entscheiden, ob zuerst breit genug oder sofort sehr präzise gefiltert wird.

Typische Stolpersteine:

Für den ersten Lauf ist ein Filter auf die Source IP oft sinnvoller als ein zu präziser Filter mit falscher Destination IP. Wenn der relevante Flow sichtbar ist, kann man im zweiten Lauf enger filtern. Bei NAT-Fehlern sollte man ausserdem prüfen, ob man gerade die Sicht vor oder nach der Übersetzung betrachtet.

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 ausführen

Nach dem Setzen des Filters wird genau ein Testfall reproduziert. Danach sollte der Mitschnitt wieder gestoppt werden, damit die Ausgabe übersichtlich bleibt und keine unnötigen Betriebsdaten gesammelt werden.

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:

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.

Ausgabe interpretieren

Die Paketliste wird erst wertvoll, wenn man Status, Interface, Rule ID und NAT ID richtig liest. Besonders wichtig ist die Unterscheidung zwischen Durchgangstraffic und Paketen, die für die Firewall selbst bestimmt sind.

Wichtige Spalten verstehen

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

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

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.

Consumed und Generated richtig lesen

Consumed und Generated werden leicht falsch interpretiert. Diese Status bedeuten nicht automatisch, dass eine normale Firewall-Regel fehlt.

Beispiele für Consumed sind Zugriffe auf WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP, IPsec oder SSL VPN der Firewall selbst. Solcher Traffic wird nicht wie normaler Durchgangstraffic durch eine LAN-to-WAN- oder WAN-to-DMZ-Regel behandelt. Wenn ein Paket im Capture Consumed zeigt, sollte man deshalb zuerst klären, ob der Client wirklich die Firewall selbst erreichen wollte.

Für diese Fälle sind Administration > Device access und Local Service ACL wichtiger als eine normale Firewall-Regel. Die Härtung dieser Zugriffe ist in Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren beschrieben.

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.

Typische Analysefälle

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.

Kleine Tests funktionieren, grosse Transfers hängen: Capture auf den betroffenen Client und das Ziel setzen und auf Retransmits, fehlende Antworten oder auffällige Paketgrössen achten. Wenn Ping, Login oder kleine HTTP-Requests funktionieren, grössere Downloads, RDP, VoIP oder VPN-Anwendungen aber hängen, sollte man zusätzlich MTU, MSS, PPPoE, VPN-Overhead und Fragmentierung prüfen. Der Ablauf steht in Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

Typische Fehlinterpretationen

Packet Capture zeigt sehr viel, aber nicht immer das, was man zuerst erwartet. Einige Fehlinterpretationen kommen in Supportfällen besonders häufig vor.

Wenn der Packet Capture eine unerwartete Rule ID zeigt, sollte man nicht sofort mehrere Regeln ändern. Besser ist zuerst ein Abgleich mit dem Log Viewer und der Regelposition. Für systematisches Matching passt Sophos Firewall Regel greift nicht: Ursachen prüfen.

Grenzen, Datenschutz und Weitergabe

Packet Capture ist schnell, aber nicht immer das richtige Werkzeug. Für längere Mitschnitte, PCAP-Dateien oder Supportanalysen ist tcpdump oft besser. Gleichzeitig enthalten Captures oft sensible Betriebsdaten.

Datenschutz und Weitergabe von Captures

Packet-Capture-Daten sind Betriebsdaten. Auch wenn oft nur Header sichtbar sind, können sie interne IP-Adressen, öffentliche Ziele, Benutzernamen, Hostnamen, Ports, Protokolle und Kommunikationsbeziehungen offenlegen. Bei unverschlüsselten Protokollen können zusätzlich Nutzdaten sichtbar sein.

Vor der Weitergabe sollte man deshalb prüfen:

• Enthält der Mitschnitt Kundennamen, interne Hostnamen oder öffentliche IP-Adressen?
• Sind Benutzer, Systeme oder Anwendungen erkennbar?
• Ist der Empfänger berechtigt, diese Informationen zu sehen?
• Reicht ein Screenshot der relevanten Zeilen oder braucht es wirklich eine PCAP-Datei?
• Muss der Mitschnitt vorher gekürzt oder anonymisiert werden?

Für Supportfälle ist oft ein gezielter tcpdump-Mitschnitt mit sauberem Filter besser als ein breiter WebAdmin-Capture. Wenn zusätzlich Logdateien benötigt werden, hilft Sophos Firewall Logs für Support und Analyse sichern.

Wann tcpdump besser ist

Das WebAdmin Packet Capture ist ideal für schnelle Analysen direkt im Browser. Man sieht schnell, ob Pakete ankommen, weitergeleitet, konsumiert, erzeugt oder verworfen werden. Für eine erste Eingrenzung ist das meistens der richtige Start.

tcpdump ist besser, wenn der Mitschnitt nicht nur als Bildschirmansicht gebraucht wird, sondern als auswertbare Datei oder als längere technische Spur.

Der wichtigste Unterschied: tcpdump zeigt Pakete, aber keine Sophos-spezifische Entscheidung. Wenn man wissen muss, welche Firewall-Regel, NAT-Regel, Web Policy, IPS Policy oder SSL/TLS-inspection-Regel beteiligt war, braucht man weiterhin Log Viewer, WebAdmin Packet Capture oder die passende Logdatei.

Vor tcpdump sollten SSH oder Advanced Shell bewusst freigegeben sein. Der Mitschnitt sollte eng gefiltert, zeitlich begrenzt und nach der Analyse wieder entfernt werden. Ein breiter PCAP auf einer produktiven Firewall kann schnell sensible Daten und unnötig viel Nebenverkehr enthalten.

Mehr dazu: Sophos Firewall tcpdump: Pakete per CLI mitschneiden.

Checkliste

• Testfall mit Source, Destination, Port, Protokoll und Uhrzeit notieren.
• Erwartete Firewall Rule und NAT Rule kennen, falls möglich.
• Capture Filter eng setzen.
• Bei DNS, NAT oder CDN-Zielen prüfen, ob der Filter Hin- und Rückrichtung wirklich erfasst.
• Nur einen Testfall gleichzeitig reproduzieren.
• Packet Capture nach dem Test wieder stoppen.
• Incoming, Forwarded, Consumed, Generated und Violation bewusst unterscheiden.
• Rule ID und NAT ID mit Log Viewer abgleichen.
• Bei fehlender Antwort Rückweg, NAT, Zielsystem und Gegenstelle prüfen.
• Bei hängenden grossen Transfers MTU/MSS, Fragmentierung und VPN-Overhead mitprüfen.
• Captures vor Weitergabe auf sensible Daten prüfen.
• Für längere Mitschnitte oder PCAP-Dateien tcpdump verwenden.

FAQ