Sophos Firewall-Regel sauber testen

Eine Firewall-Regel sollte man nicht nur speichern, sondern gezielt testen. Gerade bei Webfilter, TLS Inspection, NAT, IPS oder User Matching kann eine Regel optisch korrekt aussehen und trotzdem nicht so greifen, wie man erwartet.

Für den Test eignen sich mehrere Werkzeuge:

• Log viewer für echte Events und Regelentscheidungen
• Policy tester für Web-, Firewall- und SSL/TLS-Policy-Logik
• Packet capture für den tatsächlichen Paketfluss
• tcpdump für längere Mitschnitte, PCAP-Dateien und Supportfälle

Wichtig ist die richtige Reihenfolge: Zuerst wird geprüft, ob der Test sauber definiert ist und die Regel Logging erzeugt. Danach zeigt der Log Viewer, welche Entscheidung die Firewall tatsächlich protokolliert. Der Policy tester hilft bei der erwarteten Policy-Logik, beweist aber keinen echten Paketfluss. Packet Capture ist der beste Nachweis, wenn Routing, NAT, VLAN, VPN, Provider oder ein Zielsystem beteiligt sein könnten. Wenn der Test länger laufen muss, eine PCAP-Datei benötigt wird oder Sophos Support den Mitschnitt auswerten soll, ist tcpdump auf der Sophos Firewall das bessere Werkzeug.

Ein guter Regeltest beantwortet deshalb nicht nur die Frage, ob eine Regel „funktioniert“. Er zeigt, welche Rule ID tatsächlich gematcht hat, welche NAT ID beteiligt war, ob Security-Features eingegriffen haben und ob Hin- und Rückrichtung denselben erwarteten Pfad nehmen.

Welcher Artikel passt?

Dieser Artikel ist der richtige Einstieg, wenn ein konkreter Verbindungsversuch mit Source IP, Destination, Service und Uhrzeit getestet werden soll. Bei verwandten Fehlerbildern ist ein spezifischerer Artikel oft schneller:

• Eine Regel matcht gar nicht oder eine andere Regel gewinnt: Sophos-Firewall-Regel greift nicht: Ursachen prüfen.
• DNAT, SNAT, MASQ oder NAT-Reihenfolge ist beteiligt: NAT auf Sophos Firewall verstehen.
• Ein interner Server wird aus dem Internet veröffentlicht: Server per DNAT veröffentlichen.
• Packet Capture zeigt Drops, Violation oder unerwartete Drop-Gründe: Sophos Firewall verworfene Pakete analysieren.
• SSL VPN ist verbunden, aber interne Ziele funktionieren nicht: Sophos Firewall SSL VPN Remote Access einrichten.
• Site-to-Site-IPsec oder Remote-Access-IPsec macht Probleme: Sophos Firewall IPsec VPN Troubleshooting.
• WebAdmin-Werkzeuge reichen nicht und lokale Logs werden gebraucht: Sophos Firewall Troubleshooting: Services und Logs.
• Ein Supportfall braucht Logarchiv, IPsec-Daten oder PCAP-Dateien: Sophos Firewall Logs für Support und Analyse sichern.

Diese Abgrenzung verhindert, dass man mit einem allgemeinen Regeltest ein spezifisches NAT-, VPN-, Routing- oder Dienstproblem zu breit untersucht.

Die Werkzeuge richtig einordnen

