Sophos Firewall-regel werkt niet: oorzaken controleren

Wanneer een Sophos Firewall-regel niet werkt, moeten regels niet meteen worden verplaatst of objecten worden uitgebreid. Eerst wordt één gegevensstroom gereproduceerd en geobserveerd: komt het pakket aan, welke Firewall Rule ID en NAT Rule ID verwerken het, wordt het doorgestuurd en komt er een antwoord terug?

Meestal blijkt dat een voorwaarde anders is dan verwacht, een algemenere regel hoger in de lijst matcht of het probleem pas na de regelbeslissing ontstaat. De firewall zelf is veel minder vaak de oorzaak dan een onnauwkeurig gedefinieerde test.

Snelle beslissing: Als een correct gestarte en gefilterde Packet Capture geen pakket toont, worden eerst client, VLAN, gateway of het upstream-pad gecontroleerd. Een andere Rule ID leidt naar volgorde en matching. Als Rule ID en NAT ID kloppen, gaat de analyse verder met routing, retourpad, doelsysteem of securitymodule.

Snelle aanpak: één concrete flow volgen

Voor de eerste afbakening zijn zes stappen voldoende:

1. Testflow vastleggen: Source IP, Source zone, User, Destination, protocol, poort en tijdstip noteren.
2. Binnenkomst bewijzen: Packet Capture met een nauw Capture Filter starten en dezelfde flow activeren.
3. Firewall Rule ID controleren: In Log Viewer of Packet Capture vergelijken met de verwachte regel.
4. NAT Rule ID controleren: Als NAT betrokken is, de daadwerkelijke NAT-regel en vertaling controleren.
5. Forwarding en antwoord controleren: Zoeken naar Forwarded, het uitgaande interface en retourpakketten.
6. Pas daarna dieper gaan: Routing, SD-WAN, User Matching, TLS Inspection, IPS, Web Policy of het doelsysteem onderzoeken.

Deze aanpak houdt de lagen uit elkaar. Een firewallregel beslist over toegang en beveiligingsfuncties, NAT vertaalt adressen of poorten, routing kiest het verdere pad en het doelsysteem moet het retourpad kennen. Als alle lagen tegelijk worden gewijzigd, verdwijnt soms het symptoom, maar blijft de oorzaak onduidelijk.

Als de test is gericht op WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP of een andere dienst van de firewall zelf, gelden niet dezelfde regels als voor doorgaand verkeer. In dat geval leidt de diagnose rechtstreeks naar Administration > Device access en de Local Service ACL.

Een reproduceerbare testcase definiëren

Een uitspraak als “internet werkt niet” of “de VPN-regel werkt niet” is te breed. Een bruikbare testcase ziet er bijvoorbeeld zo uit:

• Source IP: 10.10.20.35
• Source zone: LAN
• User: admin@example.com of bewust geen User Matching
• Destination: app.example.net, momenteel via DNS omgezet in 203.0.113.20
• Service: TCP 443
• Verwachte firewallregel: LAN-App-HTTPS, Rule ID 37
• Verwachte NAT-regel: NAT Rule ID 12 of expliciet geen NAT-regel
• Testtijd: 2026-08-08 10:15:00

De IP-adressen, ID’s, namen en het tijdstip zijn voorbeeldwaarden en worden vervangen door de waarden uit de eigen omgeving. De vorm is belangrijk: tijdens de diagnose blijven Source, doel-IP, poort en gebruiker gelijk. Als tussendoor de DNS-resolutie, client of applicatie verandert, wordt niet langer dezelfde flow vergeleken.

De eerste observaties interpreteren

• Actieve Packet Capture toont ondanks een passend filter geen pakket: Controleer eerst Capture Status, filter en buffer. Als die correct zijn, ligt de oorzaak waarschijnlijk vóór de firewall, bijvoorbeeld bij client, VLAN, switch, gateway, provider of Cloud Security Group.
• Log Viewer toont een andere Rule ID: Een algemenere, automatisch gegenereerde of anders matchende regel wordt eerder geëvalueerd.
• Firewall Rule ID klopt, NAT Rule ID niet: Controleer de NAT-volgorde en Original source, destination en service.
• Rule ID en NAT ID kloppen, maar Forwarded is niet zichtbaar: Controleer regelactie, Reason, routing of een securitymodule.
• Forwarded is zichtbaar, maar er komt geen antwoord: Controleer retourroute, doelsysteem, lokale serverfirewall of externe blokkering.
• Alleen bepaalde gebruikers zijn getroffen: Controleer authenticatie en User Matching van de daadwerkelijke gegevensstroom afzonderlijk.

