Använd NAT för överlappande IPsec-nätverk på Sophos Firewall

Om huvudkontor och filial använder samma verkliga subnät kan ingen brandvägg avgöra enbart utifrån destinationsadressen om ett paket ska stanna lokalt eller gå genom IPsec-tunneln. Tunneln kan vara grön utan att det finns en entydig dataväg. Lösningen är en översättningsplan som samordnas på båda sidor: varje plats visas för peer-enheten under ett unikt översatt nät.

Tunneltypen avgör metoden. Policy-based IPsec och route-based IPsec med specifika traffic selectors använder NAT-inställningarna direkt i IPsec-anslutningen. Route-based Any-to-Any använder i stället DNAT- och SNAT-regler och en route till det översatta fjärrnätet. Konfigurera en Site-to-Site IPsec VPN beskriver det allmänna valet av tunneltyp.

Välj rätt metod

Sophos stöder översättning 1:1, 1:n och n:n för policy-based IPsec. Med n:n måste originalnätet och det översatta nätet ha samma storlek. Ett /24 ska till exempel kopplas till ett annat /24, inte ett /25.

Tre frågor räcker för valet:

• Finns specifika Local och Remote subnets i IPsec-anslutningen? Använd Network address translation (NAT) i anslutningen.
• Är båda subnäten inställda på Any i en route-based tunnel? Använd DNAT med en reflexive SNAT-regel och en route via XFRM.
• Överlappar näten inte alls? NAT är normalt onödigt och försvårar loggar, regler och felsökning.

⚠️ Blanda inte de två metoderna. Spara båda tunnelkonfigurationerna, NAT- och brandväggsregler, routes, DNS-svar och oberoende administratörsåtkomst före ändringen. En bred MASQ-regel eller en improviserad översatt adress är ingen säker workaround.

Skapa en adressplan för båda platserna

I exemplet använder huvudkontor och filial båda det verkliga nätet 192.0.2.0/24. Varje sida får ett eget virtuellt nät för tunneln:

HQ real:            192.0.2.0/24  → visible to branch as 198.51.100.0/24
Branch real:        192.0.2.0/24  → visible to HQ as 203.0.113.0/24

En klient på huvudkontoret kontaktar därför en filialserver via dess adress i 203.0.113.0/24. En filialklient använder motsvarande adress i 198.51.100.0/24 för en server på huvudkontoret. Den verkliga adressen 192.0.2.x förblir lokal på respektive plats.

De tre näten kommer från IPv4-block som RFC 5737 reserverar för exempel och ska tillsammans ersättas med lediga nät i den verkliga adressplanen. Båda översatta näten måste vara unika, får inte kollidera med LAN-, VLAN-, VPN-, cloud- eller hemnät och ska dokumenteras spegelvänt på båda brandväggarna. Om program använder namn måste DNS på respektive plats returnera den översatta adressen för fjärrsystemet.

Konfigurera policy-based IPsec med NAT

För policy-based IPsec behövs tre nätverksobjekt på varje brandvägg under Hosts and services > IP host > Add: det verkliga lokala nätet, det egna översatta nätet och peer-enhetens översatta nät. I huvudkontorets exempel är de HO_LAN_REAL_192.0.2.0, HO_LAN_NAT_198.51.100.0 och BO_LAN_NAT_203.0.113.0.

Konfigurera huvudkontoret

Skapa anslutningen under Site-to-site VPN > IPsec > Add som Policy-based med Gateway type Respond only. Profil, autentisering, WAN-interface och peer-adress måste stämma med fjärrsidan. Använd följande tilldelningar:

• Activate on save: aktiverat
• Create firewall rule: aktiverat
• Local subnet: HO_LAN_NAT_198.51.100.0
• Remote subnet: BO_LAN_NAT_203.0.113.0
• Network address translation (NAT): aktiverat
• Original subnet: HO_LAN_REAL_192.0.2.0

Brandväggen översätter det verkliga lokala nätet till sitt eget översatta nät före sändningen. Inkommande trafik till det översatta nätet kopplas tillbaka till det verkliga nätet.

Konfigurera filialen spegelvänt

Denna rollfördelning är särskilt användbar när filialen har en dynamisk IP-adress och huvudkontoret saknar en tillförlitlig adress till peer-enheten för att initiera anslutningen: filialen initierar då anslutningen mot huvudkontorets stabilt nåbara ändpunkt. En dynamisk adress är dock inget absolut hinder om peer-adressen kan lösas upp tillförlitligt och utformningen tillåter att huvudkontoret initierar anslutningen. När fler filialer läggs till skalar anslutningsetableringen bättre om varje filial upprepar sina egna anslutningsförsök, i stället för att huvudkontoret måste försöka ansluta till alla filialer på nytt.