• Log viewer: Zeigt Rule ID, NAT ID, Action, Benutzer und Security-Feature-Entscheidungen. Er beweist aber keine Pakete, die die Firewall gar nicht erreichen.
• Policy tester: Zeigt die erwartete Firewall-, Web- und SSL/TLS-Policy für definierte Eingaben. Er beweist keinen echten Rückweg, kein SD-WAN-Verhalten, keinen Paketverlust und kein Providerproblem.
• Packet capture: Zeigt, ob Pakete ankommen, weitergeleitet werden und ob Antworten zurückkommen. Er erklärt aber nicht automatisch die fachliche Absicht hinter einer Regel oder Web Policy.
• tcpdump: Eignet sich für längere Mitschnitte, sehr genaue BPF-Filter, PCAP-Dateien und Wireshark-Analyse. Rule ID, NAT ID oder Web-Policy-Entscheidungen sieht man damit nicht direkt im WebAdmin.
• Central Reporting oder Syslog: Hilft für Verlauf, Reports, SIEM-Korrelation und spätere Auswertung. Für Live-Paketfluss und lokale Dienstdetails bleiben lokale Werkzeuge meist schneller.

Wenn eine Regel angeblich “nicht greift”, sollte man deshalb nicht sofort an der Regel selbst ändern. Häufig liegt die Ursache in NAT, Routing, einer übergeordneten Regel, fehlendem Logging oder einem Security Feature. Für die systematische Fehlersuche passt zusätzlich Sophos-Firewall-Regel greift nicht: Ursachen prüfen.

Für Live-Troubleshooting bleibt der lokale Log Viewer meistens schneller als Central Reporting oder ein SIEM. Zentrale Logs sind wichtig, wenn Ereignisse später nachvollzogen, korreliert oder über längere Zeit aufbewahrt werden müssen. Für die Einrichtung passen Central Firewall Reporting und Syslog an SIEM senden.

Kurzablauf für den Regeltest

Für die meisten Supportfälle reicht ein klarer Ablauf:

1. Testfall mit Source IP, Destination, Service, Benutzer und Uhrzeit festlegen.
2. Log firewall traffic in der betroffenen Regel aktivieren.
3. Regelposition und Usage Counter prüfen.
4. Test genau einmal reproduzieren.
5. Log Viewer nach Source IP, Destination IP und Service filtern.
6. Rule ID und NAT ID aus dem echten Logeintrag notieren.
7. Policy tester nur zur Policy-Logik verwenden.
8. Packet Capture starten, wenn Log Viewer und Policy tester nicht zusammenpassen.
9. Ergebnis dokumentieren, bevor eine Regel verschoben oder verändert wird.

Wichtig ist, pro Durchlauf nur einen Testfall zu verändern. Wenn gleichzeitig Regelposition, NAT, DNS, Routing und Client geändert werden, lässt sich der spätere Erfolg nicht mehr sauber zuordnen.

Dieser Ablauf verhindert, dass man eine funktionierende Regel unnötig umbaut, obwohl das eigentliche Problem bei NAT, Routing, DNS, TLS Inspection oder einem Zielsystem liegt.

Vor dem Test

Zuerst sollte man genau notieren, was getestet werden soll:

• Source IP: 172.16.10.25
• Benutzer: user@domain.local
• Source zone: LAN
• Destination: https://www.example.com
• Service: HTTPS
• Erwartete Regel: LAN_to_WAN_Clients
• Erwartete Action: erlaubt, blockiert, decrypted, nicht decrypted

Danach in der betroffenen Firewall-Regel Log firewall traffic aktivieren. Ohne Logging ist der Log Viewer nur begrenzt hilfreich.

Schritt 1: Regelposition prüfen

Man öffnet Rules and policies > Firewall rules und prüft:

• Steht die Regel oberhalb allgemeinerer Regeln?
• Ist sie aktiv?
• Ist die richtige IPv4- oder IPv6-Ansicht ausgewählt?
• Ist sie in einer sinnvollen Rule group?
• Gibt es Exclusions?
• Gibt es eine automatisch erstellte Regel darüber?

Wenn man eine neue Regel testet, sollte man den Usage Counter der Regel zurücksetzen. Danach lässt sich besser erkennen, ob die Regel beim Test wirklich getroffen wurde.

Schritt 2: Log Viewer öffnen

Man öffnet oben rechts in der WebAdmin-Konsole den Log viewer.