De uitgebreide gecombineerde werkwijze staat in Firewallregel testen met Log Viewer, Policy Tester en Packet Capture. Dit artikel concentreert zich op het verklaren van een onverwachte regelmatch.

Regelvolgorde en matching controleren

Een firewallregel werkt alleen als alle relevante criteria overeenkomen en geen eerdere regel hetzelfde verkeer al verwerkt.

De eerste passende regel wint

Sophos Firewall evalueert regels van boven naar beneden en stopt bij de eerste passende regel. De positie in de lijst is daarom bepalend; de Rule ID is alleen een vaste identificatie en komt niet overeen met de positie.

Daarnaast moet op het volgende worden gelet:

• Een algemene regel hoger in de lijst kan een specifieke regel eronder volledig overschaduwen.
• Rule Groups verbeteren het overzicht, maar creëren geen eigen matchlogica. De regels in de groep worden geëvalueerd.
• Automatisch gegenereerde regels, bijvoorbeeld voor MTA, IPsec of hotspots, kunnen bovenaan worden ingevoegd en als eerste worden gecontroleerd.
• Een actief filter in de regeltabel kan relevante regels verbergen. Gebruik vóór de analyse Reset filter.
• De onveranderbare Default Drop-regel heeft Rule ID 0, staat onderaan en heeft geen normale Usage Counter. Tabelfilters gelden er niet voor.

De basislogica van een regel wordt volledig uitgelegd in Sophos Firewall-regels begrijpen en correct configureren.

Alle matchcriteria samen lezen

Een regel die er correct uitziet, kan door één enkel veld niet matchen:

• Source zones: De client komt uit een andere zone, bijvoorbeeld VPN in plaats van LAN, of het VLAN is aan een andere zone toegewezen.
• Source networks and devices: Het IP-object, de hostgroep of het subnet bevat de daadwerkelijke Source IP niet.
• Destination zones: De doelzone is onjuist, vooral bij DNAT, VPN of gerouteerde netwerken.
• Destination networks: Het daadwerkelijk aangesproken IP-adres komt niet overeen met het object of de pre- en post-NAT-weergave zijn verwisseld.
• Services: De poort ontbreekt, TCP en UDP zijn verwisseld of de applicatie opent extra verbindingen.
• Users or groups: De firewall kan de gebruiker niet aan de Source IP koppelen of de geïmporteerde groep klopt niet.
• Schedule: Het schema is op het testmoment niet actief.
• Exclusions: De flow wordt van de regel uitgesloten en daarna tegen verdere regels geëvalueerd.

Bij webverkeer hoort ook het protocol bij de test. Browsers kunnen QUIC via UDP 443 gebruiken, terwijl de verwachte regel of webcontrole alleen klassiek HTTPS via TCP 443 afdekt. De gevolgen worden uitgelegd in QUIC op Sophos Firewall controleren.

Overgedragen gegevensvolume gecontroleerd resetten

De menuoptie Reset data transfer count kan bij een test helpen, maar wordt vaak verkeerd geïnterpreteerd. Deze reset het via de regel overgedragen gegevensvolume; het is geen sessie- of trefferteller.

1. Open Rules and policies > Firewall rules.
2. Zoek de betreffende regel en open het menu met de drie punten.
3. Selecteer Reset data transfer count.
4. Activeer de gedefinieerde testflow opnieuw.
5. Evalueer gegevensvolume, Rule ID en Packet Capture samen.

Als de waarde na de gecontroleerde test stijgt, wijst dat op overgedragen verkeer via deze regel. Als de waarde onveranderd blijft, bewijst dit op zichzelf niet dat de regel nooit heeft gematcht. Voor een betrouwbare conclusie worden de daadwerkelijke Rule ID in Log Viewer en het pakketpad in Packet Capture gecontroleerd. Voor de Default Drop-regel met ID 0 is deze gegevensteller sowieso niet beschikbaar.