Skapa anslutningen på filialen som Policy-based med Gateway type Initiate the connection. Spegelvänd tilldelningen helt:

• Activate on save: aktiverat
• Create firewall rule: aktiverat
• Local subnet: BO_LAN_NAT_203.0.113.0
• Remote subnet: HO_LAN_NAT_198.51.100.0
• Network address translation (NAT): aktiverat
• Original subnet: BO_LAN_REAL_192.0.2.0

Local och Remote subnet innehåller alltså de översatta näten, medan Original subnet innehåller det verkliga lokala nätet. Om nätstorlek eller riktning inte stämmer kan Phase 2 ändå bildas, men trafiken översätts fel eller saknar returväg.

Kontrollera automatiska brandväggsregler

Med Create firewall rule skapar SFOS inkommande och utgående VPN-regler. Kontrollera dem under Rules and policies > Firewall rules i gruppen Automatic VPN rules. Reglerna måste tillåta de översatta näten i rätt riktning och endast de tjänster som faktiskt behövs. En befintlig generell VPN-regel kan justeras; en separat bred regel krävs inte för varje tunnel.

Regler utvärderas uppifrån och ned. Placera dessa VPN-regler ovanför eventuella bredare regler som står i konflikt och kontrollera sedan Rule ID, käll- och målzoner, käll- och målnät, tjänster och logging under ett verkligt test. Skapa brandväggsregler på Sophos Firewall beskriver den allmänna regellogiken.

Etablera anslutningen vid behov

Kontrollera tunnelstatusen först när båda platserna är konfigurerade och brandväggsreglerna har granskats. Activate on save aktiverar konfigurationsposten men bevisar inte att tunneln är etablerad. Om tunneln ännu inte är etablerad och behöver etableras manuellt, gå till Site-to-site VPN > IPsec på den initierande sidan – filialen i detta exempel – och klicka på statusknappen i kolumnen Connection för den aktuella anslutningen.

Koppla inte från eller återetablera en befintlig produktions-SA för detta steg; inget sådant klick krävs på det svarande huvudkontoret. En grön anslutningsindikator bekräftar att tunneln är etablerad, inte att datavägen fungerar: utför därefter de kontroller av tjänst, Child SA och paketfångst som beskrivs nedan i båda riktningarna.

Konfigurera route-based Any-to-Any med DNAT och SNAT

Metoden kräver en fungerande route-based Any-to-Any-tunnel. XFRM-interfacet har en unik transitadress, matchande LAN-to-VPN- och VPN-to-LAN-regler finns och en statisk, SD-WAN- eller dynamisk route pekar mot peer-enhetens översatta nät. Först därefter läggs NAT till.

Route-based anslutningar med specifika traffic selectors använder inte denna procedur. Liksom policy-based IPsec använder de NAT-inställningarna i IPsec-anslutningen. Detta är en separat variant som Sophos dokumenterar och den får inte blandas med DNAT/SNAT-reglerna för Any-to-Any.

NAT på huvudkontoret

Skapa en DNAT-regel under Rules and policies > NAT rules > Add NAT rule > New NAT rule. Den översätter inkommande paket till huvudkontorets virtuella nät till det verkliga lokala nätet:

• Original source: filialens översatta nät 203.0.113.0/24
• Translated source: Original
• Original destination: huvudkontorets översatta nät 198.51.100.0/24
• Translated destination: huvudkontorets verkliga nät 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• Create reflexive rule: aktiverat
• Load balancing method: One-to-one

Använd nätverks- eller IP range-objekt av samma storlek för kopplingen. Öppna den skapade regeln Reflexive_NAT#_<DNAT_rule_name> efter att du sparat. Utgående ska den översätta huvudkontorets verkliga nät till 198.51.100.0/24 och använda filialens översatta nät 203.0.113.0/24 som Original destination.

NAT på filialen

Använd samma princip spegelvänt på filialen:

• Original source: huvudkontorets översatta nät 198.51.100.0/24
• Translated source: Original
• Original destination: filialens översatta nät 203.0.113.0/24
• Translated destination: filialens verkliga nät 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• Create reflexive rule: aktiverat
• Load balancing method: One-to-one