Nützliche Filter:

• Module: Firewall
• Source IP
• Destination IP
• Destination port
• Rule ID
• Rule name
• Action
• User

Für Webtraffic zusätzlich prüfen:

• Web filter
• SSL/TLS inspection
• Application filter
• IPS

Der Log Viewer aktualisiert sich automatisch. Für ruhige Analyse kann man die Live-Ansicht pausieren, filtern und danach wieder fortsetzen.

Schritt 3: Test reproduzieren

Der Test sollte von einem definierten Client ausgeführt werden:

• Website öffnen
• Ping senden
• Port testen
• Anwendung starten
• VPN-Verbindung aufbauen
• Datei herunterladen

Wenn möglich, sollte immer nur ein Test zur gleichen Zeit laufen. Sonst vermischen sich Logs und Regelzähler.

Danach prüfen:

• Steigt der Regelzähler?
• Sieht man ein Log im Log Viewer?
• Welche Rule ID wird angezeigt?
• Welche NAT Rule ID wird angezeigt?
• Wird der Traffic erlaubt oder blockiert?
• Greift ein Security Feature?

Wenn der Log Viewer leer bleibt, ist das noch kein Beweis gegen die Regel. Dann zuerst Logging, Zeitfilter, Modulfilter und echten Paketfluss prüfen. Häufig erreicht der Traffic die Firewall gar nicht, die Regel loggt nicht, der falsche Logtyp ist deaktiviert oder der Test nutzt eine andere Ziel-IP als erwartet.

Schritt 4: Policy tester verwenden

Der Policy tester ist hilfreich, wenn man prüfen möchte, welche Firewall-Regel, SSL/TLS inspection rule oder Web Policy für Webtraffic theoretisch greifen würde.

Menüpfad:

Diagnostics > Tools > Policy tester

Typische Eingaben:

• URL
• Benutzer
• Zeit und Tag
• Source IP
• Source zone
• Test method

Als Test method wählt man zum Beispiel Firewall, SSL/TLS, and web, wenn die Kombination aus Firewall-Regel, SSL/TLS inspection rule und Web Policy geprüft werden soll.

Der Policy tester zeigt nicht nur Accepted oder Blocked, sondern auch die gematchte Firewall-Regel, die erkannte Destination, die Source zone und je nach Testmethode weitere Web- oder SSL/TLS-Informationen. Dadurch sieht man schnell, ob der Traffic grundsätzlich in der erwarteten Regel landet.

Wichtig:

⚠️ Der Policy tester ersetzt keinen echten Paketfluss-Test. Policy-Test-Ergebnisse bilden SD-WAN routes nicht zuverlässig ab. Das tatsächliche Verhalten kann deshalb abweichen, wenn SD-WAN, Routing oder Gateways beteiligt sind.

SFOS 22: Policy tester kann falsche Ergebnisse anzeigen

Bei SFOS 22.0 GA und SFOS 22.0 MR1 sollte man Policy-Test-Ergebnisse besonders vorsichtig bewerten. Policy Test und Policy Route Test können Traffic in bestimmten Fällen als blockiert anzeigen oder einer falschen Regel zuordnen, obwohl produktiver Traffic korrekt durch die Firewall läuft.

Für Admins ist die Konsequenz wichtig: Wenn der Policy tester ein unerwartetes Ergebnis zeigt, aber Log Viewer, Regelzähler und Packet Capture den echten Paketfluss bestätigen, sollte man nicht sofort Firewall-Regeln oder NAT-Regeln umbauen. Zuerst wird geprüft, ob es nur die Diagnoseanzeige betrifft.

Praktischer Ablauf bei widersprüchlichen Ergebnissen:

1. Test mit Source IP, Destination, Service und Benutzer sauber dokumentieren.
2. Log Viewer nach Source IP, Destination IP und Service filtern.
3. Rule ID und NAT Rule ID aus dem echten Logeintrag prüfen.
4. Packet Capture mit engem Filter starten.
5. Incoming, Forwarded und Rücktraffic vergleichen.
6. Policy-tester-Ergebnis nur als Hinweis behandeln, nicht als alleinigen Beweis.
7. Firmwarestand und Sophos Known Issues prüfen, bevor produktive Regeln geändert werden.

Diese Vorsicht gilt besonders in Wartungsfenstern. Ein falsches Diagnoseergebnis sollte nicht dazu führen, dass funktionierende produktive Regeln neu sortiert oder NAT-Regeln ohne Beweis angepasst werden.

Der Policy tester ist besonders gut für:

• Web Policy
• URL-Kategorisierung
• User-Kontext
• Schedule
• SSL/TLS inspection rule
• Firewall-Regel-Matching für Webtraffic

Er ist weniger gut für:

• echte Routing-Entscheidungen
• NAT-Rückweg
• Paketverluste
• Provider- oder Switch-Probleme
• Anwendungen mit mehreren Verbindungen und Ports

Schritt 5: Packet Capture einsetzen

Wenn Log Viewer und Policy tester nicht reichen, nutzt man Diagnostics > Packet capture.

Der Filter sollte eng gesetzt werden, zum Beispiel:

• Source IP des Clients
• Destination IP des Servers
• Destination port
• Protokoll

Dann:

1. Packet Capture starten.
2. Test reproduzieren.
3. Packet Capture stoppen.
4. Incoming und Forwarded Events vergleichen.
5. Rule ID und NAT ID mit Log Viewer vergleichen.

Interpretation:

• Kein Paket kommt an: Client, VLAN, Switch, Gateway, Provider oder Cloud Security Group prüfen.
• Paket kommt rein, geht aber nicht raus: Firewall-Regel, NAT, Routing oder Security Feature prüfen.
• Paket geht raus, Antwort fehlt: Rückroute, Zielsystem, NAT oder externe Firewall prüfen.
• Paket hat Status Violation: Policy, IPS, Webfilter oder Application Control prüfen.
• NAT ID ist unerwartet: NAT-Reihenfolge und generische NAT-Regeln prüfen.

Mehr dazu: Packet Capture Tool im WebAdmin verwenden. Wenn Pakete verworfen werden, ist zusätzlich Sophos Firewall verworfene Pakete analysieren hilfreich.

Log Viewer und Packet Capture zusammen lesen

Der Log Viewer zeigt die Entscheidung, Packet Capture zeigt den Paketfluss. In der Praxis braucht man oft beide Sichtweisen.

• Log Viewer zeigt erwartete Rule ID, Packet Capture zeigt Forwarded: Der Regeltest ist für die Firewall plausibel. Rückweg und Zielsystem bleiben separat zu prüfen.
• Log Viewer zeigt erwartete Rule ID, Packet Capture zeigt keine Antwort: Zielsystem, Rückroute, NAT oder externe Firewall prüfen.
• Packet Capture zeigt Incoming, aber kein passendes Log: Logging, Modulfilter, Default-Regel, Device Access oder Drop-Analyse prüfen.
• Packet Capture zeigt Consumed: Traffic endet auf der Firewall selbst. Device Access und Local Service ACL prüfen.
• Packet Capture zeigt Violation: Reason, Rule ID, NAT ID und Security-Modul mit Log Viewer abgleichen.

Wenn beide Werkzeuge widersprüchlich wirken, sollte zuerst der Testfall enger gemacht werden. Ein einzelner Client, ein Ziel, ein Port und ein kurzer Testzeitpunkt sind besser als ein breiter Mitschnitt mit viel Hintergrundtraffic.

Enge Packet-Capture-Filter verwenden

Packet Capture ist nur hilfreich, wenn der Filter eng genug ist. Ein zu breiter Mitschnitt zeigt schnell zu viel Hintergrundtraffic, besonders auf produktiven Firewalls mit Web, DNS, VPN oder Serververkehr. Der Filter sollte deshalb aus dem definierten Testfall abgeleitet werden.

