Sophos Firewall-regel matchar inte: Kontrollera orsaker

Om en brandväggsregel inte matchar, är det sällan brandväggen som är “trasig”. Oftast stämmer inte en förutsättning, en mer allmän regel står ovanför, NAT förändrar synen på trafiken, användarmatchning är inte uppfylld eller loggning är inte korrekt aktiverad.

Denna checklista hjälper dig att gå systematiskt tillväga istället för att slumpmässigt ändra regler.

Orientering

Börja med ett tydligt testfall innan regler eller säkerhetsfunktioner ändras.

Vilken artikel passar?

Regelproblem överlappar snabbt med NAT, routing, VPN, Device Access eller säkerhetsfunktioner. För analysen bör det först vara klart vilken nivå som är berörd:

• Förstå en brandväggsregel från grunden: Förstå och konfigurera Sophos Firewall-regler korrekt
• Testa enskild anslutning med Log Viewer, Policy Tester och Packet Capture: Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture
• NAT, SNAT, DNAT, MASQ eller PAT är inblandat: Förstå NAT på Sophos Firewall
• En server publiceras från internet via DNAT: Publicera server via DNAT
• Åtkomst går till WebAdmin, VPN Portal, SSH, DNS eller SNMP på brandväggen: Konfigurera Device Access korrekt
• Rutt, SD-WAN eller returväg är oklar: Anpassa routing-prioritet på Sophos Firewall
• Paket måste kontrolleras direkt på brandväggen: Använd Packet Capture i WebAdmin

Denna uppdelning är viktig eftersom en brandväggsregel inte styr alla typer av åtkomst. Lokala tjänster på brandväggen, NAT-beslut, routing och säkerhetsfunktioner har egna kontrollpunkter.

Snabb avgränsning

I början bör man inte omedelbart flytta regler eller ändra objekt. Först avgränsas var trafiken förloras.

• Regelräknare förblir 0: Regelposition, zon, källa, destination, tjänst eller schema stämmer inte
• Log Viewer visar en annan regel: En mer allmän eller automatiskt genererad regel står högre upp
• Log Viewer visar ingenting: Loggning saknas eller trafiken når inte brandväggen
• Packet Capture ser inget paket: Problem ligger före brandväggen: klient, VLAN, switch, gateway, leverantör eller molnsäkerhetsgrupp
• Packet Capture ser paket, men ingen vidarebefordran: Brandväggsregel, NAT, routing eller säkerhetsfunktion blockerar
• Packet Capture ser vidarebefordran, men inget svar: Kontrollera returväg, målsystem, NAT eller extern brandvägg

Denna uppdelning sparar tid. Om brandväggen inte ser något paket hjälper ingen ändring av en brandväggsregel. Om Log Viewer visar en annan Rule ID är ordningen viktigare än den berörda målregeln. Om paketflöde och Rule ID stämmer, flyttas analysen till NAT, returväg eller säkerhetsfunktioner.

Definiera testfall tydligt

En regel kan bara testas meningsfullt om testfallet är tydligt. Uttalanden som “Internet fungerar inte” eller “VPN fungerar inte” är för breda. För felsökning behövs ett konkret flöde.

Innan testet bör följande vara klart:

• Source IP: Klient 10.10.20.35
• Source zone: LAN, VPN, DMZ eller anpassad zon
• User: autentiserad användare eller ingen användarmatchning
• Destination: Server-IP, FQDN, offentlig IP eller WAN-objekt
• Service: TCP 443, UDP 53, ICMP, anpassad tjänst
• Förväntad regel: Regelnamn eller Rule ID, om känd
• Förväntad NAT-regel: NAT Rule ID eller regelnamn, om NAT är inblandad
• Testtid: exakt tid för Log Viewer och senare loggfiler

Därefter upprepas alltid samma test. Om Source-IP, mål, DNS-upplösning eller port ändras under analysen jämförs inte längre samma fall.

Kombinera analysverktyg korrekt