Den reflexive regeln ska översätta filialens verkliga nät utgående till 203.0.113.0/24. Värdet Any för båda interfacen är avsiktligt i detta dokumenterade mönster; ersätt det inte med WAN enbart för att IPsec-peer-enheten nås via WAN. Objekten för de översatta adresserna och brandväggsreglerna ger den snäva avgränsningen. En mer generell SNAT- eller MASQ-regel ovanför får inte fånga trafiken först.

SFOS matchar en NAT-regel mot ursprunglig källa, destination och tjänst före NAT samt mot inkommande och utgående interface. NAT tillämpas bara på det första paketet i en anslutning, så varje test efter en NAT-ändring måste använda en ny anslutning med en ny femtuplett. Bevisa ordning och matchning med NAT Rule ID och Packet Capture i stället för att enbart dra slutsatser från listan. Förstå NAT på Sophos Firewall beskriver reflexive regler och first-match-principen.

Matcha Any-to-Any-brandväggsreglerna exakt

En NAT-regel tillåter inte trafik. Skapa därför snävt avgränsade regler för varje nödvändig riktning under Rules and policies > Firewall rules > Add firewall rule > New firewall rule. Använd följande matchning på huvudkontoret:

• utgående: Source zone LAN, Source network huvudkontorets verkliga nät, Destination zone VPN, Destination network filialens översatta nät;
• inkommande: Source zone VPN, Source network filialens översatta nät, Destination zone LAN, Destination network huvudkontorets verkliga nät;
• begränsa Services till verksamhetstjänsten som testas och aktivera Log firewall traffic för acceptanstestet.

Byt plats på huvudkontor och filial i filialens brandvägg. De olika destinationsobjekten är avsiktliga: för utgående trafik utvärderar SFOS brandväggsregeln före SNAT. För inkommande trafik fastställer SFOS först DNAT-destinationen och utvärderar därefter brandväggsregeln mot den översatta destinationen och dess zon. Därför avgör denna NAT-bearbetningsordning regelobjekten.

Kontrollera routing, DNS och program tillsammans

Vid route-based Any-to-Any måste en egenkonfigurerad statisk, SD-WAN- eller dynamisk route på varje sida leda till det översatta fjärrnätet via rätt XFRM-interface eller dess övervakade gateway. Om flera routes finns kontrolleras Route Precedence, Administrative Distance och SD-WAN-val tillsammans. Vid route-based med specifika traffic selectors skapas däremot en statisk route automatiskt när tunneln etableras; här kontrolleras denna route och motsvarande selectors. Vid policy-based IPsec skapar SFOS en VPN-route i backend när tunneln etableras och matchar trafiken mot VPN-policyn respektive Local och Remote subnets; en separat XFRM-route ingår inte i denna metod. Det identiska verkliga nätet måste förbli lokalt i alla tre varianterna och får inte dras in i tunneln av en route till fjärrnätet.

Programmet måste också använda den översatta destinationen. Statiska konfigurationer, ACL:er, DNS-svar, monitoring och serverloggar får inte fortsätta förvänta sig den verkliga fjärradressen. Ett NAT-test enbart med ping bevisar därför inte att verksamhetsprocessen fungerar.

Validera datavägen i båda riktningarna

Börja med en känd värd och en verklig TCP- eller UDP-tjänst på varje sida. Från huvudkontoret öppnar du den översatta filialadressen och testar därefter den översatta huvudkontorsadressen från filialen. Kontrollera den etablerade anslutningen under Current activities > IPsec connections och IPsec-användningen under Reports > VPN. Under Diagnostics > Packet capture > Configure begränsar ett BPF-filter som host 203.0.113.10 inspelningen till testvärden. Kontrollera för samma tidsstämpel:

1. IPsec-anslutningen och Child SA är aktiva.
2. Förväntad Firewall Rule ID tillåter flödet.
3. Vid Any-to-Any styrker förväntade Rule IDs för DNAT- och reflexive SNAT-reglerna den planerade käll- och destinationsöversättningen. Vid policy-based IPsec och route-based med specifika traffic selectors jämförs i stället de sparade värdena för Original subnet, Local subnet och Remote subnet på båda sidor, de förhandlade selectors och de faktiska original- och översatta adresserna i testflödet. För denna NAT i anslutningen krävs ingen separat NAT Rule ID.
4. Packet Capture visar ingång, vidarebefordran och returväg med hjälp av In interface, Out interface, Rule ID, Status och Reason. Käll- och destinationsadresser före och efter översättningen jämförs med adressplanen; filtret måste fånga de original- eller översatta adresser som kontrolleras i respektive test. Vid route-based kontrolleras det tillhörande XFRM-interfacet, vid policy-based IPsec-vägen via det gemensamma IPsec-interfacet, inte ett separat XFRM-interface. NAT ID används vid Any-to-Any även för koppling till den separata NAT-regeln och är inget obligatoriskt bevis för NAT i anslutningen.
5. Målservern ser den planerade källadressen och svarar via samma väg.

