Wenn eine Firewall-Regel nicht wie erwartet greift, hilft kein Raten am Regelwerk, sondern eine klare Diagnosekette. Die Sophos Firewall stellt dafür drei Werkzeuge bereit, die unterschiedliche Fragen beantworten. Der Log Viewer zeigt die gelogte Entscheidung, der Policy Test prüft die erwartete Policy-Logik und Packet Capture beweist den tatsächlichen Paketfluss auf dem Interface. Die offizielle Beschreibung liefert die Sophos-Dokumentation zu Packet Capture. In dieser Anleitung zeigen wir die richtige Reihenfolge, die Deutung der Paketstatus und einen wichtigen Vorbehalt bei SFOS 22.0, damit produktive Regeln nicht auf Basis eines Fehlbefunds umgebaut werden.
Key Takeaways: Firewall-Regeln testen
- Beim Firewall-Regel-Test ist die richtige Reihenfolge entscheidend: zuerst der Log Viewer, dann der Policy Test und erst danach Packet Capture.
- Ein sauberer Testfall besteht aus Source-IP, Destination-IP, Service oder Port, Benutzer und Zeit.
- Der Log Viewer zeigt die tatsächliche Rule ID, die NAT ID und das entscheidende Modul.
- Der Policy Test prüft die erwartete Policy-Logik, aber nicht den realen Paketfluss und Rückweg.
- Packet Capture im WebAdmin beweist, ob Pakete ankommen, weitergeleitet werden und Antworten zurückkommen.
- Bei SFOS 22.0 GA und MR1 kann der Policy Test einen Flow fälschlich als blockiert anzeigen, obwohl er korrekt läuft.
- Für längere Mitschnitte, PCAP-Dateien und Supportfälle sind tcpdump und drop-packet-capture über die Konsole geeignet.
- Eine manuelle Drop-All-and-Log-Regel am Ende des Regelwerks macht sonst unsichtbare Default-Drops sichtbar.
- Ein widersprüchlicher Diagnosebefund rechtfertigt keinen Umbau produktiver Regeln ohne Beleg.
Die drei wichtigsten Werkzeuge beim Firewall-Regel-Test
Der häufigste Fehler in der Fehlersuche ist der Griff zum falschen Werkzeug. Log Viewer, Policy Test und Packet Capture beantworten jeweils eine andere Frage. Ein Firewall-Regel-Test zeigt so, welche Rule ID tatsächlich gegriffen hat, welche NAT ID beteiligt war, ob ein Sicherheitsmodul eingegriffen hat und ob Hin- und Rückrichtung denselben erwarteten Pfad nutzen.
Log Viewer, Policy Test und Packet Capture im Überblick
| Werkzeug | Beantwortet | Grenze |
|---|---|---|
| Log Viewer | Welche Regel oder welches Modul hat die Verbindung entschieden | Zeigt nur, was auch geloggt wird |
| Policy Test | Welche Regel sollte laut Policy-Logik greifen | Bildet Routing, NAT und Rückweg nicht vollständig ab |
| Packet Capture | Ob Pakete ankommen, weitergeleitet werden und zurückkehren | Zeigt den Fluss, nicht die Modulentscheidung im Detail |
Die richtige Reihenfolge sammelt zuerst den sichtbaren Befund, wechselt dann zum Paketfluss und erst danach zu Dienstlogs oder Debug. So bleibt die Analyse klein und reproduzierbar. Eine breitere Übersicht der Diagnosewerkzeuge bietet unser Sophos Firewall Troubleshooting. Geht es nicht um eine Regel, sondern um Durchsatz, passen unser iPerf-Test und der WAN-Speedtest per SSH.
Testfall sauber definieren
Eine Regel lässt sich nur sinnvoll testen, wenn der Testfall eindeutig ist. Aussagen wie "Internet geht nicht" sind zu breit, was aber vermutlich jedem erfahrenen Admin klar ist. Für eine belastbare Analyse braucht es also einen konkreten Flow mit festen Angaben:
- Source-IP und Source-Zone der Verbindung.
- Destination-IP und der Zieldienst als Port oder Protokoll.
- Betroffener Benutzer, sofern die Regel benutzerbezogen ist.
- Lokale Zeit des Testlaufs für die spätere Filterung im Log Viewer.
- Aktives Logging in der Regel, damit die Entscheidung überhaupt sichtbar wird.
Ändert sich während der Analyse die Source-IP, das Ziel, die DNS-Auflösung oder der Port, wird nicht mehr derselbe Fall verglichen. Ist das Logging in der Regel oder unter System-Services und Log-Einstellungen nicht aktiv, erscheint die Entscheidung lokal, in Sophos Central und im Syslog nicht zuverlässig.
Log Viewer: welche Regel und welches Modul entschieden hat
Der Log Viewer öffnet sich oben rechts in der WebAdmin-Konsole und aktualisiert sich automatisch. Er lässt sich nach Modul, Zeit, Feldwerten und Freitext filtern und als CSV exportieren. Für den Regel-Test wird nach Source-IP, Destination-IP und Service gefiltert, danach werden Rule ID und NAT Rule ID aus dem tatsächlichen Logeintrag abgelesen.
Erscheint Webtraffic als blockiert, kann die Ursache in mehreren Modulen liegen, etwa in der Web Policy, der TLS Inspection, der Application Control, dem IPS, einer WAF-Regel oder der Deep Packet Inspection. Deshalb wählen wir im Log Viewer immer das konkrete Modul aus und prüfen zusätzlich die passende Logdatei. Ein wichtiger Lesefehler betrifft den Status allowed. Zeigt die Firewall-Regel allowed, kann eine nachgelagerte Web Policy, Application Control oder TLS Inspection den Zugriff trotzdem blockieren. Allowed auf Regelebene bedeutet also nicht, dass der Benutzer das Ziel tatsächlich erreicht.
Policy Test richtig nutzen und Grenzen kennen
Der Policy Test unter Diagnostics prüft die erwartete Policy-Logik für einen definierten Fall. Die Eingabe muss bewusst gesetzt werden, denn der Test nutzt URL, Benutzer, Zeit, Source-IP und Source-Zone. Ohne angegebenes Protokoll testet Sophos standardmäßig HTTP, für HTTPS wird üblicherweise Port 443 verwendet. Regeln mit MAC-Adressen unter den Source-Netzen kann der Policy Test nicht abbilden.
Policy Test unter SFOS 22.0 GA und 22.0 MR1
Bei SFOS 22.0 GA und SFOS 22.0 MR1 kann der Policy Test einen Flow als blockiert anzeigen oder der falschen Regel zuordnen, obwohl der produktive Traffic korrekt durch die Firewall läuft. In unseren Augen ist die Konsequenz entscheidend. Zeigt der Policy Test ein unerwartetes Ergebnis, während Log Viewer, Rule Counter und Packet Capture den tatsächlichen Paketfluss bestätigen, sollten produktive Firewall- oder NAT-Regeln nicht sofort geändert werden. Zuerst wird geprüft, ob nur die Diagnoseanzeige betroffen ist.
Packet Capture im WebAdmin
Packet Capture zeigt die Details der Pakete, die ein Interface passieren, inklusive Rule ID, NAT ID, Benutzer und beteiligtem Modul. Die WebAdmin-Variante ist ideal für einen ersten Check, weil direkt im Browser sichtbar wird, ob Pakete ankommen, weitergeleitet oder verworfen werden. Der Aufruf erfolgt über Diagnostics und Packet capture.
- Den Testfall eng eingrenzen und Source-IP, Destination-IP, Port und Protokoll notieren.
- Über Configure einen Capture-Filter als BPF-Ausdruck setzen, zum Beispiel host 192.0.2.10 and port 443.
- Packet Capture einschalten und den Testfall genau einmal reproduzieren.
- Packet Capture wieder ausschalten und die Einträge nach Incoming, Forwarded und Reply prüfen.
Der Capture-Filter begrenzt, welche Pakete überhaupt aufgezeichnet werden. Der Display-Filter filtert dagegen nur die bereits aufgezeichnete Ansicht nach Interface, Status, Rule ID oder Verbindung. Je enger der Filter, desto lesbarer das Ergebnis. Sind DNS, DNAT oder CDN-Ziele beteiligt, sind oft zwei kurze Captures besser als ein breiter Mitschnitt.
Paketstatus deuten: Incoming, Forwarded, Reply und Violation
Der Status eines Pakets bestimmt, welches Werkzeug als Nächstes sinnvoll ist. Die folgende Tabelle ordnet die häufigsten Fälle einem konkreten Prüfschritt zu.
Paketstatus und nächster Prüfschritt
| Beobachtung | Wahrscheinliche Ursache und nächster Schritt |
|---|---|
| Kein Paket kommt an | Problem vor der Firewall, also Client, Switch, VLAN, Gateway, Provider oder Cloud Security Group prüfen |
| Incoming sichtbar, kein Forwarded | Paket hängt auf der Firewall, also Firewall-Regel, NAT, Routing oder Sicherheitsfeature prüfen |
| Forwarded sichtbar, keine Antwort | Rückweg oder Zielsystem prüfen, dazu Return-Route, NAT oder externe Firewall |
| Status Violation | Policy, IPS, Webfilter oder Application Control prüfen |
| Status Consumed | Device Access und Local Service ACL statt einer Firewall-Regel prüfen |
Zwei Reaktionen werden dabei oft verwechselt. Beim Verwerfen (Drop) verschwindet das Paket ohne Rückmeldung und der Client läuft in einen Timeout. Beim Zurückweisen (Reject) antwortet die Firewall aktiv mit einer Ablehnung und der Verbindungsaufbau scheitert sofort. Ein Timeout deutet damit eher auf einen Drop, ein sofortiger Abbruch eher auf einen Reject oder ein antwortendes Zielsystem.
Ein Sonderfall betrifft SFOS 22.0.1 MR1. Trifft ein Testfall keine explizite Regel, verwirft die Firewall den Traffic korrekt über die Default-Regel mit der Firewall ID 0. Dieser Drop kann jedoch in der Dropped Packet Capture fehlen. In einem solchen Fall hilft ein Policy Test oder eine explizite, geloggte Abschlussregel. Saubere Testpfade setzen zudem eine durchdachte Netzwerksegmentierung voraus.
Drop-All-and-Log-Regel als Voraussetzung
Die Default-Regel mit der Firewall ID 0 verwirft nicht zugeordneten Traffic korrekt, protokolliert diese Drops aber nicht. Genau dieser Traffic bleibt damit unsichtbar, obwohl er für die Diagnose oft am wichtigsten ist. In unseren Augen gehört deshalb eine manuelle Drop-All-and-Log-Regel als letzte Regel in jedes Regelwerk, denn erst sie macht die stillen Default-Drops im Log Viewer und im Packet Capture sichtbar.
Die Regel gehört ganz ans Ende des Regelwerks, nutzt die Aktion Verwerfen und aktiviert das Protokollieren des Traffics. Den vollständigen Ablauf samt Position, Logvolumen und IPv6 zeigt unsere Anleitung zur Drop-All-and-Log-Regel. Wie sich die geloggten Drops anschließend deuten lassen, behandelt unsere Anleitung zum Lesen der Sophos Firewall Logs.
tcpdump und drop-packet-capture über die Konsole
Für längere Mitschnitte, PCAP-Dateien, sehr präzise Filter oder einen Supportfall ist die Konsole der bessere Ort. Sophos trennt dabei zwei Bereiche, die oft verwechselt werden. In der Device Console laufen netzwerknahe Diagnosebefehle, in der Advanced Shell dagegen Datei- und Log-Operationen.
tcpdump 'host 192.0.2.10 and port 443'
Ist unklar, ob die Firewall Pakete aktiv verwirft, zeigt drop-packet-capture gezielt die durch Regeln verworfenen Pakete.
drop-packet-capture 'host 192.0.2.10'
Nach dem SSH-Login erscheint das Konsolenmenü. Die Device Console erreichen Sie über den Menüpunkt 4, die Advanced Shell über 5 und dann 3. CLI- und Shell-Befehle sollten nur aus vertrauenswürdigen Admin-Netzen und mit klarem Ziel ausgeführt werden, da Debug, tcpdump und Dateioperationen Speicher, Performance und laufende Verbindungen beeinflussen können. Wie sich der Zugang absichern lässt, behandelt unser Leitfaden zur Firewall-Härtung.
Regel-Änderungen sicher umsetzen
Ein fehlerhafter Diagnosebefund darf nicht dazu führen, dass funktionierende produktive Regeln umsortiert oder NAT-Regeln ohne Beleg angepasst werden. Vor einer produktiven Änderung lohnt eine kleine Vorher-Nachher-Kontrolle mit fester Disziplin.
- Ein Backup oder Wiederherstellungspunkt existiert, sodass ein Rückbau jederzeit möglich bleibt.
- Der Testfall ist vorab definiert, damit der Erfolg nicht nur nach Gefühl bewertet wird.
- Pro Test wird nur eine Änderung vorgenommen, damit Ursache und Wirkung nachvollziehbar bleiben.
- Der reale Rule ID und die NAT ID werden im Log Viewer oder in den zentralen Logs gegengeprüft.
- Temporäre Testregeln werden nach der Analyse wieder entfernt.
Bei mehreren Firewalls oder zentral verwalteten Gruppen wird zusätzlich geprüft, ob die Änderung auf der richtigen Appliance angekommen ist. Reicht die eigene Analyse nicht aus, unterstützt Sie unser Team beim Firewall Audit auf einer Sophos Firewall im produktiven Betrieb.
Fazit: Firewall-Regeln testen mit System statt Bauchgefühl
Ein sauberer Regel-Test folgt einer festen Kette. Zuerst zeigt der Log Viewer die tatsächliche Entscheidung mit Rule ID, NAT ID und Modul, dann prüft der Policy Test die erwartete Logik und schließlich beweist Packet Capture den realen Paketfluss samt Rückweg. Gerade bei SFOS 22.0 gilt, dass ein widersprüchlicher Policy-Test-Befund keine Grundlage für den Umbau produktiver Regeln ist, solange Log Viewer, Rule Counter und Packet Capture den korrekten Fluss bestätigen. Für tiefere Mitschnitte helfen tcpdump und drop-packet-capture über die Konsole. Für eine externe Bewertung des Regelwerks steht Ihnen unser Team beim Firewall Audit zur Seite.
info FAQ zum Testen von Firewall-Regeln arrow_drop_down
FAQ: Firewall-Regeln testen
In welcher Reihenfolge teste ich eine Firewall-Regel auf der Sophos Firewall?
Zuerst wird ein enger Testfall definiert und das Logging in der Regel geprüft. Danach zeigt der Log Viewer die tatsächliche Entscheidung, der Policy Test prüft die erwartete Logik und Packet Capture beweist den realen Paketfluss. tcpdump und drop-packet-capture über die Konsole folgen erst bei längeren Mitschnitten oder Supportfällen.
Worin unterscheiden sich Policy Test und Packet Capture?
Der Policy Test bewertet die erwartete Policy-Logik, bildet aber Routing, NAT, SD-WAN und den Rückweg nicht vollständig ab. Packet Capture zeigt den tatsächlichen Paketfluss auf Interface-Ebene, also ob Pakete ankommen, weitergeleitet werden und Antworten zurückkehren. Bei widersprüchlichen Ergebnissen ist Packet Capture das belastbarere Werkzeug.
Warum zeigt der Policy Test bei SFOS 22.0 ein falsches Ergebnis?
Bei SFOS 22.0 GA und SFOS 22.0 MR1 kann der Policy Test einen Flow als blockiert anzeigen oder der falschen Regel zuordnen, obwohl der Traffic korrekt fließt. Bestätigen Log Viewer, Rule Counter und Packet Capture den tatsächlichen Fluss, sollten produktive Regeln nicht geändert werden. Zuerst wird geprüft, ob nur die Diagnoseanzeige betroffen ist.
Was bedeutet der Status Violation im Packet Capture?
Violation bedeutet, dass die Firewall das Paket aufgrund einer Policy verworfen hat. Zu prüfen sind dann Grund, Rule ID, NAT ID und die beteiligten Module wie IPS, Webfilter oder Application Control. Viele Drops sind gewollt und werden erst dann zum Problem, wenn legitimer Traffic betroffen ist oder die Ursache unklar bleibt.
Wann sollte ich tcpdump statt Packet Capture im WebAdmin nutzen?
Für kurze Checks ist Packet Capture im WebAdmin meist schneller. tcpdump über die Device Console ist besser, wenn ein längerer Mitschnitt, eine PCAP-Datei, ein sehr präziser BPF-Filter oder ein Supportfall für Sophos benötigt wird. drop-packet-capture hilft, wenn unklar ist, ob die Firewall Pakete aktiv verwirft.
Warum erscheint eine Verbindung nicht im Log Viewer?
Häufig ist das Logging in der Regel oder unter System-Services und Log-Einstellungen nicht aktiv. Möglich ist auch, dass der Traffic die Firewall nicht erreicht oder die Verbindung nicht mit einem passenden Log-Ereignis endet. Packet Capture und Policy Test helfen dann bei der Abgrenzung, ob das Paket überhaupt ankommt.
