Sophos Firewall-Regel greift nicht: Ursachen prüfen

Wenn eine Sophos Firewall-Regel nicht greift, sollte man nicht als Erstes Regeln verschieben oder Objekte erweitern. Zuerst wird ein einzelner Datenfluss reproduziert und beobachtet: Kommt das Paket an, welche Firewall Rule ID und NAT Rule ID verarbeitet es, wird es weitergeleitet und kommt eine Antwort zurück?

Meist zeigt sich dabei, dass eine Bedingung anders aussieht als erwartet, eine allgemeinere Regel weiter oben greift oder das Problem erst nach der Regelentscheidung entsteht. Die Firewall selbst ist deutlich seltener die Ursache als ein ungenau definierter Test.

Schnellentscheidung: Zeigt ein korrekt gestartetes und gefiltertes Packet Capture kein Paket, prüft man zuerst Client, VLAN, Gateway oder den vorgeschalteten Pfad. Eine andere Rule ID führt zu Reihenfolge und Matching. Stimmen Rule ID und NAT ID, geht die Analyse zu Routing, Rückweg, Zielsystem oder Security-Modul weiter.

Schnellweg: einen konkreten Flow verfolgen

Für die erste Eingrenzung reichen sechs Schritte:

1. Testflow festlegen: Source IP, Source zone, User, Destination, Protokoll, Port und Uhrzeit notieren.
2. Eingang beweisen: Packet Capture mit engem Capture-Filter starten und denselben Flow auslösen.
3. Firewall Rule ID prüfen: Im Log Viewer oder Packet Capture mit der erwarteten Regel vergleichen.
4. NAT Rule ID prüfen: Wenn NAT beteiligt ist, die tatsächliche NAT-Regel und ihre Übersetzung kontrollieren.
5. Weiterleitung und Antwort prüfen: Forwarded, Ausgangsinterface und Rückpakete suchen.
6. Erst danach tiefer gehen: Routing, SD-WAN, User Matching, TLS Inspection, IPS, Web Policy oder Zielsystem untersuchen.

Dieser Ablauf hält die Ebenen auseinander. Eine Firewall-Regel entscheidet über Zugriff und Schutzfunktionen, NAT übersetzt Adressen oder Ports, Routing wählt den weiteren Pfad und das Zielsystem muss den Rückweg kennen. Werden alle Ebenen gleichzeitig geändert, verschwindet zwar manchmal das Symptom, die Ursache bleibt aber unklar.

Zielt der Test auf WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP oder einen anderen Dienst der Firewall selbst, gelten nicht dieselben Regeln wie für Durchgangstraffic. In diesem Fall führt der Diagnoseweg direkt zu Administration > Device access und zur Local Service ACL.

Einen reproduzierbaren Testfall definieren

Eine Aussage wie „Internet geht nicht“ oder „die VPN-Regel greift nicht“ ist zu breit. Ein brauchbarer Testfall sieht beispielsweise so aus:

• Source IP: 10.10.20.35
• Source zone: LAN
• User: admin@example.com oder bewusst kein User Matching
• Destination: app.example.net, aktuell aufgelöst zu 203.0.113.20
• Service: TCP 443
• Erwartete Firewall-Regel: LAN-App-HTTPS, Rule ID 37
• Erwartete NAT-Regel: NAT Rule ID 12 oder ausdrücklich keine NAT-Regel
• Testzeit: 2026-08-08 10:15:00

Die IP-Adressen, IDs, Namen und Uhrzeit sind Beispielwerte und werden durch die Werte der eigenen Umgebung ersetzt. Wichtig ist die Form: Während der Diagnose bleiben Source, Ziel-IP, Port und Benutzer gleich. Wenn zwischendurch DNS-Auflösung, Client oder Anwendung wechseln, vergleicht man nicht mehr denselben Flow.

Die ersten Beobachtungen einordnen

