Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT

NAT ändrar adresser eller portar i ett paket. Det avgör däremot inte om anslutningen är tillåten och skapar inte heller någon rutt. För att dataflödet ska fungera måste NAT-regeln, brandväggsregeln, routningen och returvägen stämma överens.

Den bästa utgångspunkten är därför inte frågan ”Vilken typ av NAT behöver jag?”, utan: Vilken adress eller port ska ändras mellan in- och utgående trafik? Om det inte finns något tydligt svar ligger lösningen oftast i routningen eller brandväggsregeln, inte i NAT.

⚠️ En NAT-regel är inte en tillåtelseregel. Om brandväggsregeln tillåter trafiken men ingen NAT-regel matchar vidarebefordrar SFOS paketet utan översättning. Om motsvarande brandväggsregel saknas kasseras och loggas paketet.

När ska NAT användas?

• LAN-klienter ska nå internet: vanligtvis SNAT med MASQ.
• En intern tjänst ska vara nåbar via en offentlig adress: DNAT; kontrollera först om WAF bör användas för HTTP/HTTPS.
• Den externa och interna porten skiljer sig åt: tjänsteöversättning med Translated service (PAT).
• Interna klienter använder det offentliga namnet på en intern server: använd helst split DNS eller en särskilt avgränsad Loopback Rule.
• Icke-överlappande nät kommunicerar via ett plats-till-plats-VPN: normalt routning och brandväggsregler utan NAT.
• Näten överlappar: planera NAT utifrån VPN-typen; improvisera inte med en generell MASQ-regel.
• Åtkomst ska endast tillåtas eller blockeras: ändra brandväggsregeln; skapa ingen NAT-regel.

För den konkreta uppgiften att publicera en server beskriver Publicera en server med DNAT på Sophos Firewall assistenten, en manuell regel, härdning, driftsättning och återställning. Den här artikeln förklarar NAT-modellen så att du kan tolka sådana regler och felsöka problem.

Andra närliggande specialfall är NAT64 med Direct Web Proxy, Proxy ARP för ytterligare offentliga IPv4-adresser och NAT vid IPsec-problem.

Tolka Original och Translated korrekt

Under Rules and policies > NAT rules > Add NAT rule beskriver Original paketet som det ser ut när det anländer till brandväggen. Translated beskriver den ändring som SFOS tillämpar på paketet.

Regeln väljs utifrån följande fält:

• Original source
• Original destination
• Original service
• Inbound interface
• Outbound interface

Fälten Translated source (SNAT), Translated destination (DNAT) och Translated service (PAT) anger resultatet och är inga ytterligare matchningsvillkor. NAT-regler utvärderas uppifrån och ned; den första matchande regeln används.

NAT-regler finns för IPv4 och IPv6. Välj rätt adressfamilj under Rules and policies > NAT rules innan regeln skapas; IPv4-adresserna i exemplen hör inte hemma i en IPv6-regel. Add NAT rule > New NAT rule öppnar den manuella konfigurationen. Nya regler är aktiverade som standard. Rule position erbjuder Top och Bottom; senare kan ordningen ändras genom att dra reglerna. Kontrollera villkor och position före Save så att regeln inte oavsiktligt tar över produktionstrafik.

Två exempel på paketflöden

En klient med adressen 10.10.10.80 ansluter via Port2 till 198.51.100.20:443. En SNAT-regel kan ändra enbart källan till MASQ. Destinationen och tjänsten förblir Original.

När en tjänst publiceras ansluter en extern klient till 203.0.113.10:5555. DNAT ändrar destinationen till 172.16.16.10 och PAT ändrar tjänsten till 443. Regeln ser då ut så här:

• Original destination: 203.0.113.10
• Original service: TCP 5555
• Translated destination (DNAT): 172.16.16.10
• Translated service (PAT): TCP 443

PAT är alltså inte en egen typ av adress-NAT vid sidan av SNAT och DNAT, utan port- eller tjänsteöversättningen i en NAT-regel.

SNAT och MASQ för utgående trafik

