Sophos Firewall-regel werkt niet: Oorzaken onderzoeken

Als een firewall-regel niet werkt, is de firewall zelden “kapot”. Meestal klopt een voorwaarde niet, staat er een algemenere regel boven, verandert NAT het zicht op het verkeer, is gebruikersmatching niet voldaan of is logging niet correct geactiveerd.

Deze checklist helpt om systematisch te werk te gaan in plaats van willekeurig aan regels te sleutelen.

Oriëntatie

Begin met een duidelijk testgeval voordat regels of security features worden gewijzigd.

Welke artikel past?

Regelproblemen overlappen snel met NAT, routing, VPN, Device Access of beveiligingsfuncties. Voor de analyse moet eerst duidelijk zijn welk niveau betrokken is:

• Een firewall-regel van begin tot eind begrijpen: Sophos Firewall-regels begrijpen en correct configureren
• Individuele verbinding testen met Log Viewer, Policy Tester en Packet Capture: Firewall-regel testen met Log Viewer, Policy Test en Packet Capture
• NAT, SNAT, DNAT, MASQ of PAT is betrokken: NAT op Sophos Firewall begrijpen
• Een server wordt via DNAT gepubliceerd vanuit het internet: Server publiceren via DNAT
• Toegang gaat naar WebAdmin, VPN Portal, SSH, DNS of SNMP van de firewall: Device Access correct configureren
• Route, SD-WAN of retourpad is onduidelijk: Routing-prioriteit op Sophos Firewall aanpassen
• Pakketten moeten direct op de firewall worden gecontroleerd: Packet Capture in WebAdmin gebruiken

Deze scheiding is belangrijk omdat een firewall-regel niet elke vorm van toegang regelt. Lokale diensten van de firewall, NAT-beslissingen, routing en beveiligingsfuncties hebben hun eigen controlepunten.

Snelle afbakening

In het begin moet je niet meteen regels verplaatsen of objecten wijzigen. Eerst wordt afgebakend waar het verkeer verloren gaat.

• Regelcounter blijft 0: Regelpositie, zone, bron, bestemming, service of schema klopt niet
• Log Viewer toont een andere regel: Een algemenere of automatisch gegenereerde regel staat hoger
• Log Viewer toont niets: Logging ontbreekt of het verkeer bereikt de firewall niet
• Packet Capture ziet geen pakket: Probleem ligt voor de firewall: client, VLAN, switch, gateway, provider of cloud security group
• Packet Capture ziet pakketten, maar geen forward: Firewall-regel, NAT, routing of beveiligingsfunctie blokkeert
• Packet Capture ziet forward, maar geen antwoord: Retourroute, doelsysteem, NAT of externe firewall controleren

Deze scheiding bespaart tijd. Als de firewall geen pakket ziet, helpt geen wijziging aan een firewall-regel. Als de Log Viewer een andere Rule ID toont, is de volgorde belangrijker dan de betreffende doelregel. Als pakketstroom en Rule ID kloppen, verschuift de analyse naar NAT, retourpad of beveiligingsfuncties.

Testgeval duidelijk definiëren

Een regel kan alleen zinvol worden getest als het testgeval eenduidig is. Uitspraken zoals “Internet werkt niet” of “VPN werkt niet” zijn te breed. Voor het oplossen van problemen is een concreet flow nodig.

Voor de test moet vaststaan:

• Bron IP: Client 10.10.20.35
• Bronzone: LAN, VPN, DMZ of aangepaste zone
• Gebruiker: geauthenticeerde gebruiker of geen gebruikersmatching
• Bestemming: Server-IP, FQDN, openbare IP of WAN-object
• Service: TCP 443, UDP 53, ICMP, aangepaste service
• Verwachte regel: Regelnaam of Rule ID, indien bekend
• Verwachte NAT-regel: NAT Rule ID of regelnaam, indien NAT betrokken is
• Testtijd: exacte tijd voor Log Viewer en latere logbestanden

Daarna wordt altijd dezelfde test herhaald. Als tijdens de analyse bron-IP, doel, DNS-resolutie of poort veranderen, vergelijk je niet meer hetzelfde geval.

