Sophos Firewall-regel matchar inte: kontrollera orsaker

När en Sophos Firewall-regel inte matchar ska regler inte flyttas eller objekt utökas som första åtgärd. Först reproduceras och observeras ett enskilt dataflöde: kommer paketet fram, vilka Firewall Rule ID och NAT Rule ID behandlar det, vidarebefordras det och kommer ett svar tillbaka?

Oftast visar det sig att ett villkor ser annorlunda ut än förväntat, att en mer generell regel högre upp matchar eller att problemet uppstår först efter regelbeslutet. Själva firewallen är betydligt mer sällan orsaken än ett oprecist definierat test.

Snabbt beslut: Om en korrekt startad och filtrerad Packet Capture inte visar något paket kontrolleras först klienten, VLAN, gateway eller den föregående sökvägen. En annan Rule ID leder till regelordning och matchning. Om Rule ID och NAT ID stämmer fortsätter analysen med routing, returväg, målsystem eller säkerhetsmodul.

Snabb väg: följ ett konkret flöde

För den första avgränsningen räcker sex steg:

1. Definiera testflödet: Anteckna Source IP, Source zone, User, Destination, protokoll, port och tidpunkt.
2. Bekräfta inkommande trafik: Starta Packet Capture med ett snävt Capture Filter och utlös samma flöde.
3. Kontrollera Firewall Rule ID: Jämför i Log Viewer eller Packet Capture med den förväntade regeln.
4. Kontrollera NAT Rule ID: Om NAT används kontrolleras den faktiska NAT-regeln och dess översättning.
5. Kontrollera vidarebefordran och svar: Sök efter Forwarded, utgående gränssnitt och returpaket.
6. Fördjupa först därefter: Undersök routing, SD-WAN, User Matching, TLS Inspection, IPS, Web Policy eller målsystemet.

Detta arbetssätt håller lagren åtskilda. En firewallregel beslutar om åtkomst och skyddsfunktioner, NAT översätter adresser eller portar, routing väljer den fortsatta vägen och målsystemet måste känna till returvägen. Om alla lager ändras samtidigt kan symptomet ibland försvinna, men orsaken förblir oklar.

Om testet gäller WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP eller någon annan tjänst på själva firewallen gäller inte samma regler som för genomgående trafik. I så fall leder diagnostiken direkt till Administration > Device access och Local Service ACL.

Definiera ett reproducerbart testfall

Ett påstående som ”internet fungerar inte” eller ”VPN-regeln matchar inte” är för brett. Ett användbart testfall kan exempelvis se ut så här:

• Source IP: 10.10.20.35
• Source zone: LAN
• User: admin@example.com eller medvetet utan User Matching
• Destination: app.example.net, för närvarande upplöst till 203.0.113.20
• Service: TCP 443
• Förväntad firewallregel: LAN-App-HTTPS, Rule ID 37
• Förväntad NAT-regel: NAT Rule ID 12 eller uttryckligen ingen NAT-regel
• Testtid: 2026-08-08 10:15:00

IP-adresser, ID:n, namn och tidpunkt är exempelvärden och ersätts med värdena i den egna miljön. Formen är viktig: under diagnostiken förblir Source, mål-IP, port och användare oförändrade. Om DNS-upplösning, klient eller applikation ändras under tiden jämförs inte längre samma flöde.

Tolka de första observationerna

• Aktiv Packet Capture visar inget paket trots ett passande filter: Kontrollera först Capture Status, filter och buffert. Om dessa är korrekta ligger orsaken sannolikt före firewallen, exempelvis hos klienten, VLAN, switch, gateway, leverantör eller Cloud Security Group.
• Log Viewer visar en annan Rule ID: En mer generell, automatiskt skapad eller annorlunda matchande regel utvärderas tidigare.
• Firewall Rule ID stämmer, NAT Rule ID gör det inte: Kontrollera NAT-ordningen samt Original source, destination och service.
• Rule ID och NAT ID stämmer, men Forwarded syns inte: Kontrollera regelåtgärd, Reason, routing eller en säkerhetsmodul.
• Forwarded syns, men inget svar kommer: Kontrollera returväg, målsystem, lokal serverfirewall eller extern blockering.
• Endast vissa användare berörs: Kontrollera autentisering och User Matching för det faktiska dataflödet separat.

