Sophos Firewall-Regel greift nicht: Ursachen prüfen

Wenn eine Firewall-Regel nicht greift, ist selten die Firewall „kaputt“. Meist passt eine Bedingung nicht, eine allgemeinere Regel steht darüber, NAT verändert die Sicht auf den Traffic, User Matching ist nicht erfüllt oder Logging ist nicht sauber aktiviert.

Diese Checkliste hilft, systematisch vorzugehen, statt zufällig an Regeln zu drehen.

Orientierung

Wenn eine Firewall-Regel nicht greift, sollte man zuerst den Testfall eingrenzen. Danach lässt sich gezielt prüfen, ob das Problem bei Reihenfolge, Matching, NAT, Routing, Authentifizierung oder Logging liegt.

Welcher Artikel passt?

Regelprobleme überschneiden sich schnell mit NAT, Routing, VPN, Device Access oder Security Features. Für die Analyse sollte zuerst klar sein, welche Ebene betroffen ist:

• Firewall-Regel von Grund auf verstehen: Sophos Firewall-Regeln verstehen und richtig konfigurieren.
• Einzelne Verbindung mit Log Viewer, Policy Tester und Packet Capture testen: Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.
• NAT, SNAT, DNAT, MASQ oder PAT ist beteiligt: NAT auf Sophos Firewall verstehen.
• Server wird aus dem Internet per DNAT veröffentlicht: Server per DNAT veröffentlichen.
• Zugriff geht auf WebAdmin, VPN Portal, SSH, DNS oder SNMP der Firewall: Device Access richtig konfigurieren.
• Route, SD-WAN oder Rückweg ist unklar: Routing-Priorität auf Sophos Firewall anpassen.
• Pakete müssen direkt auf der Firewall geprüft werden: Packet Capture im WebAdmin verwenden.

Diese Trennung ist wichtig, weil eine Firewall-Regel nicht jede Art von Zugriff steuert. Lokale Dienste der Firewall, NAT-Entscheidungen, Routing und Security Features haben eigene Prüfstellen.

Schnelle Eingrenzung

Am Anfang sollte man nicht sofort Regeln verschieben oder Objekte ändern. Zuerst wird eingegrenzt, an welcher Stelle der Traffic verloren geht.

• Regelzähler bleibt 0: Regelposition, Zone, Source, Destination, Service oder Schedule passt nicht.
• Log Viewer zeigt eine andere Regel: Eine allgemeinere oder automatisch erzeugte Regel steht weiter oben.
• Log Viewer zeigt gar nichts: Logging fehlt oder der Traffic erreicht die Firewall nicht.
• Packet Capture sieht kein Paket: Das Problem liegt vor der Firewall, zum Beispiel Client, VLAN, Switch, Gateway, Provider oder Cloud Security Group.
• Packet Capture sieht Pakete, aber keinen Forward: Firewall-Regel, NAT, Routing oder Security Feature blockiert.
• Packet Capture sieht Forward, aber keine Antwort: Rückroute, Zielsystem, NAT oder externe Firewall prüfen.

Diese Trennung spart Zeit. Wenn die Firewall kein Paket sieht, hilft keine Änderung an einer Firewall-Regel. Wenn der Log Viewer eine andere Rule ID zeigt, ist die Reihenfolge wichtiger als die betroffene Zielregel. Wenn Paketfluss und Rule ID stimmen, verschiebt sich die Analyse zu NAT, Rückweg oder Security Features.

Testfall sauber definieren

Eine Regel kann nur sinnvoll geprüft werden, wenn der Testfall eindeutig ist. Aussagen wie “Internet geht nicht” oder “VPN geht nicht” sind zu breit. Für die Fehlersuche braucht es einen konkreten Flow.

Vor dem Test sollte feststehen:

• Source IP: Client 10.10.20.35.
• Source zone: LAN, VPN, DMZ oder benutzerdefinierte Zone.
• User: authentifizierter Benutzer oder kein User Matching.
• Destination: Server-IP, FQDN, öffentliche IP oder WAN-Objekt.
• Service: TCP 443, UDP 53, ICMP oder benutzerdefinierter Service.
• Erwartete Regel: Regelname oder Rule ID, falls bekannt.
• Erwartete NAT-Regel: NAT Rule ID oder Regelname, falls NAT beteiligt ist.
• Testzeit: exakte Uhrzeit für Log Viewer und spätere Logdateien.

Danach wird immer derselbe Test wiederholt. Wenn während der Analyse Source-IP, Ziel, DNS-Auflösung oder Port wechseln, vergleicht man nicht mehr denselben Fall.

Analysewerkzeuge richtig kombinieren

Sophos Firewall bietet mehrere Werkzeuge, die unterschiedliche Fragen beantworten. Keines davon ist allein ein vollständiger Beweis.

• Regelzähler: Zeigt, ob neuer Testtraffic die Regel grundsätzlich trifft. Er erklärt aber nicht, warum eine Anwendung trotzdem scheitert.
• Log Viewer: Zeigt Rule ID, NAT Rule ID, Action, User oder protokollierte Security-Funktionen. Die Aussage hängt von Logging und Session-Ende ab.
• Policy Tester: Zeigt, welche Policy-Logik für einen definierten Flow greifen würde. Er ersetzt keinen echten Paketfluss und bildet SD-WAN nicht vollständig ab.
• Packet Capture: Zeigt, ob Pakete ankommen, weitergeleitet oder verworfen werden. Die Ausgabe erklärt nicht jede Anwendungsebene und braucht enge Filter.
• Service-Logs: Zeigen, ob ein Modul wie Web, IPS, Authentifizierung oder VPN ein eigenes Problem hat. Sinnvoll ist das erst, wenn der betroffene Dienst eingegrenzt ist.

Für einen belastbaren Befund kombiniert man mindestens Log Viewer und einen echten Test. Bei widersprüchlichen Ergebnissen ist Packet Capture meistens der nächste Schritt, weil es zeigt, ob Pakete tatsächlich ankommen und weiterlaufen.

Entscheidungsbaum für den ersten Test

Für die erste Analyse reicht oft ein kurzer Entscheidungsbaum. Er verhindert, dass man sofort an Regeln, NAT und Routing gleichzeitig arbeitet.

• Packet Capture sieht kein Paket: Client, VLAN, Switch, Gateway, Provider, Cloud Security Group oder vorgeschaltete Firewall prüfen.
• Packet Capture sieht Paket, Log Viewer bleibt leer: Logging, Logtyp, Session-Ende und passenden BPF-Filter prüfen.
• Log Viewer zeigt andere Rule ID: Regelreihenfolge, Zonen, Source, Destination, Service und Schedule vergleichen.
• Firewall Rule ID passt, NAT Rule ID passt nicht: NAT-Reihenfolge und Original-Felder prüfen.
• Rule ID und NAT ID passen, aber keine Antwort kommt zurück: Rückroute, Zielsystem, lokale Firewall auf dem Server oder externe Blockade prüfen.
• Regel matcht nur bei bestimmten Benutzern nicht: User Matching, Gruppe, Authentifizierung und Clientless User prüfen.

Damit bleibt die Analyse kontrolliert: Erst wird bewiesen, ob der Traffic die Firewall erreicht. Danach wird geprüft, welche Regel und welche NAT-Regel wirklich greifen. Erst wenn diese beiden Punkte stimmen, lohnt sich die Suche bei Rückweg, Security Features oder Anwendungsebene.

Regel-Matching verstehen

Die Sophos Firewall prüft Regeln von oben nach unten. Eine Regel greift nur, wenn alle relevanten Felder zum Paket passen und keine passendere Regel vorher den Traffic übernimmt.

Erstes Prinzip: Die erste passende Regel gewinnt

Sophos Firewall verarbeitet Firewall-Regeln von oben nach unten. Sobald eine Regel passt, werden nachfolgende Regeln nicht mehr geprüft. Dasselbe Grundprinzip gilt auch für NAT-Regeln.

Wichtig:

• Die Position in der Liste entscheidet über die Auswertung.
• Die Rule ID ist nur eine Referenz und sagt nichts über die aktuelle Reihenfolge aus.
• Regelgruppen helfen bei der Übersicht, sind aber keine eigene Match-Logik.
• Eine allgemeine Regel oberhalb kann eine spezifische Regel darunter vollständig „schlucken“.

Wenn eine Regel nicht greift, prüft man deshalb zuerst die Position.

Regelzähler zurücksetzen

Bei unklaren Treffern hilft es, den Regelzähler zurückzusetzen.

1. Rules and policies > Firewall rules öffnen.
2. Die betroffene Regel suchen.
3. Das Drei-Punkte-Menü öffnen.
4. Reset data transfer count auswählen.
5. Den Traffic erneut reproduzieren.
6. Den Zähler nach dem Test kontrollieren.

Wenn der Zähler nicht steigt, matcht die Regel nicht. Wenn er steigt, aber die Anwendung trotzdem nicht funktioniert, liegt das Problem eher bei Security Profiles, NAT, Routing, Rückweg oder Zielsystem.

Matching-Felder prüfen

Eine Firewall-Regel matcht nur, wenn alle relevanten Kriterien passen.

• Source zones: Falsche Zone, VLAN liegt in anderer Zone oder VPN-Traffic kommt aus VPN.
• Source networks and devices: Falsches Objekt, falsche IP oder Host-Gruppe unvollständig.
• Destination zones: Falsche Zielzone, besonders bei DNAT oder VPN.
• Destination networks: Vor-NAT- und Nach-NAT-Sicht verwechselt.
• Services: Port fehlt, TCP/UDP verwechselt oder Anwendung nutzt Zusatzports.
• Users or groups: Benutzer ist nicht authentifiziert oder in der falschen Gruppe.
• Schedule: Zeitplan passt aktuell nicht.
• Exclusions: Traffic wird aus der Regel ausgenommen und darunter weiterverarbeitet.

Bei Webtraffic sollte man zusätzlich prüfen, ob QUIC aktiv ist. Wenn Browser Traffic über UDP 443 senden, greifen manche Webfilter- und Scanning-Erwartungen anders als bei klassischem HTTPS über TCP.

Mehr dazu: Sophos Firewall und das QUIC-Protokoll.

DNS, FQDN und IPv6 nicht übersehen

Eine Regel kann korrekt aussehen und trotzdem nicht matchen, wenn der Client ein anderes Ziel erreicht als erwartet. Das passiert häufig bei FQDN-Objekten, Split DNS, CDN-Diensten, IPv6 oder Anwendungen, die mehrere Ziele parallel verwenden.

Vor Regeländerungen sollte man deshalb prüfen:

• Welche IP löst der Client wirklich auf? DNS-Cache, Split DNS oder ein anderer Resolver können eine andere Adresse liefern als erwartet.
• Ist es IPv4 oder IPv6? IPv4-Regeln matchen keinen IPv6-Traffic. Wenn Clients IPv6 bevorzugen, muss die IPv6-Seite separat geprüft werden.
• Wird ein FQDN Host in der Firewall verwendet? Die Firewall muss den FQDN auflösen und die aktuelle Ziel-IP kennen. CDN- oder Cloud-Dienste können mehrere wechselnde IPs liefern.
• Verwendet die Anwendung zusätzliche Ziele? Login, API, Updates, Telemetrie oder Medienpfade können andere Domains und Ports nutzen als die Hauptanwendung.
• Nutzt ein interner Client den öffentlichen Namen eines internen Dienstes? Dann sind Split DNS, Loopback NAT oder eine falsche öffentliche Auflösung mögliche Ursachen.

Für die Fehlersuche ist entscheidend, nicht nur den Hostnamen zu notieren, sondern die tatsächlich verwendete Ziel-IP im Log Viewer oder Packet Capture zu vergleichen. Wenn eine Regel auf ein bestimmtes FQDN- oder Host-Objekt zeigt, der Client aber eine andere IP verwendet, wird die Regel nicht matchen.