SNAT ändrar källadressen. En typisk LAN-till-WAN-regel använder det interna nätet som Original source, WAN-gränssnittet som Outbound interface och MASQ som Translated source. Destinationen och tjänsten förblir Original eller begränsas till det omfång som faktiskt krävs.

MASQ använder som standard adressen för det utgående gränssnittet. Fabrikskonfigurationen innehåller Default SNAT IPv4 för detta ändamål. Om regeln inte behövs rekommenderar Sophos att den inaktiveras i stället för att tas bort, eftersom den kan skapas på nytt när ett WAN-gränssnitt skapas eller uppdateras.

Efter en migrering från SFOS 17.5 eller tidigare kan dessutom en inaktiverad standardregel för SNAT visas längst ned i tabellen. Den är avsedd att ersätta Linked MASQ-regler som rensats bort och får inte förväxlas med en aktiv fabriksregel.

Flera interna klienter eller servrar kan använda samma offentliga käll-IP: SFOS skiljer deras anslutningar åt med olika portnummer. Denna tilldelning av källportar är inte DNAT-vidarebefordran av en tjänst till en server.

Skapa en fristående SNAT-regel från LAN till WAN

En fristående SNAT-regel kan betjäna flera brandväggsregler. Kontrollera först befintliga NAT-regler, rutten, utgående gränssnitt och returvägen; spara det tidigare tillståndet med ID och positioner. Exemplet tillåter endast HTTPS från klientnätet till en bestämd testdestination. Ersätt alla adresser och gränssnitt med egna värden.

1. Öppna Rules and policies > NAT rules, välj IPv4 och Add NAT rule > New NAT rule. Ange Rule name, exempelvis LAN-Web-Standalone-MASQ. Välj Top eller Bottom under Rule position och placera sedan regeln medvetet ovanför mer generella matchande regler; lägg den inte överst utan kontroll.
2. Ange Original source som Clients_LAN (10.10.10.0/24), Original destination som ett värdobjekt för 198.51.100.20 och Original service som HTTPS. Dokumentationsadressen är ingen verklig testserver. För generell internetåtkomst kan destinationerna breddas medvetet; begränsa ändå tjänsterna till det som behövs.
3. Ange Translated source (SNAT) som MASQ, Translated destination (DNAT) och Translated service (PAT) som Original. Välj det verkliga LAN-gränssnittet under Inbound interface, här Port2, och WAN-gränssnittet under Outbound interface, här Port1. Välj Save och anteckna NAT Rule ID.
4. Välj IPv4 > Add firewall rule > New firewall rule under Rules and policies > Firewall rules om ingen lämplig tillåtelseregel finns. Ange namn och position, Action Accept, Source zones LAN, Source networks and devices Clients_LAN, Destination zones WAN, Destination networks med samma destination och Services HTTPS. Konfigurera lämpligt skydd och Log firewall traffic, sedan Save. Skapa ingen ytterligare Linked NAT Rule.
5. Upprätta en ny HTTPS-anslutning till den egna testdestinationen och avsluta den normalt. Jämför båda Rule IDs i Log Viewer; Packet capture ska visa den förväntade WAN-källadressen på utgången. Vid fel NAT-matchning, kontrollera högre regler först; om svar saknas, kontrollera routning och returväg. Återställ genom att bara inaktivera tillagda regler och återställa ändrade positioner; ta inte bort en delad tillåtelseregel. Verifiera det tidigare tillståndet med en ny session.

Skapa en LAN-till-WAN-regel med länkad NAT

För att tillåta ett avgränsat IPv4-flöde kan du länka SNAT när du skapar brandväggsregeln. Kontrollera först om en befintlig SNAT-regel redan översätter flödet som avsett; i så fall behövs ingen ytterligare Linked NAT Rule. Rutten och returvägen måste vara korrekta oberoende av NAT.