Det utförliga kombinerade flödet finns i Testa firewallregel med Log Viewer, Policy Tester och Packet Capture. Den här artikeln fokuserar på hur en oväntad regelmatchning förklaras.

Kontrollera regelordning och matchning

En firewallregel matchar endast om alla relevanta kriterier stämmer och ingen tidigare regel redan behandlar samma trafik.

Den första matchande regeln vinner

Sophos Firewall utvärderar regler uppifrån och ned och avslutar sökningen vid den första matchande regeln. Positionen i listan är därför avgörande; Rule ID är endast en fast identifierare och motsvarar inte positionen.

Följande bör också beaktas:

• En generell regel högre upp kan helt täcka en specifik regel längre ned.
• Rule Groups förbättrar översikten men skapar ingen egen matchningslogik. Reglerna i grupperna utvärderas.
• Automatiskt skapade regler, till exempel för MTA, IPsec eller hotspots, kan läggas in högre upp och kontrolleras först.
• Ett aktivt filter i regeltabellen kan dölja relevanta regler. Använd Reset filter före analysen.
• Den oföränderliga Default Drop-regeln har Rule ID 0, står sist och har ingen vanlig Usage Counter. Tabellfilter gäller inte för den.

Grundlogiken för en regel förklaras fullständigt i Förstå och konfigurera Sophos Firewall-regler korrekt.

Läs alla matchningskriterier tillsammans

En regel som ser korrekt ut kan misslyckas på grund av ett enda fält:

• Source zones: Klienten kommer från en annan zon, exempelvis VPN i stället för LAN, eller VLAN är tilldelat på ett annat sätt.
• Source networks and devices: IP-objektet, hostgruppen eller subnätet innehåller inte den faktiska Source IP.
• Destination zones: Målzonen är fel, särskilt vid DNAT, VPN eller routade nätverk.
• Destination networks: Den adress som faktiskt används stämmer inte med objektet eller perspektiven före och efter NAT har blandats ihop.
• Services: Porten saknas, TCP och UDP har förväxlats eller applikationen öppnar ytterligare anslutningar.
• Users or groups: Firewallen kan inte koppla användaren till Source IP eller den importerade gruppen stämmer inte.
• Schedule: Schemat är inte aktivt vid testtillfället.
• Exclusions: Flödet undantas från regeln och kontrolleras därefter mot fler regler.

För webbtrafik ingår även protokollet i testet. Webbläsare kan använda QUIC över UDP 443, medan den förväntade regeln eller webbkontrollen endast omfattar klassisk HTTPS över TCP 443. Effekterna förklaras i Kontrollera QUIC på Sophos Firewall.

Nollställ överförd datamängd kontrollerat

Menyalternativet Reset data transfer count kan hjälpa vid testet men misstolkas ofta. Det nollställer datamängden som överförts via regeln; det är inte en sessions- eller träffräknare.

1. Öppna Rules and policies > Firewall rules.
2. Leta reda på den berörda regeln och öppna menyn med tre punkter.
3. Välj Reset data transfer count.
4. Utlös det definierade testflödet igen.
5. Utvärdera datamängd, Rule ID och Packet Capture tillsammans.

Om värdet ökar efter det kontrollerade testet tyder det på trafik som överförts via denna regel. Om det förblir oförändrat bevisar det inte i sig att regeln aldrig har matchat. För ett tillförlitligt resultat kontrolleras den faktiska Rule ID i Log Viewer och paketvägen i Packet Capture. För Default Drop-regeln med ID 0 finns denna dataräknare inte tillgänglig.