• Aktives Packet Capture zeigt trotz passendem Filter kein Paket: Zuerst Capture-Status, Filter und Puffer prüfen. Sind diese korrekt, liegt die Ursache wahrscheinlich vor der Firewall, etwa bei Client, VLAN, Switch, Gateway, Provider oder Cloud Security Group.
• Log Viewer zeigt eine andere Rule ID: Eine allgemeinere, automatisch erzeugte oder anders passende Regel wird früher ausgewertet.
• Firewall Rule ID stimmt, NAT Rule ID nicht: NAT-Reihenfolge sowie Original source, destination und service prüfen.
• Rule ID und NAT ID stimmen, aber kein Forwarded ist sichtbar: Regelaktion, Reason, Routing oder ein Security-Modul prüfen.
• Forwarded ist sichtbar, aber keine Antwort kommt: Rückroute, Zielsystem, lokale Server-Firewall oder externe Blockade prüfen.
• Nur bestimmte Benutzer sind betroffen: Authentifizierung und User Matching des tatsächlichen Datenflows getrennt kontrollieren.

Der ausführliche kombinierte Ablauf steht unter Firewall-Regel mit Log Viewer, Policy Tester und Packet Capture testen. Dieser Artikel konzentriert sich darauf, wie man einen unerwarteten Regelmatch erklärt.

Regelreihenfolge und Matching prüfen

Eine Firewall-Regel greift nur, wenn alle relevanten Kriterien passen und keine frühere Regel denselben Traffic bereits verarbeitet.

Die erste passende Regel gewinnt

Sophos Firewall wertet Regeln von oben nach unten aus und beendet die Suche bei der ersten passenden Regel. Die Position in der Liste ist deshalb entscheidend; die Rule ID ist nur eine feste Kennung und entspricht nicht der Position.

Zusätzlich sollte man Folgendes beachten:

• Eine allgemeine Regel oberhalb kann eine spezifische Regel darunter vollständig überdecken.
• Rule Groups verbessern die Übersicht, erzeugen aber keine eigene Match-Logik. Ausgewertet werden die enthaltenen Regeln.
• Automatisch erzeugte Regeln, beispielsweise für MTA, IPsec oder Hotspots, können oben eingefügt und zuerst geprüft werden.
• Ein aktiver Filter in der Regeltabelle kann relevante Regeln ausblenden. Vor der Analyse sollte man Reset filter verwenden.
• Die unveränderbare Default-Drop-Regel hat Rule ID 0, steht am Ende und besitzt keinen normalen Usage Counter. Tabellenfilter gelten für sie nicht.

Wer die Grundlogik einer Regel nochmals vollständig einordnen möchte, findet sie unter Sophos Firewall-Regeln verstehen und richtig konfigurieren.

Alle Match-Kriterien gemeinsam lesen

Eine optisch passende Regel kann an einem einzigen Feld scheitern:

• Source zones: Der Client kommt aus einer anderen Zone, etwa VPN statt LAN, oder das VLAN ist anders zugeordnet.
• Source networks and devices: IP-Objekt, Host-Gruppe oder Subnetz enthält die tatsächliche Source IP nicht.
• Destination zones: Die Zielzone ist falsch, besonders bei DNAT, VPN oder gerouteten Netzen.
• Destination networks: Die tatsächlich angesprochene IP stimmt nicht mit dem Objekt überein oder Vor- und Nach-NAT-Sicht wurden verwechselt.
• Services: Port fehlt, TCP und UDP wurden vertauscht oder die Anwendung öffnet zusätzliche Verbindungen.
• Users or groups: Die Firewall kann den Benutzer nicht der Source IP zuordnen oder die importierte Gruppe stimmt nicht.
• Schedule: Der Zeitplan ist zum Testzeitpunkt nicht aktiv.
• Exclusions: Der Flow wird aus der Regel ausgeschlossen und danach gegen weitere Regeln geprüft.