1. Öppna Rules and policies > Firewall rules, välj IPv4 och skapa en regel via Add firewall rule > New firewall rule. Välj ett tydligt namn, exempelvis LAN-Web-Out, och en lämplig position; ställ in Action på Accept och aktivera Log firewall traffic.
2. Ställ in Source zones på LAN och begränsa Source networks and devices till det klientnät som behöver åtkomst. Använd exempelvis ett nätverksobjekt Clients_LAN för 10.10.10.0/24; anpassa namnet och subnätet till den egna miljön. Ställ in Destination zones på WAN. Välj de nödvändiga destinationerna under Destination networks och endast de tjänster som behövs under Services, exempelvis HTTPS för detta webbflöde. Any är inget generellt krav. Ta hänsyn till DNS och andra nödvändiga tjänster separat.
3. Välj Create linked NAT rule. Ge NAT-regeln ett eget namn, exempelvis LAN-Web-MASQ, och en lämplig position. Ställ in Translated source (SNAT) på MASQ: flödet ska använda adressen för det faktiska utgående gränssnittet, medan brandväggsregeln fortsätter att begränsa källor, destinationer och tjänster.
4. Välj först Save i konfigurationen för länkad NAT och därefter Save igen för brandväggsregeln. Att bara spara den inbäddade NAT-dialogen slutför inte proceduren.
5. Kontrollera brandväggsregeln under Firewall rules och den länkade SNAT-regeln under NAT rules; anteckna båda posterna och deras Rule IDs. Kontrollera ordningen i båda tabellerna separat. En matchande NAT-regel högre upp kan få företräde; länkningen garanterar ingen prioritet.
6. Upprätta en faktiskt ny anslutning från en tillåten klient till den tillåtna destinationen och tjänsten och avsluta sedan testanslutningen på normalt sätt, så att en sessionslogg kan skapas. Filtrera på flödet i Log Viewer och jämför Firewall Rule ID och NAT Rule ID med de antecknade ID-värdena. Om brandväggs-ID är fel, kontrollera först brandväggsvillkoren och regelordningen; om NAT-ID är fel, kontrollera först högre placerade NAT-regler. Att båda posterna finns bekräftar inte i sig att internetåtkomsten fungerar.

Viktiga begränsningar för SNAT

Utöver MASQ kan Translated source (SNAT) använda en enskild IP-adress eller ett IP-intervall. SFOS 22-beskrivningen tillåter uttryckligen varje IP-adress som tilldelats ett gränssnitt som källa och anger Add för att skapa IP-/intervallobjektet. Beskrivningen av NAT-typer i SFOS 23 inkluderar fortfarande enskilda IP-adresser och intervall; utelämnade meningar i Add-beskrivningen visar inte att stödet tagits bort. Den fasta adressen måste vara nåbar i den egna miljön och passa den förväntade returvägen.

• Ett intervall under Translated source skapar ingen fast ett-till-ett-mappning. SFOS använder nästa lediga adress i intervallet.
• Ett offentligt gränssnitt som ingår i en brygga kan inte användas som gränssnitt för käll-NAT. Om ett gränssnitt som används senare läggs till i en brygga tar SFOS bort de berörda SNAT-reglerna.
• Override source translation for specific outbound interfaces gör det möjligt att använda olika översatta källor för olika utgående gränssnitt i en och samma SNAT-regel. Lägg till fler mappningar med Expand.
• För route-based VPN med Any som lokala och fjärranslutna subnät, eller med en dual-IP-konfiguration, kan MASQ använda XFRM-adressen som inre källadress. WAN-adressen är fortfarande synlig i den yttre tunnelheadern.

Dokumentera därför de berörda reglerna innan ett gränssnitt läggs till i en brygga eller produktionspooler för SNAT ändras. Testa dem sedan med ett faktiskt nytt trafikflöde.

DNAT, PAT, Loopback och Reflexive Rules

DNAT ändrar destinationsadressen. PAT ändrar dessutom tjänsten eller porten som adresseras. Protokollet måste förbli detsamma: TCP kan översättas till en annan TCP-port och UDP till en annan UDP-port, men TCP kan inte översättas till UDP.