Sophos Firewall erbjuder flera verktyg som besvarar olika frågor. Inget av dem är ensamt ett fullständigt bevis.

• Regelräknare: Träffar den nya testtrafiken regeln i grunden? Visar inte varför en applikation ändå misslyckas
• Log Viewer: Vilken Rule ID, NAT Rule ID, Action, User eller säkerhetsfunktion loggades? Beror på loggning och sessionens slut
• Policy Tester: Vilken policy-logik skulle gälla för ett definierat flöde? Ersätter inget verkligt paketflöde och avbildar inte SD-WAN fullständigt
• Packet Capture: Kommer paket fram, vidarebefordras de eller slängs de? Förklarar inte varje applikationsnivå och behöver snäva filter
• Service-Logs: Har en modul som Web, IPS, autentisering eller VPN ett eget problem? Endast meningsfullt när den berörda tjänsten är avgränsad

För en hållbar bedömning kombinerar man minst Log Viewer och ett verkligt test. Vid motstridiga resultat är Packet Capture oftast nästa steg, eftersom det visar om paket faktiskt kommer fram och vidarebefordras.

Beslutsdiagram för första testet

För den första analysen räcker ofta ett kort beslutsdiagram. Det förhindrar att man omedelbart arbetar med regler, NAT och routing samtidigt.

• Packet Capture ser inget paket: Kontrollera klient, VLAN, switch, gateway, leverantör, molnsäkerhetsgrupp eller föregående brandvägg
• Packet Capture ser paket, Log Viewer förblir tom: Kontrollera loggning, loggtyp, sessionens slut och lämplig BPF-filter
• Log Viewer visar annan Rule ID: Jämför regelordning, zoner, källa, destination, tjänst och schema
• Firewall Rule ID stämmer, NAT Rule ID stämmer inte: Kontrollera NAT-ordning och Original-fält
• Rule ID och NAT ID stämmer, men inget svar kommer tillbaka: Kontrollera returväg, målsystem, lokal brandvägg på servern eller extern blockering
• Regel matchar inte för vissa användare: Kontrollera användarmatchning, grupp, autentisering och klientlösa användare

Därmed förblir analysen kontrollerad: Först bevisas om trafiken når brandväggen. Därefter kontrolleras vilken regel och vilken NAT-regel som verkligen matchar. Först när dessa två punkter stämmer, är det värt att söka vid returväg, säkerhetsfunktioner eller applikationsnivå.

Förstå regelmatchning

Sophos Firewall behandlar regler i ordning. Den första lämpliga regeln vinner.

Första principen: Den första matchande regeln vinner

Sophos Firewall bearbetar brandväggsregler uppifrån och ner. Så snart en regel matchar, kontrolleras inte efterföljande regler längre. Samma grundprincip gäller även för NAT-regler.

Viktigt:

• Positionen i listan avgör utvärderingen.
• Rule ID är bara en referens och säger inget om den aktuella ordningen.
• Regelgrupper hjälper till med översikten, men är ingen egen matchningslogik.
• En allmän regel ovanför kan helt “sluka” en specifik regel nedanför.

Om en regel inte matchar, kontrollerar man därför först positionen.

Återställ regelräknare

Vid oklara träffar hjälper det att återställa regelräknaren.

1. Öppna Rules and policies > Firewall rules.
2. Sök efter den berörda regeln.
3. Öppna trepunktsmenyn.
4. Välj Reset data transfer count.
5. Reproducera trafiken igen.
6. Kontrollera räknaren efter testet.

Om räknaren inte ökar, matchar inte regeln. Om den ökar men applikationen ändå inte fungerar, ligger problemet snarare hos säkerhetsprofiler, NAT, routing, returväg eller målsystem.

Kontrollera matchningsfält

En brandväggsregel matchar bara om alla relevanta kriterier stämmer.

