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å
Anyi 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.168.2.0/24. Varje sida får ett eget virtuellt nät för tunneln:
HQ real: 192.168.2.0/24 → visible to branch as 192.168.1.0/24
Branch real: 192.168.2.0/24 → visible to HQ as 192.168.3.0/24
En klient på huvudkontoret kontaktar därför en filialserver via dess adress i 192.168.3.0/24. En filialklient använder motsvarande adress i 192.168.1.0/24 för en server på huvudkontoret. Den verkliga adressen 192.168.2.x förblir lokal på respektive plats.
De tre näten är dokumentationsvärden 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
Policy-based IPsec kräver tre IP host-objekt på varje brandvägg: 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.168.2.0, HO_LAN_NAT_192.168.1.0 och BO_LAN_NAT_192.168.3.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:
- Local subnet:
HO_LAN_NAT_192.168.1.0 - Remote subnet:
BO_LAN_NAT_192.168.3.0 - Network address translation (NAT): aktiverat
- Original subnet:
HO_LAN_REAL_192.168.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
Skapa anslutningen på filialen som Policy-based med Gateway type Initiate the connection. Spegelvänd tilldelningen helt:
- Local subnet:
BO_LAN_NAT_192.168.3.0 - Remote subnet:
HO_LAN_NAT_192.168.1.0 - Network address translation (NAT): aktiverat
- Original subnet:
BO_LAN_REAL_192.168.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. Kontrollera 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.
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. Om deras trafik i stället matchar en MASQ-regel kan SFOS kassera den, eftersom dessa XFRM-interface inte har någon tilldelad IP-adress.
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
192.168.3.0/24 - Translated source:
Original - Original destination: huvudkontorets översatta nät
192.168.1.0/24 - Translated destination: huvudkontorets verkliga nät
192.168.2.0/24 - 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 192.168.1.0/24 och använda filialens översatta nät 192.168.3.0/24 som Original destination.
NAT på filialen
Använd samma princip spegelvänt på filialen:
- Original source: huvudkontorets översatta nät
192.168.1.0/24 - Translated source:
Original - Original destination: filialens översatta nät
192.168.3.0/24 - Translated destination: filialens verkliga nät
192.168.2.0/24 - Create reflexive rule: aktiverat
- Load balancing method:
One-to-one
Den reflexive regeln ska översätta filialens verkliga nät utgående till 192.168.3.0/24. En mer generell SNAT- eller MASQ-regel ovanför får inte fånga trafiken först. 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.
Kontrollera routing, DNS och program tillsammans
På varje sida måste routen till det översatta fjärrnätet använda rätt XFRM-interface eller dess övervakade gateway. En route till det identiska verkliga nätet vore tvetydig och kan dra lokal trafik in i tunneln. Om flera routes finns ska Route Precedence, Administrative Distance och SD-WAN-val kontrolleras tillsammans.
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 för samma tidsstämpel:
- IPsec-anslutningen och Child SA är aktiva.
- Förväntad Firewall Rule ID tillåter flödet.
- Förväntad NAT Rule ID översätter original- och destinationsadresser korrekt.
- Packet Capture visar ingång, översättning, XFRM-utgång och returväg.
- Målservern ser den planerade källadressen och svarar via samma väg.
Lägg till fler värdar, tjänster och DNS-namn först när båda riktningarna fungerar. 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. Jämför Original och Translated source i den reflexive regeln, Remote subnet i IPsec-anslutningen, serverns gateway och reglerna i motsatt riktning. En ensidig översättning kan inte skapa ett stabilt dubbelriktat flöde.
Fel NAT-regel matchar
Kontrollera NAT Rule ID och ordning. En bred MASQ-, Default-SNAT- eller tidigare DNAT-regel kan matcha före den specifika VPN-regeln. Inaktivera inte alla NAT-regler på chans; korrelera först det enskilda testflödet med tidsstämpel och korrigera sedan endast den konfliktande regeln.
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. Inaktivera gamla regler under migreringen endast när en tydlig återställning är dokumenterad.
Om valideringen misslyckas inaktiverar du de nya NAT-reglerna och routes, återställer den tidigare tunnelkonfigurationen och testar den ursprungliga lokala trafiken igen. 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.