Praktische BPF-Beispiele:

• Einzelner Client zu einem Ziel: host 172.16.10.25 and host 203.0.113.10, wenn Source und Destination bekannt sind.
• Client zu HTTPS-Ziel: host 172.16.10.25 and port 443, wenn das Ziel über DNS oder CDN wechseln kann.
• Nur ausgehender Traffic eines Clients: src host 172.16.10.25, wenn zuerst geprüft wird, ob der Client überhaupt sendet.
• Nur Antworttraffic zum Client: dst host 172.16.10.25, wenn Rückweg oder Antwortpakete fehlen.
• DNS-Test: host 172.16.10.25 and port 53, wenn Namensauflösung und Regeltest getrennt geprüft werden sollen.
• ICMP-Test: icmp and host 172.16.10.25, wenn ein Ping als einfacher Erreichbarkeitstest dient.

Bei DNAT- oder VPN-Tests sollte man besonders auf die Blickrichtung achten. Ein Filter auf die interne Server-IP zeigt nicht zwingend den ursprünglichen Zugriff auf die öffentliche IP. Umgekehrt zeigt ein Filter auf die öffentliche IP nicht automatisch, ob der Traffic nach NAT beim internen Server ankommt. In solchen Fällen sind oft zwei kurze Captures sauberer: zuerst auf die öffentliche Seite, danach auf das interne Ziel.

Nach dem Test sollte man den Capture sofort stoppen. Lange Mitschnitte erhöhen das Risiko, unnötige Nutzdaten, interne Hostnamen oder fremde Verbindungen mitzuschneiden.

Wann man auf tcpdump wechselt

Das WebAdmin Packet Capture ist für schnelle Tests ideal. Es reicht aber nicht für jeden Fall. Auf tcpdump sollte man wechseln, wenn einer dieser Punkte zutrifft:

• Der Mitschnitt soll als PCAP-Datei in Wireshark oder durch Support ausgewertet werden.
• Der Test läuft länger als ein kurzer manueller Reproduktionstest.
• Es braucht sehr genaue BPF-Filter, zum Beispiel für VoIP, VPN, DNS oder mehrere Hosts.
• Der WebAdmin-Buffer läuft voll oder zeigt nur einen Ausschnitt.
• Der relevante Traffic muss auf einem bestimmten Interface über längere Zeit beobachtet werden.

Auch bei tcpdump gilt: Filter eng setzen, Testzeit notieren, Mitschnitt kurz halten und die Datei nach der Übertragung wieder entfernen. Die praktische CLI-Anleitung steht in Sophos Firewall tcpdump: Pakete per CLI mitschneiden.

Schritt 6: Security Features einzeln validieren

Wenn die richtige Regel matcht, aber der Traffic nicht funktioniert, sollten die aktivierten Features einzeln geprüft werden.

• Web policy: Kategorie, Benutzer, Schedule und Policy-Reihenfolge prüfen.
• Scan HTTP and decrypted HTTPS: HTTPS wird nur gescannt, wenn es bereits decrypted ist.
• SSL/TLS inspection: passende Regel, Decryption Profile und CA-Zertifikat auf Clients prüfen.
• IPS: Signatur, Policy und mögliche False Positives prüfen.
• Application Control: erkannte Anwendung, Kategorie und Cloud-App-Erkennung prüfen.
• Security Heartbeat: prüfen, ob der Endpoint Heartbeat sendet und ob Status grün, gelb oder rot ist.
• Traffic Shaping: prüfen, ob die Policy aktiv ist und zur richtigen Anwendung oder Regel passt.
• NAT: korrekte SNAT-, DNAT- oder PAT-Regel und die Regelreihenfolge prüfen.