Bei Webtraffic gehört auch das Protokoll zum Test. Browser können QUIC über UDP 443 verwenden, während die erwartete Regel oder Webprüfung nur klassisches HTTPS über TCP 443 abbildet. Die Auswirkungen erklärt QUIC auf Sophos Firewall kontrollieren.

Übertragenes Datenvolumen kontrolliert zurücksetzen

Der Menüpunkt Reset data transfer count kann beim Test helfen, wird aber häufig falsch interpretiert. Er setzt das über die Regel übertragene Datenvolumen zurück; es handelt sich nicht um einen Session- oder Trefferzähler.

1. Rules and policies > Firewall rules öffnen.
2. Die betroffene Regel suchen und das Drei-Punkte-Menü öffnen.
3. Reset data transfer count auswählen.
4. Den definierten Testflow neu auslösen.
5. Datenvolumen, Rule ID und Packet Capture gemeinsam auswerten.

Steigt der Wert nach dem kontrollierten Test, ist das ein Hinweis auf übertragenen Traffic über diese Regel. Bleibt er unverändert, beweist das allein nicht, dass die Regel nie gematcht hat. Für eine belastbare Aussage werden die tatsächliche Rule ID im Log Viewer und der Paketpfad im Packet Capture geprüft. Bei der Default-Drop-Regel ID 0 steht dieser Datenzähler ohnehin nicht zur Verfügung.

Log Viewer, Policy Tester und Packet Capture richtig lesen

Die Werkzeuge beantworten unterschiedliche Fragen:

• Log Viewer: Welche protokollierte Session, Regel, NAT-Regel, Aktion und welcher Benutzer wurden erkannt?
• Policy Tester: Welche Policy-Logik würde für die eingegebenen Werte greifen?
• Packet Capture: Welche Pakete kommen real an, wie verarbeitet die Firewall sie und gehen sie wieder hinaus?

Keines der Werkzeuge ersetzt die anderen vollständig. Widersprechen sich Simulation und echter Paketfluss, haben Log- und Paketdaten aus dem reproduzierten Test mehr Gewicht.

Log Viewer: tatsächliche Rule ID und NAT Rule ID

In der Firewall-Regel muss Log firewall traffic aktiviert sein. Zusätzlich muss unter System services > Log settings der passende Logtyp für lokale Anzeige, Sophos Central oder Syslog eingeschaltet sein.

Für den Test sind Filter auf folgende Felder hilfreich:

• Source IP und Destination IP
• Port oder Service
• Rule ID und Rule name
• NAT rule ID
• Action und User
• die notierte Testzeit

Ein fehlender Eintrag ist noch kein Beweis, dass die Firewall nichts gesehen hat. Firewall-Sessions werden unter anderem protokolliert, wenn die Verbindung mit einem Destroy-Event endet. Bei abrupten Verbindungsabbrüchen kann der erwartete Eintrag deshalb fehlen oder später erscheinen. Dann liefert Packet Capture den direkteren Befund. Die passenden Dienst- und Logdateien sind unter Sophos Firewall Troubleshooting: Services und Logs beschrieben.

Policy Tester: Policy-Logik ohne echten Paketfluss

Unter Diagnostics > Tools > Policy tester werden URL, User, Zeit, Source IP und Source zone bewusst gesetzt. Protokoll und Port sollten aus der vollständigen URL hervorgehen, beispielsweise https://app.example.net:8443/. Ohne Protokoll testet das Werkzeug HTTP; bei HTTPS wird standardmässig Port 443 verwendet, einen abweichenden Port muss man in der URL angeben.

Der Policy Tester ist nützlich, hat aber klare Grenzen:

• Er erzeugt keinen echten Paketfluss und prüft weder Zielsystem noch Rückweg.
• Die Ergebnisse bilden SD-WAN-Routen nicht ab.
• Regeln mit MAC-Adressen unter Source networks and devices können nicht gematcht werden.
• Provider-, Switch-, Gateway- und Paketverlustprobleme bleiben unsichtbar.