Analysehulpmiddelen correct combineren

Sophos Firewall biedt verschillende hulpmiddelen die verschillende vragen beantwoorden. Geen van hen is alleen een volledig bewijs.

• Regelcounter: Treft de nieuwe testtraffic de regel in principe? Toont niet waarom een toepassing toch faalt
• Log Viewer: Welke Rule ID, NAT Rule ID, actie, gebruiker of beveiligingsfunctie werd gelogd? Hangt af van logging en sessie-einde
• Policy Tester: Welke beleidslogica zou voor een gedefinieerde flow gelden? Vervangt geen echte pakketstroom en dekt SD-WAN niet volledig
• Packet Capture: Komen pakketten aan, worden ze doorgestuurd of verworpen? Verklaart niet elke toepassingslaag en heeft strakke filters nodig
• Service-logs: Heeft een module zoals Web, IPS, authenticatie of VPN een eigen probleem? Pas zinvol als de getroffen dienst is afgebakend

Voor een betrouwbaar resultaat combineer je minimaal Log Viewer en een echte test. Bij tegenstrijdige resultaten is Packet Capture meestal de volgende stap, omdat het laat zien of pakketten daadwerkelijk aankomen en doorgaan.

Beslissingsboom voor de eerste test

Voor de eerste analyse is vaak een korte beslissingsboom voldoende. Deze voorkomt dat je meteen aan regels, NAT en routing tegelijk werkt.

• Packet Capture ziet geen pakket: Client, VLAN, switch, gateway, provider, cloud security group of voorgeschakelde firewall controleren
• Packet Capture ziet pakket, Log Viewer blijft leeg: Logging, logtype, sessie-einde en passende BPF-filter controleren
• Log Viewer toont andere Rule ID: Regelvolgorde, zones, bron, bestemming, service en schema vergelijken
• Firewall Rule ID klopt, NAT Rule ID niet: NAT-volgorde en Original-velden controleren
• Rule ID en NAT ID kloppen, maar geen antwoord komt terug: Retourroute, doelsysteem, lokale firewall op de server of externe blokkade controleren
• Regel matcht alleen niet bij bepaalde gebruikers: Gebruikersmatching, groep, authenticatie en clientloze gebruiker controleren

Hiermee blijft de analyse gecontroleerd: Eerst wordt bewezen of het verkeer de firewall bereikt. Daarna wordt gecontroleerd welke regel en welke NAT-regel daadwerkelijk van toepassing zijn. Pas als deze twee punten kloppen, loont het de moeite om te zoeken naar retourpad, beveiligingsfuncties of toepassingslaag.

Rule matching begrijpen

Sophos Firewall verwerkt regels op volgorde. De eerste passende regel wint.

Eerste principe: De eerste passende regel wint

Sophos Firewall verwerkt firewall-regels van boven naar beneden. Zodra een regel past, worden volgende regels niet meer gecontroleerd. Hetzelfde basisprincipe geldt ook voor NAT-regels.

Belangrijk:

• De positie in de lijst bepaalt de evaluatie.
• De Rule ID is slechts een referentie en zegt niets over de huidige volgorde.
• Regelgroepen helpen bij het overzicht, maar zijn geen eigen match-logica.
• Een algemene regel bovenaan kan een specifieke regel eronder volledig “opslokken”.

Als een regel niet werkt, controleer dan eerst de positie.

Regelcounter resetten

Bij onduidelijke treffers helpt het om de regelcounter te resetten.

1. Open Rules and policies > Firewall rules.
2. Zoek de betreffende regel.
3. Open het drie-punten-menu.
4. Selecteer Reset data transfer count.
5. Reproduceer het verkeer opnieuw.
6. Controleer de teller na de test.

Als de teller niet stijgt, matcht de regel niet. Als hij stijgt, maar de toepassing werkt toch niet, ligt het probleem eerder bij Security Profiles, NAT, routing, retourpad of doelsysteem.

Matching-velden controleren

Een firewall-regel matcht alleen als alle relevante criteria kloppen.