• Source zones: Fel zon, VLAN ligger i annan zon, VPN-trafik kommer från VPN
• Source networks and devices: Fel objekt, fel IP, värdgrupp ofullständig
• Destination zones: Fel målzon, särskilt vid DNAT eller VPN
• Destination networks: Förväxling av före-NAT och efter-NAT-syn
• Services: Port saknas, TCP/UDP förväxlas, applikation använder tilläggsportar
• Users or groups: Användaren är inte autentiserad eller fel grupp
• Schedule: Schema passar inte för närvarande
• Exclusions: Trafik undantas från regeln och behandlas vidare nedanför

Vid webtrafik bör man dessutom kontrollera om QUIC är aktivt. Om webbläsare skickar trafik över UDP 443, matchar vissa webbfilter- och skanningsförväntningar annorlunda än vid klassisk HTTPS över TCP.

Mer om detta: Sophos Firewall och QUIC-protokollet.

DNS, FQDN och IPv6 får inte förbises

En regel kan se korrekt ut och ändå inte matcha om klienten når ett annat mål än förväntat. Detta händer ofta med FQDN-objekt, Split DNS, CDN-tjänster, IPv6 eller applikationer som använder flera mål parallellt.

Innan regeländringar bör man därför kontrollera:

• Vilken IP löser klienten verkligen upp?: DNS-cache, Split DNS eller en annan resolver kan ge en annan adress än förväntat.
• Är det IPv4 eller IPv6?: IPv4-regler matchar inte IPv6-trafik. Om klienter föredrar IPv6 måste IPv6-sidan kontrolleras separat.
• Används en FQDN-värd i brandväggen?: Brandväggen måste lösa upp FQDN och känna till den aktuella mål-IP:n. CDN- eller molntjänster kan leverera flera växlande IP-adresser.
• Använder applikationen ytterligare mål?: Inloggning, API, uppdateringar, telemetri eller mediebanor kan använda andra domäner och portar än huvudapplikationen.
• Använder en intern klient det offentliga namnet på en intern tjänst?: Då är Split DNS, Loopback NAT eller en felaktig offentlig upplösning möjliga orsaker.

För felsökning är det avgörande att inte bara notera värdnamnet, utan att jämföra den faktiskt använda mål-IP:n i Log Viewer eller Packet Capture. Om en regel pekar på ett specifikt FQDN- eller värdobjekt, men klienten använder en annan IP, kommer regeln inte att matcha.

Vid interna namnupplösningar hjälper rena DNS request routes. Förloppet beskrivs i Ställ in DNS Request Routes på Sophos Firewall. Om IPv6 är aktivt i miljön bör man dessutom kontrollera om IPv6 är medvetet planerat och om rätt policy finns. Grunderna finns i Ställ in IPv6 Prefix Delegation på Sophos Firewall.

Ett vanligt specialfall är FQDN-objekt. Om klienter föredrar IPv6, men en regel bara använder IPv4-objekt eller en FQDN-host med IPv4-upplösning, matchar det faktiska IPv6-flödet inte. Regeln ser tekniskt rätt ut, men behandlar inte trafiken som faktiskt går på nätet. I sådana fall bör DNS-svar, IP-version och policy kontrolleras separat.

Trafik till brandväggen själv är ett specialfall

Inte varje åtkomst till en Sophos Firewall styrs av vanliga brandväggsregler. Om klienten ska nå brandväggen själv, till exempel WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS eller SNMP, är Device Access och Local service ACL avgörande.

Typiska exempel:

• WebAdmin från LAN eller WAN: Device Access, Local service ACL, MFA, admin-behörighet
• VPN Portal eller User Portal: Device Access, portal-konfiguration, användarbehörighet
• SSH till brandväggen: Device Access, Local service ACL, admin-rättigheter, källnät
• SSL VPN eller IPsec-inloggning: Device Access för rätt zon, VPN-konfiguration, autentisering
• DNS till brandväggen: Device Access, DNS-konfiguration, förfrågningsväg
• SNMP till brandväggen: Device Access, SNMP-konfiguration, övervakningskälla