Om flera ursprungliga tjänster eller Any väljs måste Translated service (PAT) vara Original. Entydig portvidarebefordran använder en specifik ursprunglig tjänst och en specifik översatt tjänst. Translated destination (DNAT) kan vara en IP-adress eller FQDN. Tjänsteöversättning stöder en enda målport eller lika många ursprungliga och översatta portar: exempelvis flera portar inom en ursprunglig tjänst till en port (many-to-one), eller lika stora portuppsättningar (many-to-many). Many-to-many kräver lika antal portar; flera separat valda ursprungliga tjänster tillåter inte PAT-översättning. Protokollet måste alltid förbli detsamma.

Brandväggsregeln som hör till DNAT

För inkommande trafik fastställer SFOS först vilken DNAT-regel som matchar. Därefter utvärderas brandväggsregeln. Då gäller följande ovanliga men viktiga mappning:

• Destination zone: zonen för den interna destinationen efter DNAT, exempelvis DMZ.
• Destination networks: den offentliga destinationsadressen före DNAT.
• Services: utan PAT, tjänsten som anslutningen gäller. Med PAT innehåller brandväggsregeln i Sophos officiella exempel både den ursprungliga och den översatta tjänsten.

I motsatt riktning utvärderas brandväggsregeln först. Därefter tillämpar SFOS den matchande SNAT-regeln.

En NAT-regel ersätter inte denna brandväggsregel. För en fullständig DNAT-konfiguration med källbegränsning, IPS, loggning och externt acceptanstest, använd DNAT-runbooken.

Loopback Rule

En Loopback Rule kan ge interna klienter åtkomst via den offentliga IP-adressen eller det offentliga FQDN-namnet. Split DNS är ofta tydligare: internt matchas samma namn direkt mot serverns interna adress, så att hairpin-NAT inte behövs.

Server Access Assistant skapar endast en Loopback Rule om ett WAN-gränssnitt på brandväggen väljs som offentlig adress och External source networks and devices är inställt på Any. Om en offentlig IP-adress anges eller en mer begränsad extern källa väljs skapas inte denna automatiska Loopback Rule.

Vid manuell DNAT-konfiguration är Create loopback rule ett separat val. Den ursprungliga DNAT-regeln måste använda Original source Any, Translated source (SNAT) MASQ och Translated destination (DNAT) som inte är Original. Detta är inte assistentens fält. Ta inte bort en extern källbegränsning bara för att få loopback: överväg först split DNS eller en separat planerad intern regel. Testa intern åtkomst och externa begränsningar var för sig efter att du sparat.

Reflexive Rule

En Reflexive Rule skapar en omvänd SNAT-regel för en DNAT-regel. Den vänder på matchningsvillkoren och kan översätta utgående servertrafik med motsvarande offentliga identitet. Om den ursprungliga destinationen inte är en IP-adress eller om den översätts använder Reflexive Rule MASQ som översatt källa.

Vid manuell DNAT-skapande genererar Create reflexive rule denna spegelregel; Create loopback rule är ett separat val. Genererade regler använder den ursprungliga regelns ID och namn men förblir fristående. Identifiera och inaktivera varje genererad post separat vid återställning och verifiera med nya interna och externa anslutningar.

Loopback och Reflexive Rules förblir fristående regler. Om den ursprungliga DNAT-regeln ändras eller tas bort uppdateras eller tas de inte bort automatiskt. Kontrollera därför de härledda reglerna separat när den offentliga adressen, den interna destinationen eller tjänsten har ändrats.

Om en DNAT-regel fördelar trafik mellan flera interna destinationer betraktas de som tillgängliga om Health check inte är aktiverat. För First alive är hälsokontrollen obligatorisk. För övriga fördelningsmetoder måste den aktiveras uttryckligen och konfigureras med ICMP eller TCP efter tjänstens behov, så att SFOS inte skickar ny trafik till en server som inte fungerar.

Linked NAT Rules och Server Access Assistant

En Linked NAT Rule är alltid en SNAT-regel som är länkad till en brandväggsregel. Brandväggsregelns samtliga matchningsvillkor fortsätter att gälla, inklusive användare och scheman. I NAT-regeln kan endast översatta källor och gränssnittsspecifika översatta källor ändras.