• Bronzones: Verkeerde zone, VLAN ligt in andere zone, VPN-verkeer komt uit VPN
• Bronnetwerken en apparaten: Verkeerd object, verkeerd IP, hostgroep onvolledig
• Bestemmingszones: Verkeerde doelzone, vooral bij DNAT of VPN
• Bestemmingsnetwerken: Voor-NAT- en na-NAT-zicht verwisseld
• Services: Poort ontbreekt, TCP/UDP verwisseld, toepassing gebruikt extra poorten
• Gebruikers of groepen: Gebruiker is niet geauthenticeerd of verkeerde groep
• Schema: Tijdschema past momenteel niet
• Uitsluitingen: Verkeer wordt uit de regel uitgesloten en daaronder verder verwerkt

Bij webverkeer moet je daarnaast controleren of QUIC actief is. Als browsers verkeer via UDP 443 verzenden, werken sommige webfilter- en scanverwachtingen anders dan bij klassiek HTTPS via TCP.

Meer hierover: Sophos Firewall en het QUIC-protocol.

DNS, FQDN en IPv6 niet over het hoofd zien

Een regel kan correct lijken en toch niet matchen als de client een ander doel bereikt dan verwacht. Dit gebeurt vaak bij FQDN-objecten, Split DNS, CDN-diensten, IPv6 of toepassingen die meerdere doelen parallel gebruiken.

Voor regelwijzigingen moet je daarom controleren:

• Welke IP lost de client echt op?: DNS-cache, Split DNS of een andere resolver kunnen een ander adres leveren dan verwacht.
• Is het IPv4 of IPv6?: IPv4-regels matchen geen IPv6-verkeer. Als clients IPv6 verkiezen, moet de IPv6-kant apart worden gecontroleerd.
• Wordt een FQDN-host in de firewall gebruikt?: De firewall moet de FQDN oplossen en het huidige doel-IP kennen. CDN- of clouddiensten kunnen meerdere wisselende IP’s leveren.
• Gebruikt de toepassing extra doelen?: Login, API, updates, telemetrie of mediapaden kunnen andere domeinen en poorten gebruiken dan de hoofdtoepassing.
• Gebruikt een interne client de openbare naam van een interne dienst?: Dan zijn Split DNS, Loopback NAT of een verkeerde openbare resolutie mogelijke oorzaken.

Voor het oplossen van problemen is het cruciaal om niet alleen de hostnaam te noteren, maar de daadwerkelijk gebruikte doel-IP in de Log Viewer of Packet Capture te vergelijken. Als een regel naar een specifiek FQDN- of hostobject wijst, maar de client een ander IP gebruikt, zal de regel niet matchen.

Bij interne naamresoluties helpen schone DNS-aanvraagroutes. De procedure staat in DNS-aanvraagroutes op Sophos Firewall instellen. Als IPv6 in de omgeving actief is, moet je daarnaast controleren of IPv6 bewust is gepland en het juiste beleid aanwezig is. Basisprincipes hierover staan in IPv6 Prefix Delegation op Sophos Firewall instellen.

Verkeer naar de firewall zelf is een bijzonder geval

Niet elke toegang tot een Sophos Firewall wordt geregeld via normale firewall-regels. Als de client de firewall zelf moet bereiken, bijvoorbeeld WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS of SNMP, zijn Device Access en Local service ACL doorslaggevend.

Typische voorbeelden:

• WebAdmin vanuit LAN of WAN: Device Access, Local service ACL, MFA, admin-rechten
• VPN Portal of User Portal: Device Access, portalconfiguratie, gebruikersrechten
• SSH naar de firewall: Device Access, Local service ACL, admin-rechten, bronnetwerk
• SSL VPN of IPsec-inbelverbinding: Device Access voor de juiste zone, VPN-configuratie, authenticatie
• DNS naar de firewall: Device Access, DNS-configuratie, aanvraagpad
• SNMP naar de firewall: Device Access, SNMP-configuratie, monitoringbron

Als een firewall-regel voor dergelijk verkeer niet werkt, is dat vaak geen fout van de regel. Het verkeer eindigt op de firewall en wordt als lokale dienst behandeld. Voor het versterken van deze diensten is Sophos Firewall-toegang beveiligen: Device Access correct configureren het centrale artikel. Voor portalen past daarnaast Overzicht van Sophos-portalen.