Läs Log Viewer, Policy Tester och Packet Capture korrekt

Verktygen besvarar olika frågor:

• Log Viewer: Vilken loggad session, regel, NAT-regel, åtgärd och användare identifierades?
• Policy Tester: Vilken policylogik skulle gälla för de angivna värdena?
• Packet Capture: Vilka paket kommer faktiskt fram, hur behandlar firewallen dem och går de ut igen?

Inget av verktygen ersätter helt de andra. Om simulering och verkligt paketflöde motsäger varandra väger logg- och paketdata från det reproducerade testet tyngre.

Log Viewer: faktisk Rule ID och NAT Rule ID

I firewallregeln måste Log firewall traffic vara aktiverat. Dessutom måste rätt loggtyp under System services > Log settings vara aktiverad för lokal visning, Sophos Central eller Syslog.

För testet är filter på följande fält användbara:

• Source IP och Destination IP
• port eller Service
• Rule ID och Rule name
• NAT rule ID
• Action och User
• den antecknade testtiden

En post som saknas bevisar ännu inte att firewallen inte såg något. Firewallsessioner loggas bland annat när anslutningen avslutas med en Destroy-händelse. Vid plötsliga anslutningsavbrott kan den förväntade posten därför saknas eller visas senare. Packet Capture ger då ett mer direkt resultat. Lämpliga tjänster och loggfiler beskrivs i Sophos Firewall-troubleshooting: tjänster och loggar.

Policy Tester: policylogik utan verkligt paketflöde

Under Diagnostics > Tools > Policy tester anges URL, User, tid, Source IP och Source zone medvetet. Protokoll och port ska framgå av den fullständiga URL:en, exempelvis https://app.example.net:8443/. Utan protokoll testar verktyget HTTP; för HTTPS används port 443 som standard och en avvikande port måste anges i URL:en.

Policy Tester är användbart men har tydliga begränsningar:

• Det skapar inget verkligt paketflöde och kontrollerar varken målsystemet eller returvägen.
• Resultaten återger inte SD-WAN-rutter.
• Regler med MAC-adresser under Source networks and devices kan inte matchas.
• Problem hos leverantör, switch, gateway och paketförlust förblir osynliga.

⚠️ På SFOS 22.0 GA Build 411 kunde NC-177587 och NC-176083 orsaka felaktiga Policy Test-resultat. Trafik visades som blockerad eller matchad via fel regel trots att den i verkligheten flödade korrekt. MR1 Build 490 innehåller de dokumenterade korrigeringarna. Vid motstridiga resultat kontrolleras först firmwareversion, Log Viewer och Packet Capture innan produktionsregler ändras.

Packet Capture: kontrollera den verkliga paketvägen

Under Diagnostics > Packet capture ställs först ett snävt BPF Capture Filter in, exempelvis med Source IP, Destination IP och port för testflödet. Aktivera därefter Trace On, rensa listan och utlös exakt det definierade flödet.

En tom Packet Capture är meningsfull först när dessa förutsättningar är uppfyllda:

1. Trace On är aktivt.
2. BPF Capture Filter stämmer med det verkliga målet och filtrerar inte bort flödet.
3. Bufferten har inte redan skrivit över relevant testtrafik. Utan Wrap capture buffer once full stoppar inspelningen när bufferten på 2048 KB är full och fortsätter med Clear. Med Wrap-alternativet aktiverat fortsätter inspelningen och skriver över de äldsta paketen.

Ett extra Display Filter ändrar inte vad som spelades in men kan dölja befintliga poster. Kontrollera därför Capture Filter och Display Filter separat.

Statusvärdena betyder:

• Incoming: Paketet togs emot på ett gränssnitt.
• Forwarded: Firewallen vidarebefordrar paketet via ett utgående gränssnitt.
• Consumed: Paketet är avsett för själva firewallen eller används av den.
• Generated: Firewallen har själv skapat paketet.
• Violation: En policyöverträdelse leder till drop; fältet Reason förklarar orsaken närmare.