Om en brandväggsregel inte matchar för sådan trafik är det ofta inget fel på regeln. Trafiken slutar på brandväggen och behandlas som en lokal tjänst. För att härda dessa tjänster är Säkra åtkomst till Sophos Firewall: Konfigurera Device Access korrekt den centrala artikeln. För portaler passar dessutom Översikt över Sophos-portaler.

Kontrollera NAT, DNAT och ID:n

För DNAT-trafik måste brandväggsregler och NAT-regler läsas tillsammans.

Läs DNAT korrekt

Vid DNAT är synen i brandväggsregler särskilt viktig. Som tumregel kan man komma ihåg:

Brandväggsregler för DNAT-trafik använder målzonen efter NAT, men mål-IP:n före NAT.

Exempel:

• Extern klient ansluter till brandväggens WAN-IP.
• NAT översätter till en intern server i DMZ.
• Brandväggsregeln använder som Destination zone zonen för den interna servern, alltså till exempel DMZ.
• Destination network förblir dock den offentliga IP:n eller WAN-objektet som klienten kontaktade.

Om denna kombination är felaktig kan NAT-regeln se korrekt ut, men brandväggsregeln matchar ändå inte.

Mer om detta: Publicera server via DNAT på Sophos Firewall.

Kontrollera NAT-regler

NAT tillåter ingen trafik. NAT översätter bara. Det behövs alltid en passande brandväggsregel.

Under Rules and policies > NAT rules bör man kontrollera:

• Står den passande NAT-regeln ovanför mer allmänna NAT-regler?
• Är regeln aktiv?
• Stämmer Original source, destination och service?
• Stämmer Translated source, destination och service?
• Används MASQ eller en fast SNAT-IP?
• Finns det en Linked NAT Rule som oväntat matchar?
• Finns det en generisk SNAT-regel som matchar före en mer specifik regel?

Sophos rekommenderar för enkla miljöer oftast fristående NAT-regler istället för att skapa en Linked NAT Rule per brandväggsregel.

Mer om detta: Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Läs Firewall Rule ID och NAT Rule ID tillsammans

Om NAT är inblandat räcker inte frågan “Vilken brandväggsregel matchar?”. En anslutning kan träffa den förväntade Firewall Rule ID, men ändå gå över en felaktig NAT Rule ID. Omvänt kan en NAT-regel se korrekt ut, medan en mer allmän brandväggsregel ovanför redan behandlar trafiken.

För testet bör man därför i förväg notera:

• Förväntad Firewall Rule ID: Visar om rätt brandväggsregel tillåter eller blockerar trafiken
• Förväntad NAT Rule ID: Visar om rätt SNAT-, DNAT-, MASQ- eller PAT-regel översätter
• Faktiska ID:n i Log Viewer: Bevisar om brandväggen behandlar flödet som planerat
• ID:n i Packet Capture: Hjälper om Log Viewer verkar ofullständig eller returvägen är oklar

Tolkningen är relativt enkel, men sparar mycket söktid:

• Firewall Rule ID stämmer, NAT Rule ID är fel: Kontrollera NAT-ordning, Original-fält och mer allmänna NAT-regler
• NAT Rule ID stämmer, Firewall Rule ID är fel: Kontrollera brandväggsregelordning, zoner, källa, destination och tjänst
• Båda ID:n stämmer, men anslutningen misslyckas ändå: Kontrollera returväg, målserver, säkerhetsfunktion eller applikation
• Ingen NAT Rule ID synlig, trots att NAT förväntas: Kontrollera testflöde, NAT-kriterier, riktning och loggning igen

Viktigt är att inte omedelbart bygga om båda regelverken samtidigt. Först avgörs om problemet ligger i brandväggsmatchning eller NAT-matchning. Först därefter bör man ändra en konkret regelposition, ett objekt eller ett fält. Den mer detaljerade NAT-utvärderingen finns i avsnittet Läs Firewall Rule ID och NAT Rule ID korrekt.