NAT, DNAT en ID’s controleren

Bij DNAT-verkeer moeten firewallregels en NAT-regels samen worden gelezen.

DNAT correct lezen

Bij DNAT is het zicht in firewall-regels bijzonder belangrijk. Als vuistregel kun je onthouden:

Firewall-regels voor DNAT-verkeer gebruiken de doelzone na NAT, maar het doel-IP voor NAT.

Voorbeeld:

• Externe client verbindt met de WAN-IP van de firewall.
• NAT vertaalt naar een interne server in de DMZ.
• De firewall-regel gebruikt als bestemmingszone de zone van de interne server, bijvoorbeeld DMZ.
• Het bestemmingsnetwerk blijft echter de openbare IP of het WAN-object dat de client heeft aangesproken.

Als deze combinatie verkeerd is, lijkt de NAT-regel misschien correct, maar de firewall-regel matcht toch niet.

Meer hierover: Server publiceren via DNAT op Sophos Firewall.

NAT-regels controleren

NAT staat geen verkeer toe. NAT vertaalt alleen. Er is altijd een passende firewall-regel nodig.

Onder Rules and policies > NAT rules moet je controleren:

• Staat de juiste NAT-regel boven algemenere NAT-regels?
• Is de regel actief?
• Kloppen originele bron, bestemming en service?
• Kloppen vertaalde bron, bestemming en service?
• Wordt MASQ of een vaste SNAT-IP gebruikt?
• Is er een gekoppelde NAT-regel die onverwacht van toepassing is?
• Is er een generieke SNAT-regel die voor een specifiekere regel matcht?

Sophos raadt voor eenvoudige omgevingen meestal zelfstandige NAT-regels aan, in plaats van per firewall-regel een gekoppelde NAT-regel te maken.

Meer hierover: NAT op Sophos Firewall begrijpen: SNAT, DNAT, MASQ, PAT.

Firewall Rule ID en NAT Rule ID samen lezen

Als NAT betrokken is, is de vraag “Welke firewall-regel is van toepassing?” niet voldoende. Een verbinding kan de verwachte Firewall Rule ID treffen, maar toch via een verkeerde NAT Rule ID lopen. Omgekeerd kan een NAT-regel correct lijken, terwijl een algemenere firewall-regel bovenaan het verkeer al verwerkt.

Voor de test moet je daarom vooraf noteren:

• Verwachte Firewall Rule ID: Toont of de juiste firewall-regel het verkeer toestaat of blokkeert
• Verwachte NAT Rule ID: Toont of de juiste SNAT-, DNAT-, MASQ- of PAT-regel vertaalt
• Werkelijke ID’s in Log Viewer: Bevestigt of de firewall de flow zo verwerkt als gepland
• ID’s in Packet Capture: Helpt als de Log Viewer onvolledig lijkt of het retourpad onduidelijk is

De interpretatie is relatief eenvoudig, maar bespaart veel zoektijd:

• Firewall Rule ID klopt, NAT Rule ID is verkeerd: NAT-volgorde, Original-velden en algemenere NAT-regels controleren
• NAT Rule ID klopt, Firewall Rule ID is verkeerd: Firewall-regelvolgorde, zones, bron, bestemming en service controleren
• Beide ID’s kloppen, verbinding faalt toch: Retourpad, doelsysteem, beveiligingsfunctie of toepassing controleren
• Geen NAT Rule ID zichtbaar, hoewel NAT verwacht wordt: Testflow, NAT-criteria, richting en logging opnieuw controleren

Belangrijk is om niet meteen beide regelwerken tegelijk aan te passen. Eerst wordt bepaald of het probleem in het firewall-matching of in het NAT-matching ligt. Pas daarna moet je een specifieke regelpositie, een object of een veld wijzigen. De uitgebreidere NAT-evaluatie staat in de sectie Firewall Rule ID en NAT Rule ID correct lezen.

Gebruikers, routing en security features controleren

User Matching, routing, NAT, logging en securityprofielen kunnen beïnvloeden of een regel matcht.

Gebruikersmatching en authenticatie controleren