Für HTTPS gilt: Eine Firewall-Regel mit Webfilterung reicht nicht aus, um HTTPS-Inhalte zu prüfen. Es braucht zusätzlich eine passende SSL/TLS inspection rule mit Decryption und verteiltem CA-Zertifikat.

Mehr dazu: TLS Inspection auf Sophos Firewall schrittweise ausrollen. Für NAT-Fehler passt NAT auf Sophos Firewall verstehen, weil eine NAT-Regel keinen Traffic erlaubt, sondern nur Adressen oder Ports übersetzt.

Schritt 7: Logdateien prüfen

Wenn WebAdmin-Werkzeuge nicht reichen, sollten die passenden Logdateien geprüft werden.

Typische Dateien:

• Firewall-Regel: firewall_rule.log
• NAT: nat_rule.log
• Firewall-Verbindungen: fwlog.log
• IPS und DPI: ips.log
• Web Proxy: awarrenhttp.log
• IPsec: strongswan.log, charon.log
• SSL VPN: sslvpn.log
• DNS: dnsd.log, dnsgrabber.log
• DHCP: dhcpd.log

Welche Logdatei zu welchem Modul gehört, ist in Sophos Firewall Troubleshooting: Services und Logs zusammengefasst.

Bei Supportfällen ist ein Logarchiv oder CTR nur dann wirklich hilfreich, wenn der Testzeitpunkt und die erwarteten IDs dokumentiert sind. Ein grosses Logpaket ohne Source, Destination, Port, Benutzer, Rule ID und NAT ID führt oft nur zu längeren Rückfragen.

Beispiel: LAN zu WAN Webregel testen

1. Firewall-Regel LAN_to_WAN_Clients erstellen.
2. Logging aktivieren.
3. Services auf HTTP und HTTPS setzen.
4. Web Policy auswählen.
5. Block QUIC protocol aktiviert lassen.
6. Scan HTTP and decrypted HTTPS aktivieren.
7. SSL/TLS inspection rule für die Testgruppe erstellen.
8. CA-Zertifikat auf dem Testclient installieren.
9. Regelzähler zurücksetzen.
10. Website öffnen.
11. Log Viewer nach Source IP filtern.
12. Policy tester für dieselbe URL ausführen.
13. Bei Abweichung Packet Capture starten.

So sieht man, ob die Regel matcht, ob HTTPS wirklich entschlüsselt wird und ob Webfilter, IPS oder Application Control eingreifen.

Testergebnis dokumentieren

Nach einem Regeltest sollte das Ergebnis kurz dokumentiert werden. Das ist besonders wichtig, wenn ein Supportfall, ein Wartungsfenster oder eine spätere Regelbereinigung daraus entsteht.

Sinnvoll sind:

• Datum und Uhrzeit des Tests
• Source IP, Benutzer, Destination, Service und getestete URL oder Anwendung
• erwartete und tatsächlich gematchte Firewall Rule ID
• NAT Rule ID, falls NAT beteiligt ist
• Action im Log Viewer
• Screenshot oder Export aus Packet Capture, wenn der Paketfluss relevant war
• geänderte Regel, Web Policy, SSL/TLS inspection rule oder NAT-Regel
• offener Punkt, falls das Verhalten noch nicht vollständig erklärt ist

Bei produktiven Änderungen sollte man zusätzlich notieren, ob die Regel nur für einen Pilot, dauerhaft oder als temporärer Workaround gedacht ist. Temporäre Testregeln sollten ein Ablaufdatum oder einen klaren Owner haben, damit sie nicht als Altlast im Regelwerk bleiben.

Wenn aus dem Regeltest ein Supportfall entsteht, sollten zusätzlich Logarchiv, Packet Capture oder tcpdump-PCAP, betroffener Zeitraum und bereits ausgeschlossene Ursachen dokumentiert werden. Für diesen Teil passt Sophos Firewall Logs für Support und Analyse sichern.

FAQ