Rule ID, NAT ID, Reason samt inkommande och utgående gränssnitt läses alltid tillsammans. Consumed och Generated är normala resultat och inte automatiskt fel.

⚠️ På SFOS 22.0 MR1 Build 490 kan NC-178387 visa drops via Default-regeln med ID 0 enbart som Incoming. Den förväntade posten Violation Firewall och posten i drppkt saknas trots att firewallen fortfarande avvisar flödet. För denna berörda version hjälper Policy Tester eller en medvetet placerad och loggad dropregel i slutet av den egna regellistan. Någon fixversion anges inte i den aktuella Known Issues-informationen.

Ett detaljerat Capture-flöde finns i Använd Packet Capture i Sophos Firewall WebAdmin. Drops och en kontrollerad slutregel behandlas i Analysera paket som Sophos Firewall har avvisat.

Kontrollera NAT, DNAT, routing och returväg

NAT tillåter ingen trafik. Det översätter adresser eller portar för trafik som en firewallregel tillåter. Därför måste Firewall Rule ID och NAT Rule ID stämma var för sig.

Utvärdera Firewall Rule ID och NAT Rule ID tillsammans

• Firewall Rule ID stämmer, NAT Rule ID är fel: Kontrollera NAT-ordningen, fälten Original och mer generella NAT-regler.
• NAT Rule ID stämmer, Firewall Rule ID är fel: Jämför firewallregelordning, zoner, Source, Destination, Service och Schedule.
• Båda ID:n stämmer, anslutningen misslyckas: Kontrollera routing, returväg, målserver, säkerhetsmodul eller applikation.
• Ingen NAT Rule ID syns trots att NAT förväntas: Kontrollera riktning, Inbound/Outbound Interface och NAT-regelns Original-kriterier.

Under Rules and policies > NAT rules gäller också den första matchande regeln. En generell SNAT- eller MASQ-regel kan därför täcka en specifik regel längre ned. Linked NAT Rules beaktas dessutom endast för trafik som matchar deras tillhörande firewallregel; en tidigare fristående NAT-regel kan ändå matcha först.

Den fullständiga ID-logiken förklaras i Förstå NAT på Sophos Firewall.

Förstå DNAT ur perspektivet före och efter NAT

För inkommande DNAT-trafik gäller en viktig tumregel:

Firewallregeln använder målzonen efter NAT, men den ursprungligen adresserade adressen före NAT som Destination Network.

Exempel på portvidarebefordran:

• Den externa klienten ansluter till 198.51.100.10 på TCP 8888.
• NAT-regeln översätter till servern 10.10.50.20 i zonen DMZ och till TCP 4444.
• I NAT-regeln är TCP 8888 Original service och TCP 4444 Translated service (PAT).
• Firewallregeln använder WAN som Source zone, DMZ som Destination zone och 198.51.100.10 som Destination network.
• I Sophos officiella PAT-exempel innehåller den tillhörande firewallregeln både den ursprungliga och den översatta tjänsten.

Det externa testet utförs fortfarande mot port 8888; den interna servern tar emot anslutningen på port 4444. Om endast en av de två portarna granskas kan regeln snabbt verka korrekt trots att tjänstematchning och översättning inte stämmer överens. En fullständig publicering beskrivs i Publicera server via DNAT på Sophos Firewall.

Skapa en ny anslutning efter NAT-ändringar

Sophos Firewall utvärderar en NAT-regel endast för det första paketet i en anslutning. Befintliga sessioner fortsätter att använda den tidigare översättningen även om NAT-regeln har ändrats.

Efter en NAT-korrigering skapas därför en ny anslutning: avsluta det pågående testet, stäng den befintliga webbläsar- eller applikationssessionen och starta flödet igen. En omladdning inom samma TCP-session bevisar inte tillförlitligt den nya NAT-konfigurationen.