Regels met gebruikers- of groepsmatching lijken vaak correct, maar werken alleen als de firewall de gebruiker op dat moment ook echt aan het verkeer kan toewijzen.

Te controleren:

• Is de gebruiker zichtbaar in de Log Viewer?
• Komt het verkeer van het verwachte apparaat of van een andere client?
• Is de gebruiker in de juiste firewall-groep?
• Werkt AD SSO, STAS, Captive Portal, RADIUS of Entra ID SSO?
• Is er een regel zonder gebruikersmatching boven de geplande gebruikersregel?
• Zijn er clientloze gebruikers die anders worden behandeld?
• Is MFA of portaaltoegang wel succesvol, maar is de firewall-regel voor het eigenlijke gebruikersverkeer verkeerd?

Bij Remote Access moet je gebruikersprobleem en VPN-probleem scheiden. Een gebruiker kan zich succesvol aanmelden, maar toch geen interne toepassing bereiken als VPN-pool, firewall-regel, NAT of routing niet kloppen. Voor AD-basisprincipes past Active Directory toevoegen aan Sophos Firewall, voor Entra-gebaseerde Remote-Access-scenario’s Microsoft Entra ID SSO voor Sophos Connect en VPN Portal. Als de gebruiker via Captive Portal met Entra ID SSO is aangemeld, past Microsoft Entra ID SSO voor Sophos Firewall Captive Portal instellen.

Gebruikerslogin en regelmatching scheiden

Een succesvolle login op het VPN Portal, User Portal, Captive Portal of via Microsoft Entra ID SSO bewijst nog niet dat de geplande gebruikersregel het eigenlijke verkeer matcht. De login bevestigt eerst alleen de authenticatie. Daarna moet de firewall de gebruiker, de bron-IP, de groep en de traffic-flow correct samenbrengen.

Voor de analyse moet je daarom apart controleren:

• Gebruiker meldt zich aan, regelcounter blijft 0: VPN-pool, bronzone, bronnetwerk, groepsvoorwaarde of regelpositie controleren
• Gebruikersveld in Log Viewer is leeg: STAS, Captive Portal, AD SSO, Entra ID SSO of clientloze gebruiker controleren
• Gebruiker is zichtbaar, maar verkeerde regel is van toepassing: Regelvolgorde, groepsfilter of algemenere regel bovenaan controleren
• Alleen VPN-gebruikers zijn getroffen: Zone VPN, VPN-pool, SSL/IPsec-configuratie en Sophos Connect-profiel controleren
• Alleen individuele gebruikers zijn getroffen: UPN, e-mailadres, geïmporteerde groep en firewall-groep vergelijken

Bij lokale AD-omgevingen helpen STAS en Active Directory toevoegen aan Sophos Firewall. Bij Entra-gebaseerde setups moet je afhankelijk van het loginpad Microsoft Entra ID SSO voor Sophos Connect en VPN Portal of Entra ID SSO voor Captive Portal meerekenen. Als er veel gebruikers of clientloze gebruikers betrokken zijn, kan daarnaast de Sophos Firewall User-ID-limiet relevant worden.

Routing en SD-WAN controleren

Als de regel matcht, maar de verbinding niet werkt, kan routing het probleem zijn.

Daarbij controleer je:

• Is er een passende standaardroute?
• Is er een statische route?
• Is er een SD-WAN-route van toepassing?
• Is de gateway actief?
• Zijn er retourroutes op het doelsysteem of in het externe netwerk?
• Is het retourpad symmetrisch?
• Gaat verkeer via VPN, MPLS of een andere interface dan verwacht?

Belangrijk: De Policy Tester dekt SD-WAN-routing niet volledig af. Hij is zeer nuttig voor firewall-, SSL/TLS- en webbeleidbeslissingen, maar vervangt geen echte pakketstroomtest.

Meer hierover: Routing-prioriteit op Sophos Firewall aanpassen.

Logging activeren

Zonder logs wordt troubleshooting moeizaam. Je controleert twee plekken:

1. In de firewall-regel moet Log firewall traffic geactiveerd zijn.
2. Onder System services > Log settings moet het passende logtype lokaal, voor Sophos Central of voor Syslog geactiveerd zijn.