Som negativ kontroll anropas därefter den identiska verkliga adressen 192.0.2.10: den måste förbli lokal och får inte gå genom VPN i någon av de tre varianterna. Lägg till fler värdar, tjänster och DNS-namn först när de positiva och negativa testen ger planerat resultat i båda riktningarna. Packet Capture på Sophos Firewall hjälper till att jämföra före och efter NAT; Sophos Firewall IPsec-felsökning beskriver hela tunnelkontrollen.

Avgränsa fel efter symptom

Tunneln är grön, men destinationen svarar lokalt

Klienten använder troligen den verkliga adressen, som också finns lokalt, i stället för det översatta fjärrnätet. Kontrollera DNS-svar, hosts-fil, programkonfiguration och destinationsroute. Felet ligger då före tunneln.

Utgående väg fungerar, men returväg saknas

Översättningarna måste vara spegelvända på båda brandväggarna. Vid Any-to-Any jämförs Original source och Translated source samt den oförändrade fjärrdestinationsadressen i den reflexive SNAT-regeln; vid policy-based IPsec och route-based med specifika traffic selectors jämförs tilldelningarna för Original subnet, Local subnet och Remote subnet samt anslutningens förhandlade selectors. Dessutom kontrolleras serverns gateway och brandväggsreglerna i motsatt riktning. En ensidig översättning kan inte skapa ett stabilt dubbelriktat flöde.

Fel NAT-regel matchar

Vid Any-to-Any kontrolleras NAT Rule ID och ordningen för de separata DNAT-/SNAT-reglerna. En bred MASQ-, Default-SNAT- eller tidigare DNAT-regel kan matcha före den specifika VPN-regeln. Alla NAT-regler inaktiveras inte på chans; först korreleras det enskilda testflödet med tidsstämplar och sedan korrigeras endast den konfliktande regeln. Vid policy-based IPsec och route-based med specifika traffic selectors avgränsas en felaktig översättning i stället med hjälp av NAT-fälten i IPsec-anslutningen, de förhandlade selectors och de faktiska adresserna före och efter NAT; en saknad separat NAT Rule ID är inget fel här.

Vissa värdar fungerar och andra inte

Med n:n måste original- och översättningsintervallen ha samma storlek och position. Kontrollera IP range-objekt, subnätmasker, undantagna adresser, värdbrandvägg och den offset som faktiskt används. Framgång för .10 bevisar inte kopplingen för hela intervallet.

Rollback och drift

Förbered före ändringen en konfigurationsbackup, skärmbilder eller exporter av tunnel-, NAT-, brandväggs- och routingkonfigurationen samt oberoende hanteringsåtkomst. Anteckna också namn, ID, ordning och aktiveringsstatus för alla berörda regler och routes samt tidigare DNS- och programvärden. Inaktivera gamla regler under migreringen först när deras exakta tidigare tillstånd är dokumenterat.

Om valideringen misslyckas återställer du först de antecknade DNS- och programvärdena. För Any-to-Any inaktiverar du endast de nya brandväggsreglerna, DNAT/reflexive-SNAT-paret och routen till det översatta nätet. För policy-based IPsec återställer du de sparade värdena för Local, Remote och Original subnet. Återställ därefter tidigare regler och routes till ursprunglig ordning och aktiveringsstatus och testa nya anslutningar i båda riktningarna. Redan etablerade sessioner behåller NAT-mappningen från det första paketet och bevisar inte en återställning: låt orelaterade sessioner fortsätta och avsluta, om omedelbart bevis krävs, endast berörda testsessioner före omtestet. Töm inte alla anslutningar. Ta bort XFRM-adresser och objekt först när Object usage inte visar några kvarvarande beroenden. Ta bort översatta nät från DNS, monitoring och dokumentation först när inga beroenden återstår.

I drift ska översatta nät hanteras i den centrala IP-adressplanen. Kontrollera nya platser, cloud-nät, Remote Access-pooler och hemnät mot både original- och översatta nät. Annars flyttas överlappningen bara till en annan plats.

Vanliga frågor