Kontrollera användare, routing och säkerhetsfunktioner

User Matching, routing, NAT, loggning och säkerhetsprofiler kan påverka om en regel matchar.

Kontrollera användarmatchning och autentisering

Regler med användar- eller gruppmatchning ser ofta korrekta ut, men matchar bara om brandväggen verkligen kan tilldela användaren till trafiken vid det tillfället.

Att kontrollera:

• Är användaren synlig i Log Viewer?
• Kommer trafiken från den förväntade enheten eller från en annan klient?
• Är användaren i rätt brandväggsgrupp?
• Fungerar AD SSO, STAS, Captive Portal, RADIUS eller Entra ID SSO?
• Matchar en regel utan användarmatchning ovanför den planerade användarregeln?
• Finns det klientlösa användare som behandlas annorlunda?
• Är MFA eller portalåtkomst framgångsrik, men brandväggsregeln för den faktiska användartrafiken felaktig?

Vid fjärråtkomst bör man skilja mellan användarproblem och VPN-problem. En användare kan logga in framgångsrikt men ändå inte nå en intern applikation om VPN-pool, brandväggsregel, NAT eller routing inte stämmer. För AD-grunder passar Lägg till Active Directory på Sophos Firewall, för Entra-baserade fjärråtkomstscenarier Microsoft Entra ID SSO för Sophos Connect och VPN Portal. Om användaren loggar in via Captive Portal med Entra ID SSO, passar Ställ in Microsoft Entra ID SSO för Sophos Firewall Captive Portal.

Separera användarinloggning och regelmatchning

En lyckad inloggning på VPN Portal, User Portal, Captive Portal eller via Microsoft Entra ID SSO bevisar inte att den planerade användarregeln matchar den faktiska trafiken. Inloggningen bekräftar först bara autentiseringen. Därefter måste brandväggen korrekt koppla användaren, käll-IP, grupp och trafikflöde.

För analysen bör man därför separat kontrollera:

• Användaren loggar in, regelräknaren förblir 0: Kontrollera VPN-pool, Source zone, Source network, gruppvillkor eller regelposition
• User-fältet i Log Viewer är tomt: Kontrollera STAS, Captive Portal, AD SSO, Entra ID SSO eller klientlösa användare
• Användaren är synlig, men fel regel matchar: Kontrollera regelordning, gruppfilter eller mer allmän regel ovanför
• Endast VPN-användare är berörda: Kontrollera zon VPN, VPN-pool, SSL/IPsec-konfiguration och Sophos Connect-profil
• Endast enskilda användare är berörda: Jämför UPN, e-postadress, importerad grupp och brandväggsgrupp

Vid lokala AD-miljöer hjälper STAS och Lägg till Active Directory på Sophos Firewall. Vid Entra-baserade uppsättningar bör man beroende på inloggningsväg kontrollera Microsoft Entra ID SSO för Sophos Connect och VPN Portal eller Entra ID SSO för Captive Portal. Om många användare eller klientlösa användare är inblandade kan dessutom Sophos Firewall User-ID-Limit bli relevant.

Kontrollera routing och SD-WAN

Om regeln matchar men anslutningen inte fungerar kan routing vara problemet.

Då kontrollerar man:

• Finns det en passande standardrutt?
• Finns det en statisk rutt?
• Matchar en SD-WAN-rutt?
• Är gatewayen aktiv?
• Finns det returvägar på målsystemet eller i det avlägsna nätverket?
• Är returvägen symmetrisk?
• Går trafiken över VPN, MPLS eller ett annat gränssnitt än förväntat?

Viktigt: Policy Tester avbildar inte SD-WAN-routing fullständigt. Den är mycket hjälpsam för brandväggs-, SSL/TLS- och webbpolicybeslut, men ersätter inget verkligt paketflödestest.

Mer om detta: Anpassa routing-prioritet på Sophos Firewall.