Länkningen åsidosätter inte den normala regelordningen för NAT: en fristående NAT-regel som ligger högre upp kan matcha först. Om en generell SNAT-regel redan omfattar samma trafik rekommenderar Sophos att ingen ytterligare Linked NAT Rule läggs till. I MTA-läge skapar SFOS däremot automatiskt en sådan regel.

Server access assistant (DNAT) skapar en DNAT-regel, en Reflexive Rule och en brandväggsregel. En Loopback Rule läggs bara till för den tidigare beskrivna kombinationen av ett WAN-gränssnitt och den externa källan Any. Assistenten placerar reglerna överst i tabellerna och aktiverar dem. Kontrollera därefter källorna, regelpositionen, de extra regler som skapats och användningen av alias-IP. För en alias-IP anger assistenten först det fysiska gränssnittet som översatt källa i Reflexive respektive Loopback Rules. Om aliasadressen ska användas måste motsvarande IP Host väljas manuellt.

Håll isär NAT, VPN och SD-WAN

NAT ändrar inte routingbeslutet. Även efter översättningen behöver SFOS en rutt till destinationen. För VPN-trafik beror rätt konfigurationsplats dessutom på tunneltypen:

• Policy-based IPsec: använd NAT-inställningarna för IPsec-anslutningen när de lokala och fjärranslutna subnäten ska översättas, särskilt om de överlappar. Om en ytterligare SNAT-regel ska matcha policy-based trafik måste dess Outbound interface vara inställt på Any; regeln tillämpas inte om specifika WAN-gränssnitt väljs.
• Route-based IPsec med valda lokala och fjärranslutna subnät: använd NAT-inställningarna för IPsec-anslutningen för att översätta dessa subnät.
• Route-based IPsec med Any/Any: använd NAT-regler för den vidarebefordrade trafiken.

För VPN-trafik ska Inbound interface i NAT-regler vara Any. För VPN och DNAT från offentliga till privata IP-adresser måste även Outbound interface vara Any. Det är ett krav för gränssnittsmatchning, inte tillåtelse för godtyckliga källor eller tjänster; Original-villkor och brandväggsregler begränsar dem fortfarande.

Icke-överlappande nät behöver i regel inte NAT. För överlappande nät ska de verkliga och översatta näten på båda sidor dokumenteras. Annars blir DNS, regler och loggar senare tvetydiga.

För DNAT till en server bakom en route-based IPsec-tunnel dokumenterar Sophos en särskild SD-WAN-konfiguration: DNAT-regeln använder MASQ som Translated source så att svaren går tillbaka till brandväggen. SD-WAN-rutten matchar den ursprungliga WAN-adressen eller WAN-gränssnittet som destination och, när PAT används, den externa porten. Gateway-objektet pekar på XFRM-gränssnittet. Använd inte detta specialfall som generell DNAT-modell för lokala servrar.

Nå en fjärrserver med DNAT och en SD-WAN-rutt

Denna IPv4-procedur gäller endast en server bakom brandväggen på den andra platsen. Kontrollera först route-based IPsec-anslutningar på båda brandväggarna, tunnelstatus, fjärråtkomst, tillåtna källor, tjänst, returväg och befintlig NAT-/SD-WAN-ordning. Spara konfiguration och berörda positioner. Exemplet använder extern TCP 5555 och intern TCP 443, inte offentlig RDP; ersätt dokumentationsadresserna med egna värden. Separat brandväggstillåtelse och härdning krävs fortfarande.