⚠️ Auf SFOS 22.0 GA Build 411 konnten NC-177587 und NC-176083 falsche Policy-Test-Ergebnisse verursachen. Traffic erschien blockiert oder über die falsche Regel gematcht, obwohl er real korrekt floss. MR1 Build 490 enthält die dokumentierten Korrekturen. Bei widersprüchlichen Resultaten zuerst Firmwarestand, Log Viewer und Packet Capture prüfen, bevor produktive Regeln geändert werden.

Packet Capture: den realen Paketpfad prüfen

Unter Diagnostics > Packet capture wird zuerst ein enger BPF-Capture-Filter gesetzt, beispielsweise auf Source IP, Destination IP und Port des Testflows. Danach Trace On aktivieren, die Liste leeren und genau den definierten Flow auslösen.

Ein leeres Packet Capture ist erst aussagekräftig, wenn diese Voraussetzungen erfüllt sind:

1. Trace On ist aktiv.
2. Der BPF-Capture-Filter passt zum realen Ziel und blendet den Flow nicht aus.
3. Der Puffer hat den relevanten Testtraffic nicht bereits überschrieben. Ohne Wrap capture buffer once full stoppt die Aufzeichnung beim vollen 2048-KB-Puffer und wird mit Clear fortgesetzt. Mit aktivierter Wrap-Option läuft die Aufzeichnung weiter und überschreibt die ältesten Pakete.

Ein zusätzlicher Display Filter ändert nicht, was aufgezeichnet wurde, kann vorhandene Einträge aber unsichtbar machen. Deshalb Capture-Filter und Display Filter getrennt kontrollieren.

Die Statuswerte bedeuten:

• Incoming: Das Paket wurde auf einem Interface empfangen.
• Forwarded: Die Firewall leitet das Paket über ein Ausgangsinterface weiter.
• Consumed: Das Paket ist für die Firewall selbst bestimmt oder wird von ihr verwendet.
• Generated: Die Firewall hat das Paket selbst erzeugt.
• Violation: Eine Policy-Verletzung führt zum Drop; das Feld Reason erklärt den Grund näher.

Rule ID, NAT ID, Reason sowie Ein- und Ausgangsinterface werden immer gemeinsam gelesen. Consumed und Generated sind reguläre Ergebnisse und nicht automatisch Fehler.

⚠️ Auf SFOS 22.0 MR1 Build 490 kann NC-178387 Drops durch die Default-Regel ID 0 nur als Incoming zeigen. Der erwartete Violation Firewall-Eintrag und der Eintrag in drppkt fehlen, obwohl die Firewall den Flow weiterhin verwirft. Für diese betroffene Version helfen der Policy Tester oder eine bewusst platzierte, geloggte Drop-Regel am Ende der eigenen Regelliste. Eine Fix-Version ist in der aktuellen Known-Issues-Angabe nicht ausgewiesen.

Ein detaillierter Capture-Ablauf steht unter Packet Capture im Sophos Firewall WebAdmin verwenden. Drops und eine kontrollierte Schlussregel behandelt Sophos Firewall verworfene Pakete analysieren.

NAT, DNAT, Routing und Rückweg prüfen

NAT erlaubt keinen Traffic. Es übersetzt Adressen oder Ports für Traffic, den eine Firewall-Regel erlaubt. Deshalb müssen Firewall Rule ID und NAT Rule ID getrennt stimmen.

Firewall Rule ID und NAT Rule ID zusammen auswerten

• Firewall Rule ID stimmt, NAT Rule ID ist falsch: NAT-Reihenfolge, Original-Felder und allgemeinere NAT-Regeln prüfen.
• NAT Rule ID stimmt, Firewall Rule ID ist falsch: Firewall-Reihenfolge, Zonen, Source, Destination, Service und Schedule vergleichen.
• Beide IDs stimmen, Verbindung scheitert: Routing, Rückweg, Zielserver, Security-Modul oder Anwendung prüfen.
• Keine NAT Rule ID sichtbar, obwohl NAT erwartet wird: Richtung, Inbound/Outbound Interface und die Original-Kriterien der NAT-Regel kontrollieren.