Aktivera loggning

Utan loggar blir felsökning mödosam. Man kontrollerar två ställen:

1. I brandväggsregeln måste Log firewall traffic vara aktiverat.
2. Under System services > Log settings måste rätt loggtyp vara aktiverad lokalt, för Sophos Central eller för Syslog.

Log Viewer visar vanligtvis brandväggssessioner när brandväggen avslutar en anslutning och får ett Destroy-händelse. Om en internetanslutning bara bryts kan det hända att inte varje session visas som man förväntar sig.

Log Viewer öppnas uppe till höger i WebAdmin-konsolen. Användbara filter är:

• Source IP
• Destination IP
• Port eller tjänst
• Rule ID
• Regelnamn
• Åtgärd
• Användare
• NAT rule ID

Mer om detta: Sophos Firewall Troubleshooting: Services och Logs.

Använd Packet Capture

Om Log Viewer och regelräknare inte räcker använder man Diagnostics > Packet capture.

Den viktigaste frågan är om paketet kommer fram, vidarebefordras eller redan fastnar på brandväggen.

• Inget paket kommer fram: Problem ligger före brandväggen: klient, switch, VLAN, gateway, leverantör, molnsäkerhetsgrupp
• Paket kommer in, men går inte ut: Kontrollera brandväggsregel, NAT, routing eller säkerhetsfunktion
• Paket går ut, men inget svar kommer tillbaka: Kontrollera returväg, målsystem, NAT eller extern blockering
• Paket visas med Violation: Policy eller säkerhetsfunktion blockerar
• Paket visar NAT ID och Rule ID: Jämför regel- och NAT-träffar specifikt

Mer om detta: Använd Packet Capture Tool i WebAdmin.

Ändra inte flera saker samtidigt

Vid regelproblem är det frestande att samtidigt justera position, tjänst, NAT, webbpolicy och routing. Det löser ibland åtkomsten kortsiktigt, men gör orsaken svår att förstå senare.

Bättre är ett steg-för-steg-förfarande:

1. Notera utgångsläget: Rule ID, NAT ID, Source, Destination, Service, tid.
2. Gör exakt en ändring.
3. Upprepa testet med samma Source IP och samma mål.
4. Jämför Log Viewer och Packet Capture igen.
5. Dokumentera resultatet.
6. Först därefter kontrollera nästa ändring.

För produktiva regler bör det dessutom vara klart om en ändring är permanent eller bara en testrule. Tillfälliga regler bör ha en ägare och ett utgångsdatum, annars blir de ofta kvar i regelverket i åratal.

Kontrollera säkerhetsfunktioner individuellt

Om regeln matchar men applikationen inte fungerar kan en skyddsprofil ingripa:

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

För tester kan man inte generellt inaktivera allt permanent. Bättre är: kontrollera kort och specifikt, observera Log Viewer och åtgärda sedan orsaken korrekt. Vid TLS Inspection hjälper artikeln Rulla ut TLS Inspection på Sophos Firewall stegvis.

För produktiva regler bör man inte betrakta säkerhetsfunktioner som ett samlingsblock. Bättre är att avgränsa en modul i taget:

• Webbkategori eller URL blockeras: Kontrollera Web Policy, kategori, undantag och Log Viewer
• Applikation identifieras felaktigt: Kontrollera Application Control och IPS-logg
• HTTPS-sida laddas bara utan inspektion: Kontrollera SSL/TLS inspection rule, CA-distribution, Decryption Profile och undantag
• Anslutning bryts vid stora data: Kontrollera MTU/MSS, VPN-väg, fragmentering och Packet Capture
• Träffar i IPS eller Zero-day Protection: Utvärdera signatur, policy, målsystem och falskt positiv-risk
• Endast enskilda användare berörs: Kontrollera användarmatchning, Security Heartbeat, grupp och autentisering