Bei internen Namensauflösungen helfen saubere DNS request routes. Der Ablauf steht in DNS Request Routes auf Sophos Firewall einrichten. Wenn IPv6 in der Umgebung aktiv ist, sollte man zusätzlich prüfen, ob IPv6 bewusst geplant und die passende Policy vorhanden ist. Grundlagen dazu stehen in IPv6 Prefix Delegation auf Sophos Firewall einrichten.

Ein häufiger Sonderfall sind FQDN-Objekte. Wenn Clients IPv6 bevorzugen, eine Regel aber nur IPv4-Objekte oder einen FQDN-Host mit IPv4-Auflösung verwendet, matcht der tatsächliche IPv6-Flow nicht. Dann sieht die Regel fachlich richtig aus, verarbeitet aber nicht den Traffic, der wirklich auf dem Draht liegt. In solchen Fällen sollten DNS-Antwort, IP-Version und Policy getrennt geprüft werden.

Traffic zur Firewall selbst ist ein Sonderfall

Nicht jeder Zugriff auf eine Sophos Firewall wird über normale Firewall-Regeln gesteuert. Wenn der Client die Firewall selbst erreichen soll, zum Beispiel WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS oder SNMP, sind Device Access und Local service ACL entscheidend.

Typische Beispiele:

• WebAdmin aus LAN oder WAN: Device Access, Local service ACL, MFA und Admin-Berechtigung.
• VPN Portal oder User Portal: Device Access, Portal-Konfiguration und Benutzerberechtigung.
• SSH auf die Firewall: Device Access, Local service ACL, Admin-Rechte und Quellnetz.
• SSL VPN oder IPsec-Einwahl: Device Access für die passende Zone, VPN-Konfiguration und Authentifizierung.
• DNS zur Firewall: Device Access, DNS-Konfiguration und Anfragepfad.
• SNMP zur Firewall: Device Access, SNMP-Konfiguration und Monitoring-Quelle.

Wenn eine Firewall-Regel für solchen Traffic nicht greift, ist das oft kein Fehler der Regel. Der Traffic endet auf der Firewall und wird als lokaler Dienst behandelt. Für die Härtung dieser Dienste ist Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren der zentrale Artikel. Für Portale passt zusätzlich Sophos Portale im Überblick.

NAT, DNAT und IDs prüfen

Bei DNAT-Problemen muss man NAT-Regel und Firewall-Regel gemeinsam lesen. Besonders wichtig sind Firewall Rule ID, NAT Rule ID und die unterschiedliche Sicht auf ursprüngliche und übersetzte Ziele.

DNAT richtig lesen

Bei DNAT ist die Sicht in Firewall-Regeln besonders wichtig. Als Faustregel kann man sich merken:

Firewall-Regeln für DNAT-Traffic verwenden die Zielzone nach NAT, aber die Ziel-IP vor NAT.

Beispiel:

• Externer Client verbindet sich auf die WAN-IP der Firewall.
• NAT übersetzt auf einen internen Server in der DMZ.
• Die Firewall-Regel verwendet als Destination zone die Zone des internen Servers, also zum Beispiel DMZ.
• Das Destination network bleibt aber die öffentliche IP oder das WAN-Objekt, das der Client angesprochen hat.

Wenn diese Kombination falsch ist, sieht die NAT-Regel vielleicht korrekt aus, die Firewall-Regel matcht aber trotzdem nicht.

Mehr dazu: Server per DNAT auf Sophos Firewall veröffentlichen.

NAT-Regeln prüfen

NAT erlaubt keinen Traffic. NAT übersetzt nur. Es braucht immer zusätzlich eine passende Firewall-Regel.

Unter Rules and policies > NAT rules sollte man prüfen:

• Steht die passende NAT-Regel oberhalb allgemeinerer NAT-Regeln?
• Ist die Regel aktiv?
• Stimmen Original source, destination und service?
• Stimmen Translated source, destination und service?
• Wird MASQ oder eine feste SNAT-IP verwendet?
• Gibt es eine Linked NAT Rule, die unerwartet greift?
• Gibt es eine generische SNAT-Regel, die vor einer spezifischeren Regel matcht?