Log Viewer, Policy Tester en Packet Capture correct lezen

De tools beantwoorden verschillende vragen:

• Log Viewer: Welke gelogde sessie, regel, NAT-regel, actie en gebruiker zijn herkend?
• Policy Tester: Welke policylogica zou voor de ingevoerde waarden gelden?
• Packet Capture: Welke pakketten komen daadwerkelijk aan, hoe verwerkt de firewall ze en gaan ze weer naar buiten?

Geen van de tools vervangt de andere volledig. Als simulatie en echte pakketstroom elkaar tegenspreken, wegen log- en pakketgegevens uit de reproduceerbare test zwaarder.

Log Viewer: daadwerkelijke Rule ID en NAT Rule ID

In de firewallregel moet Log firewall traffic zijn ingeschakeld. Daarnaast moet onder System services > Log settings het juiste logtype voor lokale weergave, Sophos Central of Syslog zijn ingeschakeld.

Voor de test zijn filters op de volgende velden nuttig:

• Source IP en Destination IP
• Poort of Service
• Rule ID en Rule name
• NAT rule ID
• Action en User
• het genoteerde testtijdstip

Een ontbrekende invoer bewijst nog niet dat de firewall niets heeft gezien. Firewallsessies worden onder andere gelogd wanneer de verbinding met een Destroy-event eindigt. Bij abrupte verbindingsonderbrekingen kan de verwachte invoer daarom ontbreken of later verschijnen. Packet Capture levert dan een directere bevinding. De bijbehorende services en logbestanden worden beschreven in Sophos Firewall-troubleshooting: services en logs.

Policy Tester: policylogica zonder echte pakketstroom

Onder Diagnostics > Tools > Policy tester worden URL, User, tijd, Source IP en Source zone bewust ingesteld. Protocol en poort moeten uit de volledige URL blijken, bijvoorbeeld https://app.example.net:8443/. Zonder protocol test de tool HTTP; voor HTTPS wordt standaard poort 443 gebruikt en een afwijkende poort moet in de URL worden opgegeven.

De Policy Tester is nuttig, maar heeft duidelijke beperkingen:

• De tool genereert geen echte pakketstroom en controleert het doelsysteem of retourpad niet.
• De resultaten geven SD-WAN-routes niet weer.
• Regels met MAC-adressen onder Source networks and devices kunnen niet worden gematcht.
• Problemen bij provider, switch, gateway en pakketverlies blijven onzichtbaar.

⚠️ Op SFOS 22.0 GA Build 411 konden NC-177587 en NC-176083 onjuiste Policy Test-resultaten veroorzaken. Verkeer leek geblokkeerd of via de verkeerde regel gematcht, hoewel het in werkelijkheid correct stroomde. MR1 Build 490 bevat de gedocumenteerde correcties. Controleer bij tegenstrijdige resultaten eerst firmwareversie, Log Viewer en Packet Capture voordat productieregels worden gewijzigd.

Packet Capture: het echte pakketpad controleren

Onder Diagnostics > Packet capture wordt eerst een nauw BPF Capture Filter ingesteld, bijvoorbeeld op Source IP, Destination IP en poort van de testflow. Activeer daarna Trace On, wis de lijst en activeer precies de gedefinieerde flow.

Een lege Packet Capture is pas betekenisvol als aan deze voorwaarden is voldaan:

1. Trace On is actief.
2. Het BPF Capture Filter past bij het daadwerkelijke doel en filtert de flow niet weg.
3. De buffer heeft het relevante testverkeer niet al overschreven. Zonder Wrap capture buffer once full stopt de opname zodra de buffer van 2048 KB vol is en wordt deze met Clear voortgezet. Met de Wrap-optie ingeschakeld loopt de opname door en worden de oudste pakketten overschreven.

Een extra Display Filter verandert niet wat is opgenomen, maar kan bestaande invoeren onzichtbaar maken. Controleer Capture Filter en Display Filter daarom afzonderlijk.

De statuswaarden betekenen:

• Incoming: Het pakket is op een interface ontvangen.
• Forwarded: De firewall stuurt het pakket via een uitgaande interface door.
• Consumed: Het pakket is bestemd voor de firewall zelf of wordt door de firewall gebruikt.
• Generated: De firewall heeft het pakket zelf gegenereerd.
• Violation: Een policyovertreding leidt tot een drop; het veld Reason verklaart de reden nader.

Rule ID, NAT ID, Reason en de inkomende en uitgaande interface worden altijd samen gelezen. Consumed en Generated zijn normale resultaten en niet automatisch fouten.

⚠️ Op SFOS 22.0 MR1 Build 490 kan NC-178387 drops door de Default-regel met ID 0 alleen als Incoming tonen. De verwachte invoer Violation Firewall en de invoer in drppkt ontbreken, hoewel de firewall de flow nog steeds weigert. Voor deze getroffen versie helpen de Policy Tester of een bewust geplaatste, gelogde dropregel aan het einde van de eigen regellijst. In de huidige Known Issues-informatie wordt geen fixversie genoemd.

Een gedetailleerde Capture-werkwijze staat in Packet Capture in Sophos Firewall WebAdmin gebruiken. Drops en een gecontroleerde slotregel worden behandeld in Door Sophos Firewall geweigerde pakketten analyseren.

NAT, DNAT, routing en retourpad controleren

NAT staat geen verkeer toe. Het vertaalt adressen of poorten voor verkeer dat door een firewallregel wordt toegestaan. Daarom moeten Firewall Rule ID en NAT Rule ID afzonderlijk kloppen.

Firewall Rule ID en NAT Rule ID samen evalueren

• Firewall Rule ID klopt, NAT Rule ID is onjuist: Controleer NAT-volgorde, Original-velden en algemenere NAT-regels.
• NAT Rule ID klopt, Firewall Rule ID is onjuist: Vergelijk firewallvolgorde, zones, Source, Destination, Service en Schedule.
• Beide ID’s kloppen, verbinding mislukt: Controleer routing, retourpad, doelserver, securitymodule of applicatie.
• Geen NAT Rule ID zichtbaar terwijl NAT wordt verwacht: Controleer richting, Inbound/Outbound Interface en de Original-criteria van de NAT-regel.

Onder Rules and policies > NAT rules geldt eveneens de eerste passende regel. Een algemene SNAT- of MASQ-regel kan daarom een specifieke regel eronder overschaduwen. Linked NAT Rules worden bovendien alleen meegenomen voor verkeer dat matcht met de bijbehorende firewallregel; een eerdere zelfstandige NAT-regel kan toch als eerste matchen.

De volledige ID-logica wordt uitgelegd in NAT op Sophos Firewall begrijpen.

DNAT vanuit pre- en post-NAT-perspectief begrijpen

Voor inkomend DNAT-verkeer geldt een belangrijke vuistregel:

De firewallregel gebruikt de doelzone na NAT, maar als Destination Network het oorspronkelijk aangesproken adres vóór NAT.

Voorbeeld van een portforwarding:

• De externe client maakt verbinding met 198.51.100.10 op TCP 8888.
• De NAT-regel vertaalt naar server 10.10.50.20 in zone DMZ en naar TCP 4444.
• In de NAT-regel is TCP 8888 de Original service en TCP 4444 de Translated service (PAT).
• De firewallregel gebruikt WAN als Source zone, DMZ als Destination zone en 198.51.100.10 als Destination network.
• In het officiële Sophos PAT-voorbeeld bevat de bijbehorende firewallregel zowel de oorspronkelijke als de vertaalde service.

De externe test wordt nog steeds uitgevoerd tegen poort 8888; de interne server ontvangt de verbinding op poort 4444. Als slechts één van beide poorten wordt bekeken, lijkt de regel al snel correct, hoewel servicematching en vertaling niet bij elkaar passen. Een volledige publicatie wordt beschreven in Server via DNAT op Sophos Firewall publiceren.

Na NAT-wijzigingen een nieuwe verbinding opbouwen

Sophos Firewall evalueert een NAT-regel alleen voor het eerste pakket van een verbinding. Bestaande sessies blijven de eerdere vertaling gebruiken, ook als de NAT-regel inmiddels is gewijzigd.