Om en skyddsprofil tas bort för en test bör ändringen vara strikt begränsad: endast den berörda källan, endast det specifika målet, endast för testperioden. Därefter återställs det ursprungliga skyddet eller ett specifikt undantag dokumenteras.

Kontrollera ändringshistorik

Om en regel fungerade igår men inte längre fungerar idag bör man inte bara kontrollera det aktuella regelinnehållet. Ofta har ett objekt, en regelposition, en NAT-regel, en grupp, en tjänst eller en Central-policy ändrats strax innan.

Praktiska kontroller:

• Har brandväggsregeln själv ändrats?: Audit Trail, Config Studio, regelbeskrivning
• Har ett använt objekt ändrats?: Hosts and services, Audit Trail, Config Studio
• Har regelpositionen flyttats?: Brandväggsregellista, Audit Trail
• Har en Central-policy skickats ut?: Sophos Central Task Queue och lokal brandväggsvy
• Har en NAT-regel eller SD-WAN-route ändrats?: NAT-regler, routing, Audit Trail, Packet Capture

För spårbarhet passar Kontrollera Sophos Firewall Audit Trail Logs och Använd Sophos Firewall Config Studio. Om ändringen kommer från Sophos Central bör även Sophos Central Firewall Management Task Queue kontrolleras.

Praktiskt förlopp och typiska orsaker

De flesta matchningsproblem kan snabbt avgränsas med en fast felsökningssekvens.

Vanliga orsaker

• Regelräknare förblir 0: Regelposition, Source zone, Destination zone eller Service felaktig
• Log visar annan regel: Mer allmän regel står ovanför
• Ingen logg synlig: Loggning inte aktiv eller trafik når inte brandväggen
• DNS fungerar, webb inte: Kontrollera Service, Web Policy, TLS Inspection eller QUIC
• Värdnamn stämmer, men mål-IP annorlunda: Kontrollera DNS, FQDN-objekt, Split DNS, CDN eller IPv6
• HTTPS skannas inte: Ingen passande SSL/TLS inspection rule eller CA inte distribuerad
• DNAT fungerar inte: Brandväggsregel använder fel Destination zone eller fel Destination network
• VPN-trafik matchar inte: Kontrollera zon VPN, rutt, tunnelgränssnitt eller XFRM-kontekst
• Endast vissa användare berörs: Kontrollera användarmatchning, grupp, SSO, Captive Portal eller Heartbeat

Praktiskt förlopp

1. Notera problem med Source IP, Destination, Port, User och tid.
2. Kontrollera regelposition.
3. Återställ regelräknare.
4. Reproducera test.
5. Filtrera Log Viewer med Source IP och Destination IP.
6. Kontrollera NAT-regel och routing.
7. Starta Packet Capture med snävt filter.
8. Kontrollera säkerhetsprofil endast specifikt.
9. Dokumentera ändring.

För en kombinerad testprocedur, se Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Checklista för regel-felsökning

• Konkreta testfall med Source, Destination, Service, User och tid definierade.
• Regelposition kontrollerad och regelräknare återställd för testet.
• Log Viewer visar förväntad Rule ID eller en begriplig annan regel.
• DNS-upplösning, faktisk mål-IP och IP-version har jämförts med testfallet.
• Vid DNAT är målzon efter NAT och Destination network före NAT korrekt inställda.
• NAT Rule ID har kontrollerats om NAT är inblandad.
• Trafik till brandväggen själv har separerats från trafik genom brandväggen.
• Användarmatchning har endast bedömts om användaren är synlig i Log Viewer.
• Vid användarregler har inloggning, användartilldelning och faktisk regelbeslut bedömts separat.
• Routing, SD-WAN, gateway och returväg har kontrollerats.
• Packet Capture visar Incoming, Forwarded, Violation eller saknad svar begripligt.
• Säkerhetsfunktioner har kontrollerats individuellt och inte permanent inaktiverats generellt.
• Teständringar är dokumenterade och tillfälliga regler har ägare och utgångsdatum.

FAQ