Unter Rules and policies > NAT rules gilt ebenfalls die erste passende Regel. Eine allgemeine SNAT- oder MASQ-Regel kann deshalb eine spezifische Regel darunter überdecken. Linked NAT Rules werden zudem nur für Traffic berücksichtigt, der ihre zugehörige Firewall-Regel matcht; eine frühere eigenständige NAT-Regel kann trotzdem zuerst greifen.

Die vollständige ID-Logik erklärt NAT auf Sophos Firewall verstehen.

DNAT aus Vor- und Nach-NAT-Sicht verstehen

Für eingehenden DNAT-Traffic gilt eine wichtige Faustregel:

Die Firewall-Regel verwendet die Zielzone nach NAT, als Destination Network jedoch die ursprünglich angesprochene Adresse vor NAT.

Beispiel für eine Portweiterleitung:

• Der externe Client verbindet sich mit 198.51.100.10 auf TCP 8888.
• Die NAT-Regel übersetzt auf den Server 10.10.50.20 in der Zone DMZ und auf TCP 4444.
• In der NAT-Regel ist TCP 8888 der Original service und TCP 4444 der Translated service (PAT).
• Die Firewall-Regel verwendet WAN als Source zone, DMZ als Destination zone und 198.51.100.10 als Destination network.
• Im offiziellen Sophos-PAT-Beispiel enthält die zugehörige Firewall-Regel sowohl den Original- als auch den übersetzten Service.

Der externe Test wird weiterhin gegen Port 8888 ausgeführt; der interne Server erhält die Verbindung auf Port 4444. Wird nur einer der beiden Ports betrachtet, wirkt die Regel schnell korrekt, obwohl Service-Matching oder Übersetzung nicht zusammenpassen. Eine vollständige Veröffentlichung ist unter Server per DNAT auf Sophos Firewall veröffentlichen beschrieben.

Nach NAT-Änderungen eine neue Verbindung aufbauen

Sophos Firewall wertet eine NAT-Regel nur für das erste Paket einer Verbindung aus. Bestehende Sessions verwenden weiterhin die vorherige Übersetzung, auch wenn die NAT-Regel inzwischen geändert wurde.

Nach einer NAT-Korrektur wird deshalb eine neue Verbindung aufgebaut: laufenden Test beenden, vorhandene Browser- oder Anwendungssession schliessen und den Flow erneut starten. Ein Reload innerhalb derselben TCP-Session beweist die neue NAT-Konfiguration nicht zuverlässig.

Routing erst nach bestätigtem Match untersuchen

Stimmen Rule ID und NAT Rule ID und zeigt Packet Capture Forwarded, ist das Rule Matching grundsätzlich bewiesen. Danach prüft man:

• passende statische Route oder Default Route
• SD-WAN route und aktives Gateway
• tatsächliches Ausgangsinterface
• Route auf dem Zielsystem und in entfernten Netzen
• symmetrischen Rückweg über VPN, MPLS oder WAN
• lokale Firewall des Zielservers

Der Policy Tester bildet SD-WAN nicht ab. Für die echte Entscheidung zählen Gateway ID, Interface und Paketpfad. Die Reihenfolge von statischen, SD-WAN- und VPN-Routen erklärt Routing-Priorität auf Sophos Firewall anpassen.

Sonderfälle nach dem ersten Befund

Erst wenn der grundlegende Flow eingeordnet ist, lohnt sich die Vertiefung in lokale Dienste, Benutzer, Namensauflösung oder Security-Module.

Traffic zur Firewall selbst: Device Access statt Firewall-Regel

WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS und SNMP enden auf der Firewall. Der Packet-Capture-Status kann deshalb Consumed sein. Der Zugriff wird unter Administration > Device access sowie mit Local Service ACL Exception Rules gesteuert, nicht mit einer normalen Durchgangsregel.

Zu prüfen sind Zone, vertrauenswürdiges Quellnetz, freigegebener Dienst, Benutzerberechtigung und MFA. Das sicherheitsrelevante Zusammenspiel erklärt Sophos Firewall Device Access und Local Service ACL absichern; die verschiedenen Weboberflächen sind unter Sophos Firewall Portale im Überblick eingeordnet.

Benutzer-Login und User Matching trennen

Ein erfolgreicher Login am VPN Portal, User Portal, Captive Portal oder über Entra ID SSO bestätigt zuerst nur die Authentifizierung. Damit die geplante Benutzerregel greift, muss die Firewall den Benutzer auch dem tatsächlichen Datenflow und seiner Source IP zuordnen.

Typische Befunde:

• User-Feld im Log Viewer ist leer: STAS, AD SSO, Captive Portal, Entra ID SSO oder Clientless User prüfen. Für eine feste Geräte-IP zeigt Clientless Users einrichten und testen die Zuordnung samt Live-User- und Negativtest.
• Benutzer ist sichtbar, aber eine andere Regel greift: Regelposition, Gruppenbedingung oder allgemeinere Regel oberhalb vergleichen.
• Nur VPN-Benutzer sind betroffen: Zone VPN, VPN-Pool, Source network und Gruppenmatching prüfen.
• Nur einzelne Benutzer sind betroffen: UPN, E-Mail-Adresse, importierte Directory-Gruppe und Sophos-Firewall-Gruppe vergleichen.

Für lokale AD-Umgebungen helfen STAS auf Sophos Firewall einrichten und Active Directory auf Sophos Firewall hinzufügen. Je nach Entra-Loginpfad passen Entra ID SSO für Sophos Connect und VPN Portal oder Entra ID SSO für Captive Portal. Bei sehr vielen erkannten Benutzern oder Clientless Users kann zusätzlich das Sophos Firewall User-ID-Limit relevant sein.

DNS, FQDN, CDN und IPv6 prüfen

Für das Rule Matching zählt die tatsächlich verwendete Ziel-IP, nicht nur der eingegebene Hostname. DNS-Cache, Split DNS, CDN-Dienste, ein anderer Resolver, zusätzliche API-Ziele oder IPv6 können den Flow auf eine andere Adresse führen.

Normale FQDN Hosts löst die Firewall selbst auf und aktualisiert die Zuordnung anhand der DNS-TTL. Wildcard-FQDNs funktionieren anders: Die Firewall lernt IP-Adressen passender Subdomains aus beobachteten DNS-Antworten. Nutzt der Client einen externen Resolver, muss dessen UDP-DNS-Verkehr auf Port 53 durch die Firewall laufen. Ist die betreffende Antwort für die Firewall nicht sichtbar, kann die Subdomain-IP im Wildcard-Objekt fehlen und die Regel trotz korrekt aussehendem Namen nicht matchen.

Zusätzlich unterstützen FQDN Hosts keine IPv6-Auflösung. Bevor ein Objekt erweitert wird, vergleicht man deshalb DNS-Antwort, Ziel-IP und IP-Version mit Log Viewer oder Packet Capture. Die Details zu TTL, Wildcards und Lernverhalten stehen unter FQDN Hosts und Wildcard-FQDNs auf Sophos Firewall. Für interne Auflösung helfen DNS Request Routes; eine aktive IPv6-Umgebung benötigt eigene passende Regeln und ein bewusstes IPv6-Konzept.

Security-Module und Traffic Shaping auseinanderhalten

Wenn Firewall Rule ID, NAT Rule ID und Routing stimmen, kann ein der Regel zugewiesenes Modul die Anwendung beeinflussen:

• Web Policy und Application Control
• SSL/TLS inspection rule und Decryption Profile
• IPS Policy und Malware Scan
• Zero-Day Protection
• Security Heartbeat

Es wird immer nur ein Modul für den konkreten Flow und einen kurzen Testzeitraum eingegrenzt. Eine Ausnahme bleibt auf Source, Ziel und Service beschränkt; danach wird die ursprüngliche Schutzwirkung wiederhergestellt oder die notwendige Ausnahme dokumentiert. Bei HTTPS-Problemen hilft der kontrollierte TLS-Inspection-Rollout.

Traffic Shaping ist dagegen eine QoS-Funktion. Sie garantiert, priorisiert oder begrenzt Bandbreite und kann dadurch niedrigen Durchsatz, Paketverlust bei Engpässen oder Timeouts verursachen. Das ist nicht dasselbe wie die Zugriffsentscheidung Drop oder Reject. Für einen echten Block werden Packet-Capture-Status, Reason und das verantwortliche Security-Modul geprüft. Bei grossen Transfers oder VPN-Verbindungen gehören auch MTU und MSS in die Analyse.

Änderungen kontrolliert testen und dokumentieren

Bei Regelproblemen sollte pro Test nur eine Variable geändert werden:

1. Ausgangszustand mit Source, Destination, Service, User, Uhrzeit, Rule ID und NAT ID notieren.
2. Genau eine Regelposition, ein Objekt, einen Service oder ein Modul ändern.
3. Bei NAT eine neue Verbindung aufbauen, sonst denselben Testflow erneut auslösen.
4. Log Viewer und Packet Capture mit denselben Filtern vergleichen.
5. Erfolg oder Misserfolg dokumentieren und erst dann die nächste Änderung prüfen.

Temporäre Allow-, Drop- oder Ausnahme-Regeln erhalten einen verständlichen Namen, einen Owner und ein Ablaufdatum. Sonst bleibt eine kurzfristige Diagnosehilfe schnell dauerhaft im Regelwerk.

Wenn die Verbindung gestern noch funktionierte, gehören auch die letzten Konfigurationsänderungen in die Prüfung. Audit Trail Logs zeigen, wer Regeln oder Objekte geändert hat. Config Studio hilft beim Vergleich grösserer Konfigurationen. Kam die Änderung aus Sophos Central, wird zusätzlich die Central Firewall Task Queue kontrolliert.

Checkliste für Regel-Troubleshooting

• Konkreter Testflow mit Source, Destination, Service, User und Uhrzeit definiert.
• Geprüft, ob es um Durchgangstraffic oder einen lokalen Firewall-Dienst geht.
• Regelposition, automatische Regeln und ausgeblendete Tabellenfilter kontrolliert.
• Alle Match-Felder mit dem realen Flow verglichen.
• Datenvolumen nur als Hinweis und nicht als Trefferzähler verwendet.
• Log Viewer zeigt die tatsächliche Firewall Rule ID und gegebenenfalls NAT Rule ID.
• Policy-Tester-Ergebnis mit Firmwarestand und echten Paketdaten abgeglichen.
• Packet Capture läuft mit passendem Capture-Filter und freiem Puffer.
• Incoming, Forwarded, Consumed, Generated, Violation, Reason und Interfaces korrekt eingeordnet.
• Bei DNAT Zielzone nach NAT, Destination Network vor NAT sowie beide PAT-Services geprüft.
• Nach NAT-Änderungen eine neue Verbindung aufgebaut.
• DNS-Antwort, Ziel-IP, FQDN-Lernverhalten und IP-Version kontrolliert.
• User Login und User Matching des Datenflows getrennt geprüft.
• Routing, SD-WAN, Gateway und Rückweg erst nach bestätigtem Regelmatch untersucht.
• Security-Module einzeln und Traffic Shaping als QoS geprüft.
• Jede Änderung dokumentiert; Testregeln haben Owner und Ablaufdatum.

FAQ