Für einfache Umgebungen sind eigenständige NAT-Regeln meistens übersichtlicher als eine Linked NAT Rule pro Firewall-Regel.

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

Firewall Rule ID und NAT Rule ID zusammen lesen

Wenn NAT beteiligt ist, reicht die Frage “Welche Firewall-Regel greift?” nicht aus. Eine Verbindung kann die erwartete Firewall Rule ID treffen, aber trotzdem über eine falsche NAT Rule ID laufen. Umgekehrt kann eine NAT-Regel korrekt aussehen, während eine allgemeinere Firewall-Regel oberhalb den Traffic bereits verarbeitet.

Für den Test sollte man deshalb vorab notieren:

• Erwartete Firewall Rule ID: Zeigt, ob die richtige Firewall-Regel den Traffic erlaubt oder blockiert.
• Erwartete NAT Rule ID: Zeigt, ob die richtige SNAT-, DNAT-, MASQ- oder PAT-Regel übersetzt.
• Tatsächliche IDs im Log Viewer: Belegt, ob die Firewall den Flow so verarbeitet wie geplant.
• IDs im Packet Capture: Hilft, wenn der Log Viewer unvollständig wirkt oder der Rückweg unklar ist.

Die Interpretation ist relativ einfach, spart aber viel Suchzeit:

• Firewall Rule ID passt, NAT Rule ID ist falsch: NAT-Reihenfolge, Original-Felder und allgemeinere NAT-Regeln prüfen.
• NAT Rule ID passt, Firewall Rule ID ist falsch: Firewall-Regelreihenfolge, Zonen, Source, Destination und Service prüfen.
• Beide IDs passen, Verbindung scheitert trotzdem: Rückweg, Zielserver, Security Feature oder Anwendung prüfen.
• Keine NAT Rule ID sichtbar, obwohl NAT erwartet wird: Testflow, NAT-Kriterien, Richtung und Logging erneut prüfen.

Wichtig ist, nicht sofort beide Regelwerke gleichzeitig umzubauen. Zuerst wird entschieden, ob das Problem im Firewall-Matching oder im NAT-Matching liegt. Erst danach sollte man eine konkrete Regelposition, ein Objekt oder ein Feld ändern. Die ausführlichere NAT-Auswertung steht im Abschnitt Firewall Rule ID und NAT Rule ID richtig lesen.

Benutzer, Routing und Security Features prüfen

Wenn Reihenfolge und Matching korrekt aussehen, liegen Fehler oft bei Benutzererkennung, Routing, SD-WAN, fehlendem Logging oder einem aktivierten Security Feature.

User Matching und Authentifizierung prüfen

Regeln mit Benutzer- oder Gruppenmatching sehen oft korrekt aus, greifen aber nur, wenn die Firewall den Benutzer in diesem Moment auch wirklich dem Traffic zuordnen kann.

Zu prüfen:

• Ist der Benutzer im Log Viewer sichtbar?
• Kommt der Traffic vom erwarteten Gerät oder von einem anderen Client?
• Ist der Benutzer in der richtigen Firewall-Gruppe?
• Funktioniert AD SSO, STAS, Captive Portal, RADIUS oder Entra ID SSO?
• Greift eine Regel ohne User Matching oberhalb der geplanten Benutzerregel?
• Gibt es Clientless Users, die anders behandelt werden?
• Ist MFA oder Portalzugriff zwar erfolgreich, aber die Firewall-Regel für den eigentlichen Nutztraffic falsch?

Bei Remote Access sollte man Benutzerproblem und VPN-Problem trennen. Ein Benutzer kann sich erfolgreich anmelden, aber trotzdem keine interne Anwendung erreichen, wenn VPN-Pool, Firewall-Regel, NAT oder Routing nicht passen. Für AD-Grundlagen passt Active Directory auf Sophos Firewall hinzufügen, für Entra-basierte Remote-Access-Szenarien Microsoft Entra ID SSO für Sophos Connect und VPN Portal. Wenn der Benutzer über Captive Portal mit Entra ID SSO angemeldet wird, passt Microsoft Entra ID SSO für Sophos Firewall Captive Portal einrichten.