De Log Viewer toont firewall-sessies meestal wanneer de firewall een verbinding beëindigt en een Destroy-event ontvangt. Als een internetverbinding gewoon wegvalt, kan het zijn dat niet elke sessie verschijnt zoals je verwacht.

De Log Viewer open je rechtsboven in de WebAdmin-console. Zinvolle filters zijn:

• Bron IP
• Bestemming IP
• Poort of service
• Rule ID
• Regelnaam
• Actie
• Gebruiker
• NAT rule ID

Meer hierover: Sophos Firewall Troubleshooting: Services en Logs.

Packet Capture gebruiken

Als Log Viewer en regelcounter niet voldoende zijn, gebruik je Diagnostics > Packet capture.

De belangrijkste vraag is of het pakket aankomt, wordt doorgestuurd of al op de firewall blijft hangen.

• Geen pakket komt aan: Probleem ligt voor de firewall: client, switch, VLAN, gateway, provider, cloud security group
• Pakket komt binnen, gaat maar niet uit: Firewall-regel, NAT, routing of beveiligingsfunctie controleren
• Pakket gaat uit, maar geen antwoord komt terug: Retourroute, doelsysteem, NAT of externe blokkade controleren
• Pakket wordt met Violation weergegeven: Beleid of beveiligingsfunctie blokkeert
• Pakket toont NAT ID en Rule ID: Regel- en NAT-treffers gericht vergelijken

Meer hierover: Packet Capture Tool in WebAdmin gebruiken.

Niet meerdere dingen tegelijk wijzigen

Bij regelproblemen is het verleidelijk om positie, service, NAT, webbeleid en routing tegelijk aan te passen. Dit lost soms op korte termijn de toegang op, maar maakt de oorzaak later moeilijk te achterhalen.

Beter is een stapsgewijze aanpak:

1. Beginstand noteren: Rule ID, NAT ID, bron, bestemming, service, tijdstip.
2. Precies één wijziging doorvoeren.
3. Test met dezelfde bron-IP en hetzelfde doel herhalen.
4. Log Viewer en Packet Capture opnieuw vergelijken.
5. Resultaat documenteren.
6. Pas daarna de volgende wijziging overwegen.

Voor productieve regels moet bovendien duidelijk zijn of een wijziging permanent is of alleen als testregel dient. Tijdelijke regels moeten een eigenaar en een vervaldatum hebben, anders blijven ze vaak jarenlang in het regelwerk.

Beveiligingsfuncties afzonderlijk controleren

Als de regel matcht, maar de toepassing niet werkt, kan een beveiligingsprofiel ingrijpen:

• Webbeleid
• SSL/TLS-inspectieregel
• Decryptieprofiel
• IPS-beleid
• Toepassingscontrole
• Malware-scan
• Zero-day-bescherming
• Security Heartbeat
• Traffic Shaping

Voor tests kun je niet alles zomaar permanent uitschakelen. Beter is: kort gericht controleren, Log Viewer observeren en daarna de oorzaak netjes oplossen. Bij TLS Inspection helpt het artikel TLS Inspection op Sophos Firewall stapsgewijs uitrollen.

Bij productieve regels moet je beveiligingsfuncties niet als een blok beschouwen. Beter is om één module na de andere af te bakenen:

• Webcategorie of URL wordt geblokkeerd: Webbeleid, categorie, uitzondering en Log Viewer controleren
• Toepassing wordt verkeerd herkend: Toepassingscontrole en IPS-log controleren
• HTTPS-pagina laadt alleen zonder inspectie: SSL/TLS-inspectieregel, CA-distributie, decryptieprofiel en uitzonderingen controleren
• Verbinding verbreekt bij grote gegevens: MTU/MSS, VPN-pad, fragmentatie en Packet Capture controleren
• Treffer in IPS of Zero-day Protection: Handtekening, beleid, doelsysteem en false-positive-risico beoordelen
• Alleen individuele gebruikers getroffen: Gebruikersmatching, Security Heartbeat, groep en authenticatie controleren