Na een NAT-correctie wordt daarom een nieuwe verbinding opgebouwd: beëindig de lopende test, sluit de bestaande browser- of applicatiesessie en start de flow opnieuw. Een reload binnen dezelfde TCP-sessie bewijst de nieuwe NAT-configuratie niet betrouwbaar.

Routing pas na bevestigde match onderzoeken

Als Rule ID en NAT Rule ID kloppen en Packet Capture Forwarded toont, is Rule Matching fundamenteel bewezen. Daarna wordt het volgende gecontroleerd:

• passende statische route of Default Route
• SD-WAN route en actieve gateway
• daadwerkelijk uitgaand interface
• route op het doelsysteem en in externe netwerken
• symmetrisch retourpad via VPN, MPLS of WAN
• lokale firewall van de doelserver

De Policy Tester geeft SD-WAN niet weer. Voor de echte beslissing tellen Gateway ID, interface en pakketpad. De volgorde van statische, SD-WAN- en VPN-routes wordt uitgelegd in Routingprioriteit op Sophos Firewall aanpassen.

Speciale gevallen na de eerste bevinding

Pas nadat de fundamentele flow is ingedeeld, heeft verdere analyse van lokale services, gebruikers, naamresolutie of securitymodules zin.

Verkeer naar de firewall zelf: Device Access in plaats van firewallregel

WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS en SNMP eindigen op de firewall. De Packet Capture-status kan daarom Consumed zijn. De toegang wordt geregeld onder Administration > Device access en met Local Service ACL Exception Rules, niet met een normale regel voor doorgaand verkeer.

Controleer zone, vertrouwd bronnetwerk, toegestane service, gebruikersrechten en MFA. Het veiligheidsrelevante samenspel wordt uitgelegd in Sophos Firewall Device Access en Local Service ACL beveiligen; de verschillende webinterfaces worden beschreven in Overzicht van Sophos Firewall-portalen.

Gebruikerslogin en User Matching scheiden

Een succesvolle login bij VPN Portal, User Portal, Captive Portal of via Entra ID SSO bevestigt in eerste instantie alleen de authenticatie. Om de geplande gebruikersregel te laten werken, moet de firewall de gebruiker ook aan de daadwerkelijke gegevensstroom en Source IP koppelen.

Typische bevindingen:

• User-veld in Log Viewer is leeg: Controleer STAS, AD SSO, Captive Portal, Entra ID SSO of Clientless User. Voor een vast apparaat-IP toont Clientless Users configureren en testen de koppeling met de controle in Live Users en de negatieve test.
• Gebruiker is zichtbaar, maar een andere regel matcht: Vergelijk regelpositie, groepsvoorwaarde of algemenere regel hoger in de lijst.
• Alleen VPN-gebruikers zijn getroffen: Controleer zone VPN, VPN-pool, Source network en groepsmatching.
• Alleen afzonderlijke gebruikers zijn getroffen: Vergelijk UPN, e-mailadres, geïmporteerde directorygroep en Sophos Firewall-groep.

Voor lokale AD-omgevingen helpen STAS op Sophos Firewall instellen en Active Directory aan Sophos Firewall toevoegen. Afhankelijk van het Entra-loginpad passen Entra ID SSO voor Sophos Connect en VPN Portal of Entra ID SSO voor Captive Portal. Bij zeer veel herkende gebruikers of Clientless Users kan ook de Sophos Firewall User ID-limiet relevant zijn.

DNS, FQDN, CDN en IPv6 controleren

Voor Rule Matching telt het daadwerkelijk gebruikte doel-IP, niet alleen de ingevoerde hostnaam. DNS-cache, Split DNS, CDN-services, een andere resolver, extra API-doelen of IPv6 kunnen de flow naar een ander adres leiden.

Normale FQDN Hosts worden door de firewall zelf opgelost en de koppeling wordt op basis van de DNS TTL bijgewerkt. Wildcard FQDN’s werken anders: de firewall leert IP-adressen van passende subdomeinen uit waargenomen DNS-antwoorden. Als de client een externe resolver gebruikt, moet diens UDP DNS-verkeer op poort 53 door de firewall lopen. Als het betreffende antwoord niet zichtbaar is voor de firewall, kan het IP-adres van het subdomein in het Wildcard-object ontbreken en matcht de regel ondanks een correct ogende naam niet.