1. Skapa Remote_Web under Hosts and services > IP host > Add: IP version IPv4, Type IP, IP address med fjärrserverns adress, exempelvis 172.16.16.10; välj Save.
2. Välj ett tydligt namn under Routing > Gateways, IPv4 gateway > Add. Ange Gateway IP som fjärrgatewayens adress, exempelvis 10.12.13.2, och Interface som motsvarande XFRM-gränssnitt, exempelvis xfrm1-10.12.13.1. Ange IP-adressen till en faktiskt nåbar värd bakom gatewayen under Monitoring condition; verifiera gateway- och tunnelstatus före publicering.
3. Skapa en namngiven IPv4-regel under Rules and policies > NAT rules > Add NAT rule > New NAT rule. Begränsa Original source till tillåtna externa källor. Ange Original destination som det publicerade WAN-gränssnittet, exempelvis #Port1, Translated source (SNAT) som MASQ, Translated destination (DNAT) som Remote_Web, Original service som ett TCP 5555-objekt och Translated service (PAT) som TCP 443. Ange båda gränssnittsfälten som Any i detta VPN-DNAT-fall. Kontrollera positionen och välj Save. I detta specialfall säkerställer MASQ returvägen till brandväggen.
4. Välj IPv4 > Add under Routing > SD-WAN routes och ange ett namn. Ta bort Any under Destination networks och välj samma ursprungliga WAN-gränssnitt #Port1, inte Remote_Web. Ta bort Any under Services och välj den externa tjänsten TCP 5555, inte TCP 443. Välj Primary and Backup gateways under Link selection settings och ange fjärrgatewayen som Primary gateway; välj bara en reservgateway om dess fjärrväg finns och har verifierats. Välj Save.
5. Skapa en ny anslutning från en tillåten extern källa. Kontrollera NAT-/brandväggs-ID, översatt destination och tjänst, XFRM-utgång och svar i paketinsamlingen. Vid fel utgång, kontrollera SD-WAN-villkor, ordning och gatewayövervakning; om svar saknas, kontrollera fjärrtjänsten och returvägen. För fler servrar via samma gateway, utöka samma SD-WAN-rutt med deras externa portar/WAN-adresser; använd separata rutter för olika gateways. Tillagda kombinationer måste fortsatt begränsas av NAT och brandvägg.

Om ändringen misslyckas, inaktivera den nya fjärr-DNAT-regeln, ta bort den nya SD-WAN-rutten eller återställ den tidigare konfigurationen och positionerna. Ta inte bort delade gateway-/värdobjekt. Återställ härledda NAT-regler separat och verifiera det tidigare flödet med en ny anslutning.

Översätta trafik från brandväggen med sys-traffic-nat

NAT-regler i WebAdmin översätter vidarebefordrad trafik. För trafik som genereras av brandväggen och för översättning av adresser på brandväggens gränssnitt används sys-traffic-nat i Device Console.

Vanliga användningsfall för källöversättning via CLI:

• Skicka brandväggsgenererade DHCP- och autentiseringsförfrågningar via plats-till-plats-IPsec; översättning kan även stödja förfrågningar till brandväggstjänster via VPN-tunnlar. Detta ersätter inte tjänste- och VPN-konfigurationen.
• Använda aliasadresser när det finns fler WAN-länkar än fysiska WAN-gränssnitt, med översättning från det fysiska gränssnittet till rätt alias.
• Skicka e-post med den alias-källadress som uppströmsreläet eller MX-posten kräver.
• Dölja interna adresser för WAN-destinationer, exempelvis DHCP-förfrågningar från ett LAN-gränssnitt; använda en specifik källidentitet för interna MPLS-destinationer eller utvalda webbservrar.

Anteckna först destination, nödvändig källidentitet, rutt och motpartens krav. Utlös sedan den konkreta tjänsten igen och kontrollera källadress och svar i paketinsamlingen. En CLI-post ensam visar inte att DHCP, autentisering eller e-post fungerar.

Följande exempel översätter trafik till den enskilda destinationen 192.0.2.10 som går via Port1, så att aliasadressen 203.0.113.10 används:

show advanced-firewall
set advanced-firewall sys-traffic-nat add destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

Destinationen, nätmasken, gränssnittet och SNAT-adressen måste anpassas till den egna miljön. För en enskild värd krävs 255.255.255.255; en bredare mask omfattar hela det matchande destinationsnätet. Utan interface gäller posten för trafik till den angivna destinationen via samtliga brandväggsgränssnitt.

⚠️ Detta Device Console-kommando ändrar systemgenererad trafik. Spara först hela utdata från show advanced-firewall. CLI-poster för NAT bearbetas i den ordning som visas där.

Återställ ändringen genom att använda samma fullständiga mappning med delete:

set advanced-firewall sys-traffic-nat delete destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

Systemgenererad trafik använder som standard WAN Link Load Balancing. Med en alias-IP är huvudgränssnittet fortfarande avgörande för routingbeslutet; sys-traffic-nat ser endast till att den önskade aliasadressen visas som källa. En synlig post bekräftar därför konfigurationen, inte rutten, returvägen eller tjänsten.

Ändra och testa NAT-regler på ett säkert sätt

Använd tabellen och räknarna medvetet

Under Rules and policies > NAT rules väljer IPv4 eller IPv6 regelfamiljen. Disable filter döljer filtret, Enable filter visar det och Reset filter återställer det. Att dölja ett filter inaktiverar ingen NAT-regel. Kontrollera att rätt poster visas före ändringar.

Markerade regler kan inaktiveras tillsammans med Disable eller tas bort med Delete. Dra Rule handle för att flytta en regel; specifika regler ska ligga före generella. More options erbjuder aktivering/inaktivering, redigering, borttagning och tillägg av en intilliggande regel. Unlink rule tar bort länkningen till brandväggsregeln: dokumentera först beroendet och använd inte detta som en felsökningsgenväg.

Reset usage count under More options nollställer användningsräknaren. Anteckna först värdet och tidpunkten, skapa ett nytt testflöde och kontrollera ökningen tillsammans med Rule IDs; räknaren ensam identifierar inte testflödet. Det tidigare värdet återställs inte. Spara ID, villkor, status och ordning före regeländringar, välj helst inaktivering i stället för borttagning och ändra endast markerade poster. Återställ status och positioner vid problem och testa med en ny session; en borttagen regel måste återställas från den sparade konfigurationen.

SFOS utvärderar NAT endast för det första paketet i en anslutning. Befintliga sessioner behåller sin tidigare översättning när en regel ändras eller flyttas. Ett test efter ändringen måste därför skapa en ny anslutning. Annars riskerar du att utvärdera det gamla tillståndet.

Ett tillförlitligt test börjar med ett dokumenterat flöde: källa, destination, tjänst, inkommande och utgående gränssnitt samt förväntat Firewall Rule ID och NAT Rule ID. Gör sedan följande:

1. Skapa en ny anslutning och filtrera efter källa, destination och tjänst i Log Viewer.
2. Jämför förväntat Firewall Rule ID och NAT Rule ID.
3. Om NAT Rule ID är fel kontrollerar du reglerna ovanför samt samtliga Original-fält och gränssnitt.
4. Kontrollera under Diagnostics > Packet capture att paketet anländer och vidarebefordras med de förväntade adresserna.
5. Kontrollera rutten, returvägen, målsystemet och dess lokala brandvägg.

För DNAT måste minst ett test göras utifrån. Intern åtkomst till det offentliga namnet testar endast split DNS eller loopback, inte den faktiska publiceringen från internet.

Tolka resultaten korrekt

• Firewall Rule ID och NAT Rule ID stämmer: matchningen är korrekt; undersök därefter målsystemet, returvägen och Security Profiles.
• Firewall Rule ID stämmer, men NAT Rule ID är fel: en annan NAT-regel har företräde eller så matchar inte Original-villkoren.
• NAT Rule ID saknas trots att översättning förväntas: ingen NAT-regel matchar; om brandväggsregeln tillåter flödet fortsätter det utan översättning.
• Ett annat Firewall Rule ID visas: kontrollera zoner, nätverk, tjänst och brandväggsreglernas ordning.
• Ingen loggpost: loggning är inte aktiverad eller trafiken når inte brandväggen. Gör en paketinsamling på WAN-gränssnittet eller det inkommande gränssnittet och kontrollera överordnade routrar eller molnregler.
• DNAT matchar, men servern svarar inte: kontrollera servertjänsten, den lokala brandväggen, standardgatewayen och om returvägen är asymmetrisk.

För en djupare analys, se Testa en brandväggsregel, Undersök regelmatchning, Klassificera kasserade paket och Packet Capture i WebAdmin.

Vanliga frågor