Als voor een test een beveiligingsprofiel wordt verwijderd, moet de wijziging nauwkeurig worden beperkt: alleen de getroffen bron, alleen het specifieke doel, alleen voor de testperiode. Daarna wordt de oorspronkelijke beveiligingswerking hersteld of een gerichte uitzondering gedocumenteerd.

Wijzigingsgeschiedenis controleren

Een regel kan ook niet meer matchen omdat er op de achtergrond iets is gewijzigd. Dat hoeft niet altijd de regel zelf te zijn.

• Regel werkte eerder: Audit logs en laatste wijziging controleren
• Objecten gewijzigd: Hosts, services, zones, groepen en FQDN vergelijken
• Wijziging via Sophos Central: Task Queue en uitrolstatus controleren
• Meerdere admins werken parallel: Eigenaar, ticket en wijzigingstijd verduidelijken
• Probleem ontstaat na restore of import: Configuratie, interfaces, zones en NAT vergelijken

Voor het volgen van wijzigingen helpen Sophos Firewall Audit Trail Logs controleren en Sophos Firewall Config Studio gebruiken. Als de wijziging uit Sophos Central komt, moet aanvullend de Sophos Central Firewall Management Task Queue worden gecontroleerd.

Praktische aanpak en typische oorzaken

De meeste matchingproblemen zijn snel te beperken met een vaste troubleshootingvolgorde.

Veelvoorkomende oorzaken

• Regelcounter blijft 0: Regelpositie, bronzone, doelzone of service verkeerd
• Log toont andere regel: Algemenere regel staat erboven
• Geen log zichtbaar: Logging niet actief of verkeer bereikt firewall niet
• DNS werkt, web niet: Service, webbeleid, TLS-inspectie of QUIC controleren
• Hostnaam klopt, maar doel-IP anders: DNS, FQDN-object, Split DNS, CDN of IPv6 controleren
• HTTPS wordt niet gescand: Geen passende SSL/TLS-inspectieregel of CA niet verspreid
• DNAT werkt niet: Firewall-regel gebruikt verkeerde doelzone of verkeerd bestemmingsnetwerk
• VPN-verkeer matcht niet: Zone VPN, route, tunnelinterface of XFRM-context controleren
• Alleen sommige gebruikers getroffen: Gebruikersmatching, groep, SSO, Captive Portal of Heartbeat controleren

Praktische procedure

1. Probleem met bron-IP, bestemming, poort, gebruiker en tijdstip noteren.
2. Regelpositie controleren.
3. Regelcounter resetten.
4. Test reproduceren.
5. Log Viewer met bron-IP en bestemming-IP filteren.
6. NAT-regel en routing controleren.
7. Packet Capture met strakke filter starten.
8. Beveiligingsprofiel alleen gericht controleren.
9. Wijziging documenteren.

Voor een gecombineerde testprocedure zie Firewall-regel testen met Log Viewer, Policy Test en Packet Capture.

Checklist voor regeltroubleshooting

• Concreet testgeval met bron, bestemming, service, gebruiker en tijdstip gedefinieerd.
• Regelpositie gecontroleerd en regelcounter voor de test gereset.
• Log Viewer toont de verwachte Rule ID of een begrijpelijke andere regel.
• DNS-resolutie, daadwerkelijke doel-IP en IP-versie zijn met het testgeval vergeleken.
• Bij DNAT zijn doelzone na NAT en bestemmingsnetwerk voor NAT correct ingesteld.
• NAT Rule ID is gecontroleerd als NAT betrokken is.
• Verkeer naar de firewall zelf is gescheiden van verkeer door de firewall.
• Gebruikersmatching is alleen beoordeeld als de gebruiker zichtbaar is in de Log Viewer.
• Bij gebruikersregels zijn login, gebruikerskoppeling en eigenlijke regelbeslissing apart beoordeeld.
• Routing, SD-WAN, gateway en retourpad zijn gecontroleerd.
• Packet Capture toont Incoming, Forwarded, Violation of ontbrekend antwoord begrijpelijk.
• Beveiligingsfuncties zijn afzonderlijk gecontroleerd en niet permanent algemeen uitgeschakeld.
• Testwijzigingen zijn gedocumenteerd en tijdelijke regels hebben eigenaar en vervaldatum.

FAQ