Benutzer-Login und Regel-Matching trennen

Ein erfolgreicher Login am VPN Portal, User Portal, Captive Portal oder über Microsoft Entra ID SSO beweist noch nicht, dass die geplante Benutzerregel den eigentlichen Traffic matcht. Der Login bestätigt zuerst nur die Authentifizierung. Danach muss die Firewall den Benutzer, die Quell-IP, die Gruppe und den Traffic-Flow korrekt zusammenbringen.

Für die Analyse sollte man deshalb getrennt prüfen:

• Benutzer meldet sich an, Regelzähler bleibt 0: VPN-Pool, Source zone, Source network, Gruppenbedingung oder Regelposition prüfen.
• User-Feld im Log Viewer ist leer: STAS, Captive Portal, AD SSO, Entra ID SSO oder Clientless User prüfen.
• Benutzer ist sichtbar, aber falsche Regel greift: Regelreihenfolge, Gruppenfilter oder allgemeinere Regel oberhalb prüfen.
• Nur VPN-Benutzer sind betroffen: Zone VPN, VPN-Pool, SSL/IPsec-Konfiguration und Sophos Connect Profil prüfen.
• Nur einzelne Benutzer sind betroffen: UPN, E-Mail-Adresse, importierte Gruppe und Firewall-Gruppe vergleichen.

Bei lokalen AD-Umgebungen helfen STAS und Active Directory auf Sophos Firewall hinzufügen. Bei Entra-basierten Setups sollte man je nach Loginpfad Microsoft Entra ID SSO für Sophos Connect und VPN Portal oder Entra ID SSO für Captive Portal mitprüfen. Wenn sehr viele Benutzer oder Clientless Users beteiligt sind, kann zusätzlich das Sophos Firewall User-ID-Limit relevant werden.

Routing und SD-WAN prüfen

Wenn die Regel matcht, aber die Verbindung nicht funktioniert, kann Routing das Problem sein.

Dabei prüft man:

• Gibt es eine passende Standardroute?
• Gibt es eine statische Route?
• Greift eine SD-WAN route?
• Ist das Gateway aktiv?
• Gibt es Rückrouten auf dem Zielsystem oder im entfernten Netz?
• Ist der Rückweg symmetrisch?
• Geht Traffic über VPN, MPLS oder ein anderes Interface als erwartet?

Wichtig: Der Policy Tester bildet SD-WAN-Routing nicht vollständig ab. Er ist sehr hilfreich für Firewall-, SSL/TLS- und Web-Policy-Entscheidungen, ersetzt aber keinen echten Paketfluss-Test.

Mehr dazu: Routing-Priorität auf Sophos Firewall anpassen.

Logging aktivieren

Ohne Logs wird Troubleshooting mühsam. Man prüft zwei Stellen:

1. In der Firewall-Regel muss Log firewall traffic aktiviert sein.
2. Unter System services > Log settings muss der passende Logtyp lokal, für Sophos Central oder für Syslog aktiviert sein.

Der Log Viewer zeigt Firewall-Sessions typischerweise, wenn die Firewall eine Verbindung beendet und ein Destroy-Event erhält. Wenn eine Internetverbindung einfach abreisst, kann es sein, dass nicht jede Session so erscheint, wie man es erwartet.

Den Log Viewer öffnet man oben rechts in der WebAdmin-Konsole. Sinnvolle Filter sind:

• Source IP
• Destination IP
• Port oder Service
• Rule ID
• Rule name
• Action
• User
• NAT rule ID

Mehr dazu: Sophos Firewall Troubleshooting: Services und Logs.

Packet Capture verwenden

Wenn Log Viewer und Regelzähler nicht reichen, verwendet man Diagnostics > Packet capture.

Die wichtigste Frage ist, ob das Paket ankommt, weitergeleitet wird oder bereits auf der Firewall hängen bleibt.