Undersök routing först efter bekräftad matchning

Om Rule ID och NAT Rule ID stämmer och Packet Capture visar Forwarded är Rule Matching i grunden bevisad. Därefter kontrolleras:

• passande statisk rutt eller Default Route
• SD-WAN route och aktiv gateway
• faktiskt utgående gränssnitt
• rutt på målsystemet och i fjärrnätverk
• symmetrisk returväg via VPN, MPLS eller WAN
• lokal firewall på målservern

Policy Tester återger inte SD-WAN. För det verkliga beslutet räknas Gateway ID, gränssnitt och paketväg. Ordningen för statiska rutter, SD-WAN och VPN förklaras i Justera routingprioriteten på Sophos Firewall.

Specialfall efter den första observationen

Först när det grundläggande flödet har klassificerats är det meningsfullt att fördjupa analysen av lokala tjänster, användare, namnuppslagning eller säkerhetsmoduler.

Trafik till själva firewallen: Device Access i stället för firewallregel

WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS och SNMP avslutas på firewallen. Packet Capture-statusen kan därför vara Consumed. Åtkomsten styrs under Administration > Device access och med Local Service ACL Exception Rules, inte med en vanlig regel för genomgående trafik.

Kontrollera zon, betrott källnätverk, tillåten tjänst, användarbehörighet och MFA. Det säkerhetsrelevanta samspelet förklaras i Säkra Sophos Firewall Device Access och Local Service ACL; de olika webbgränssnitten förklaras i Översikt över Sophos Firewall-portaler.

Separera användarinloggning och User Matching

En lyckad inloggning på VPN Portal, User Portal, Captive Portal eller via Entra ID SSO bekräftar först endast autentiseringen. För att den planerade användarregeln ska matcha måste firewallen även koppla användaren till det faktiska dataflödet och dess Source IP.

Typiska observationer:

• User-fältet i Log Viewer är tomt: Kontrollera STAS, AD SSO, Captive Portal, Entra ID SSO eller Clientless User. För en fast enhets-IP visar Konfigurera och testa Clientless Users kopplingen med kontrollen i Live Users och det negativa testet.
• Användaren syns, men en annan regel matchar: Jämför regelposition, gruppvillkor eller en mer generell regel högre upp.
• Endast VPN-användare berörs: Kontrollera zonen VPN, VPN-pool, Source network och gruppmatchning.
• Endast enskilda användare berörs: Jämför UPN, e-postadress, importerad kataloggrupp och Sophos Firewall-grupp.

För lokala AD-miljöer hjälper Konfigurera STAS på Sophos Firewall och Lägg till Active Directory på Sophos Firewall. Beroende på Entra-inloggningsvägen passar Entra ID SSO för Sophos Connect och VPN Portal eller Entra ID SSO för Captive Portal. Vid mycket många identifierade användare eller Clientless Users kan även Sophos Firewall User ID-gränsen vara relevant.

Kontrollera DNS, FQDN, CDN och IPv6

För Rule Matching räknas den mål-IP som faktiskt används, inte bara det angivna värdnamnet. DNS-cache, Split DNS, CDN-tjänster, en annan resolver, ytterligare API-mål eller IPv6 kan leda flödet till en annan adress.

Vanliga FQDN Hosts löses upp av firewallen själv och mappningen uppdateras utifrån DNS TTL. Wildcard FQDNs fungerar annorlunda: firewallen lär sig IP-adresser för matchande underdomäner från observerade DNS-svar. Om klienten använder en extern resolver måste dess UDP DNS-trafik på port 53 passera firewallen. Om det aktuella svaret inte är synligt för firewallen kan underdomänens IP-adress saknas i Wildcard-objektet och regeln inte matcha trots ett till synes korrekt namn.