Daarnaast ondersteunen FQDN Hosts geen IPv6-resolutie. Vergelijk daarom, voordat een object wordt uitgebreid, DNS-antwoord, doel-IP en IP-versie met Log Viewer of Packet Capture. Details over TTL, Wildcards en leergedrag staan in FQDN Hosts en Wildcard FQDN’s op Sophos Firewall. Voor interne resolutie helpen DNS Request Routes; een actieve IPv6-omgeving vereist eigen passende regels en een bewust IPv6-concept.

Securitymodules en Traffic Shaping uit elkaar houden

Als Firewall Rule ID, NAT Rule ID en routing kloppen, kan een aan de regel toegewezen module de applicatie beïnvloeden:

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

Er wordt telkens slechts één module voor de concrete flow en een korte testperiode afgebakend. Een uitzondering blijft beperkt tot Source, doel en Service; daarna wordt de oorspronkelijke beveiliging hersteld of wordt de noodzakelijke uitzondering gedocumenteerd. Bij HTTPS-problemen helpt de gecontroleerde TLS Inspection-rollout.

Traffic Shaping is daarentegen een QoS-functie. Het garandeert, prioriteert of beperkt bandbreedte en kan daardoor lage throughput, pakketverlies bij congestie of time-outs veroorzaken. Dit is niet hetzelfde als de toegangsbeslissing Drop of Reject. Voor een echte blokkering worden Packet Capture-status, Reason en de verantwoordelijke securitymodule gecontroleerd. Bij grote overdrachten of VPN-verbindingen horen ook MTU en MSS bij de analyse.

Wijzigingen gecontroleerd testen en documenteren

Bij regelproblemen wordt per test slechts één variabele gewijzigd:

1. Noteer de uitgangssituatie met Source, Destination, Service, User, tijdstip, Rule ID en NAT ID.
2. Wijzig precies één regelpositie, object, Service of module.
3. Bouw bij NAT een nieuwe verbinding op; activeer anders dezelfde testflow opnieuw.
4. Vergelijk Log Viewer en Packet Capture met dezelfde filters.
5. Documenteer succes of mislukking en controleer pas daarna de volgende wijziging.

Tijdelijke Allow-, Drop- of uitzonderingsregels krijgen een duidelijke naam, een owner en een vervaldatum. Anders blijft een tijdelijke diagnosehulp al snel permanent in de regelset staan.

Als de verbinding gisteren nog werkte, moeten ook de laatste configuratiewijzigingen worden gecontroleerd. Audit Trail Logs laten zien wie regels of objecten heeft gewijzigd. Config Studio helpt bij het vergelijken van grotere configuraties. Als de wijziging uit Sophos Central kwam, wordt ook de Central Firewall Task Queue gecontroleerd.

Checklist voor troubleshooting van regels

• Concrete testflow met Source, Destination, Service, User en tijdstip gedefinieerd.
• Gecontroleerd of het om doorgaand verkeer of een lokale firewallservice gaat.
• Regelpositie, automatische regels en verborgen tabelfilters gecontroleerd.
• Alle matchvelden met de daadwerkelijke flow vergeleken.
• Gegevensvolume alleen als aanwijzing en niet als trefferteller gebruikt.
• Log Viewer toont de daadwerkelijke Firewall Rule ID en waar van toepassing NAT Rule ID.
• Policy Tester-resultaat vergeleken met firmwareversie en echte pakketgegevens.
• Packet Capture draait met een passend Capture Filter en vrije buffer.
• Incoming, Forwarded, Consumed, Generated, Violation, Reason en interfaces correct geïnterpreteerd.
• Bij DNAT de doelzone na NAT, Destination Network vóór NAT en beide PAT-services gecontroleerd.
• Na NAT-wijzigingen een nieuwe verbinding opgebouwd.
• DNS-antwoord, doel-IP, FQDN-leergedrag en IP-versie gecontroleerd.
• User Login en User Matching van de gegevensstroom afzonderlijk gecontroleerd.
• Routing, SD-WAN, gateway en retourpad pas na bevestigde regelmatch onderzocht.
• Securitymodules afzonderlijk en Traffic Shaping als QoS gecontroleerd.
• Elke wijziging gedocumenteerd; testregels hebben een owner en vervaldatum.

FAQ