• Kein Paket kommt an: Das Problem liegt vor der Firewall, zum Beispiel Client, Switch, VLAN, Gateway, Provider oder Cloud Security Group.
• Paket kommt rein, geht aber nicht raus: Firewall-Regel, NAT, Routing oder Security Feature prüfen.
• Paket geht raus, aber keine Antwort kommt zurück: Rückroute, Zielsystem, NAT oder externe Blockade prüfen.
• Paket wird mit Violation angezeigt: Policy oder Security Feature blockiert.
• Paket zeigt NAT ID und Rule ID: Regel- und NAT-Treffer gezielt vergleichen.

Mehr dazu: Packet Capture Tool im WebAdmin verwenden.

Nicht mehrere Dinge gleichzeitig ändern

Bei Regelproblemen ist es verlockend, Position, Service, NAT, Web Policy und Routing gleichzeitig anzupassen. Das löst manchmal kurzfristig den Zugriff, macht die Ursache aber später schwer nachvollziehbar.

Besser ist ein Schritt-für-Schritt-Vorgehen:

1. Ausgangszustand notieren: Rule ID, NAT ID, Source, Destination, Service, Uhrzeit.
2. Genau eine Änderung durchführen.
3. Test mit derselben Source IP und demselben Ziel wiederholen.
4. Log Viewer und Packet Capture erneut vergleichen.
5. Ergebnis dokumentieren.
6. Erst danach die nächste Änderung prüfen.

Für produktive Regeln sollte ausserdem klar sein, ob eine Änderung dauerhaft ist oder nur als Testregel dient. Temporäre Regeln sollten einen Owner und ein Ablaufdatum haben, sonst bleiben sie oft jahrelang im Regelwerk.

Security Features einzeln prüfen

Wenn die Regel matcht, aber die Anwendung nicht funktioniert, kann ein Schutzprofil eingreifen:

• Web Policy
• SSL/TLS inspection rule
• Decryption Profile
• IPS Policy
• Application Control
• Malware Scan
• Zero-day protection
• Security Heartbeat
• Traffic Shaping

Für Tests kann man nicht pauschal alles dauerhaft deaktivieren. Besser ist: kurz gezielt prüfen, Log Viewer beobachten und danach die Ursache sauber beheben. Bei TLS Inspection hilft der Artikel TLS Inspection auf Sophos Firewall schrittweise ausrollen.

Bei produktiven Regeln sollte man Security Features nicht als Sammelblock betrachten. Besser ist, ein Modul nach dem anderen einzugrenzen:

• Webkategorie oder URL wird blockiert: Web Policy, Kategorie, Ausnahme und Log Viewer prüfen.
• Anwendung wird falsch erkannt: Application Control und IPS-Log prüfen.
• HTTPS-Seite lädt nur ohne Inspection: SSL/TLS inspection rule, CA-Verteilung, Decryption Profile und Ausnahmen prüfen.
• Verbindung bricht bei grossen Daten ab: MTU/MSS, VPN-Pfad, Fragmentierung und Packet Capture prüfen.
• Treffer in IPS oder Zero-day Protection: Signatur, Policy, Zielsystem und False-Positive-Risiko bewerten.
• Nur einzelne Benutzer betroffen: User Matching, Security Heartbeat, Gruppe und Authentifizierung prüfen.

Wenn für einen Test ein Schutzprofil entfernt wird, sollte die Änderung eng begrenzt sein: nur die betroffene Source, nur das konkrete Ziel, nur für den Testzeitraum. Danach wird die ursprüngliche Schutzwirkung wiederhergestellt oder eine gezielte Ausnahme dokumentiert.

Änderungshistorie prüfen

Wenn eine Regel gestern noch funktioniert hat und heute nicht mehr, sollte nicht nur der aktuelle Regelinhalt geprüft werden. Häufig wurde kurz vorher ein Objekt, eine Regelposition, eine NAT-Regel, eine Gruppe, ein Service oder eine Central-Policy geändert.