FQDN Hosts stöder dessutom inte IPv6-upplösning. Innan ett objekt utökas jämförs därför DNS-svar, mål-IP och IP-version med Log Viewer eller Packet Capture. Detaljer om TTL, Wildcards och inlärningsbeteende finns i FQDN Hosts och Wildcard FQDNs på Sophos Firewall. För intern upplösning hjälper DNS Request Routes; en aktiv IPv6-miljö kräver egna matchande regler och ett medvetet IPv6-koncept.

Håll isär säkerhetsmoduler och Traffic Shaping

Om Firewall Rule ID, NAT Rule ID och routing stämmer kan en modul som har tilldelats regeln påverka applikationen:

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

Endast en modul avgränsas åt gången för det konkreta flödet och en kort testperiod. Ett undantag förblir begränsat till Source, mål och Service; därefter återställs den ursprungliga skyddseffekten eller dokumenteras det nödvändiga undantaget. Vid HTTPS-problem hjälper en kontrollerad TLS Inspection-utrullning.

Traffic Shaping är däremot en QoS-funktion. Den garanterar, prioriterar eller begränsar bandbredd och kan därmed orsaka låg throughput, paketförlust vid överbelastning eller timeouts. Det är inte samma sak som åtkomstbeslutet Drop eller Reject. För en verklig blockering kontrolleras Packet Capture-status, Reason och ansvarig säkerhetsmodul. Vid stora överföringar eller VPN-anslutningar ingår även MTU och MSS i analysen.

Testa och dokumentera ändringar kontrollerat

Vid regelproblem ska endast en variabel ändras per test:

1. Anteckna utgångsläget med Source, Destination, Service, User, tidpunkt, Rule ID och NAT ID.
2. Ändra exakt en regelposition, ett objekt, en Service eller en modul.
3. Skapa en ny anslutning vid NAT; utlös annars samma testflöde igen.
4. Jämför Log Viewer och Packet Capture med samma filter.
5. Dokumentera framgång eller misslyckande och kontrollera först därefter nästa ändring.

Tillfälliga Allow-, Drop- eller undantagsregler får ett begripligt namn, en owner och ett utgångsdatum. Annars blir en kortsiktig diagnostikhjälp snabbt permanent i regelverket.

Om anslutningen fortfarande fungerade i går ska även de senaste konfigurationsändringarna kontrolleras. Audit Trail Logs visar vem som har ändrat regler eller objekt. Config Studio hjälper till att jämföra större konfigurationer. Om ändringen kom från Sophos Central kontrolleras dessutom Central Firewall Task Queue.

Checklista för felsökning av regler

• Konkret testflöde definierat med Source, Destination, Service, User och tidpunkt.
• Kontrollerat om det gäller genomgående trafik eller en lokal firewalltjänst.
• Regelposition, automatiska regler och dolda tabellfilter kontrollerade.
• Alla matchningsfält jämförda med det verkliga flödet.
• Datamängd endast använd som indikation och inte som träffräknare.
• Log Viewer visar faktisk Firewall Rule ID och vid behov NAT Rule ID.
• Policy Tester-resultatet jämfört med firmwareversion och verkliga paketdata.
• Packet Capture körs med lämpligt Capture Filter och ledig buffert.
• Incoming, Forwarded, Consumed, Generated, Violation, Reason och gränssnitt korrekt tolkade.
• Vid DNAT har målzonen efter NAT, Destination Network före NAT och båda PAT-tjänsterna kontrollerats.
• En ny anslutning skapad efter NAT-ändringar.
• DNS-svar, mål-IP, FQDN-inlärningsbeteende och IP-version kontrollerade.
• User Login och User Matching för dataflödet kontrollerade separat.
• Routing, SD-WAN, gateway och returväg undersökta först efter bekräftad regelmatchning.
• Säkerhetsmoduler kontrollerade individuellt och Traffic Shaping som QoS.
• Varje ändring dokumenterad; testregler har en owner och ett utgångsdatum.

FAQ