Praktische Prüfpunkte:

• Firewall-Regel selbst geändert? Audit Trail, Config Studio und Regelbeschreibung prüfen.
• Verwendetes Objekt angepasst? Hosts and services, Audit Trail und Config Studio prüfen.
• Regelposition verschoben? Firewall-Regelliste und Audit Trail prüfen.
• Central-Policy übertragen? Sophos Central Task Queue und lokale Firewall-Ansicht prüfen.
• NAT-Regel oder SD-WAN-Route verändert? NAT-Regeln, Routing, Audit Trail und Packet Capture prüfen.

Für die Nachvollziehbarkeit passen Sophos Firewall Audit Trail Logs prüfen und Sophos Firewall Config Studio nutzen. Wenn die Änderung aus Sophos Central kommt, sollte zusätzlich die Sophos Central Firewall Management Task Queue geprüft werden.

Praktischer Ablauf und typische Ursachen

Der schnellste Weg ist ein ruhiger Ablauf: erst Log Viewer, dann Regelzähler, dann NAT, Routing, Benutzer und Packet Capture. So vermeidet man, mehrere Fehler gleichzeitig zu verändern.

Häufige Ursachen

• Regelzähler bleibt 0: Regelposition, Source zone, Destination zone oder Service falsch.
• Log zeigt andere Regel: Eine allgemeinere Regel steht darüber.
• Kein Log sichtbar: Logging ist nicht aktiv oder Traffic erreicht die Firewall nicht.
• DNS funktioniert, Web nicht: Service, Web Policy, TLS Inspection oder QUIC prüfen.
• Hostname passt, aber Ziel-IP anders: DNS, FQDN-Objekt, Split DNS, CDN oder IPv6 prüfen.
• HTTPS wird nicht gescannt: Keine passende SSL/TLS inspection rule oder CA nicht verteilt.
• DNAT funktioniert nicht: Firewall-Regel nutzt falsche Destination zone oder falsches Destination network.
• VPN-Traffic matcht nicht: Zone VPN, Route, Tunnelinterface oder XFRM-Kontext prüfen.
• Nur einige Benutzer betroffen: User Matching, Gruppe, SSO, Captive Portal oder Heartbeat prüfen.

Praktischer Ablauf

1. Problem mit Source IP, Destination, Port, User und Uhrzeit notieren.
2. Regelposition prüfen.
3. Regelzähler zurücksetzen.
4. Test reproduzieren.
5. Log Viewer mit Source IP und Destination IP filtern.
6. NAT-Regel und Routing prüfen.
7. Packet Capture mit engem Filter starten.
8. Security Profile nur gezielt prüfen.
9. Änderung dokumentieren.

Für einen kombinierten Testablauf siehe Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Checkliste für Regel-Troubleshooting

• Konkreter Testfall mit Source, Destination, Service, User und Uhrzeit definiert.
• Regelposition geprüft und Regelzähler für den Test zurückgesetzt.
• Log Viewer zeigt die erwartete Rule ID oder eine nachvollziehbare andere Regel.
• DNS-Auflösung, tatsächliche Ziel-IP und IP-Version wurden mit dem Testfall abgeglichen.
• Bei DNAT sind Zielzone nach NAT und Destination network vor NAT korrekt gesetzt.
• NAT Rule ID wurde geprüft, wenn NAT beteiligt ist.
• Traffic zur Firewall selbst wurde von Traffic durch die Firewall getrennt.
• User Matching wurde nur bewertet, wenn der Benutzer im Log Viewer sichtbar ist.
• Bei Benutzerregeln wurden Login, Benutzerzuordnung und eigentliche Regelentscheidung getrennt bewertet.
• Routing, SD-WAN, Gateway und Rückweg wurden geprüft.
• Packet Capture zeigt Incoming, Forwarded, Violation oder fehlende Antwort nachvollziehbar.
• Security Features wurden einzeln geprüft und nicht dauerhaft pauschal deaktiviert.
• Teständerungen sind dokumentiert und temporäre Regeln haben Owner und Ablaufdatum.

FAQ