NAT gebruiken voor overlappende IPsec-netwerken op Sophos Firewall

Als hoofdkantoor en filiaal hetzelfde werkelijke subnet gebruiken, kan geen van beide firewalls alleen op basis van het doeladres bepalen of een pakket lokaal moet blijven of door de IPsec-tunnel moet gaan. De tunnel kan groen zijn terwijl er geen eenduidig gegevenspad bestaat. De oplossing is een aan beide kanten afgestemd vertaalplan: elke locatie verschijnt bij de peer onder een uniek vertaald netwerk.

Het tunneltype bepaalt de methode. Policy-based IPsec en route-based IPsec met specifieke traffic selectors gebruiken de NAT-instellingen rechtstreeks in de IPsec-verbinding. Route-based Any-to-Any gebruikt in plaats daarvan DNAT- en SNAT-regels en een route naar het vertaalde externe netwerk. Een Site-to-Site IPsec VPN instellen beschrijft de algemene keuze van het tunneltype.

De juiste methode kiezen

Sophos ondersteunt 1:1-, 1:n- en n:n-vertaling voor policy-based IPsec. Bij n:n moeten het originele en het vertaalde netwerk even groot zijn. Een /24 wordt bijvoorbeeld aan een ander /24 gekoppeld, niet aan een /25.

Drie vragen zijn voldoende om te kiezen:

• Zijn specifieke Local en Remote subnets ingevoerd in de IPsec-verbinding? Gebruik Network address translation (NAT) in de verbinding.
• Staan beide subnetten bij een route-based tunnel op Any? Gebruik DNAT met een reflexive SNAT-regel en een route via XFRM.
• Overlappen de netwerken helemaal niet? NAT is normaal gesproken onnodig en bemoeilijkt logs, regels en troubleshooting.

⚠️ Meng de twee methoden niet. Leg vóór de wijziging beide tunnelconfiguraties, NAT- en firewallregels, routes, DNS-antwoorden en onafhankelijke beheerderstoegang vast. Een brede MASQ-regel of een geïmproviseerd vertaald adres is geen veilige workaround.

Een adresplan voor beide locaties maken

In het voorbeeld gebruiken hoofdkantoor en filiaal beide het werkelijke netwerk 192.0.2.0/24. Elke kant krijgt een eigen virtueel netwerk voor de tunnel:

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

Een client op het hoofdkantoor benadert een filiaalserver daarom via zijn adres in 203.0.113.0/24. Een filiaalclient gebruikt het overeenkomstige adres uit 198.51.100.0/24 voor een server op het hoofdkantoor. Het werkelijke adres 192.0.2.x blijft op elke locatie lokaal.

De drie netwerken komen uit de door RFC 5737 voor voorbeelden gereserveerde IPv4-blokken en moeten samen worden vervangen door vrije netwerken uit het werkelijke adresplan. Beide vertaalde netwerken moeten uniek zijn, mogen niet botsen met een LAN-, VLAN-, VPN-, cloud- of thuisnetwerk en moeten op beide firewalls gespiegeld worden vastgelegd. Als toepassingen namen gebruiken, moet DNS op elke locatie het vertaalde adres van het externe systeem teruggeven.

Policy-based IPsec met NAT configureren

Onder Hosts and services > IP host > Add zijn voor policy-based IPsec op elke firewall drie netwerkobjecten nodig: het werkelijke lokale netwerk, het eigen vertaalde netwerk en het vertaalde netwerk van de peer. In het voorbeeld van het hoofdkantoor zijn dat HO_LAN_REAL_192.0.2.0, HO_LAN_NAT_198.51.100.0 en BO_LAN_NAT_203.0.113.0.

Het hoofdkantoor configureren

Maak onder Site-to-site VPN > IPsec > Add de verbinding als Policy-based met Gateway type Respond only. Profiel, authenticatie, WAN-interface en peeradres moeten overeenkomen met de andere kant. Gebruik deze toewijzingen:

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

De firewall vertaalt het werkelijke lokale netwerk vóór verzending naar het eigen vertaalde netwerk. Inkomend verkeer naar het vertaalde netwerk wordt weer aan het werkelijke netwerk toegewezen.

Het filiaal gespiegeld configureren

Deze rolverdeling is vooral nuttig als het filiaal een dynamisch IP-adres heeft en het hoofdkantoor geen betrouwbaar adresseerbare peer heeft om de verbinding naartoe te starten: het filiaal start dan de verbinding naar het stabiel bereikbare eindpunt van het hoofdkantoor. Een dynamisch adres is echter geen absolute belemmering als de peernaam betrouwbaar naar een IP-adres kan worden vertaald en het ontwerp toestaat dat het hoofdkantoor de verbinding start. Naarmate er meer filialen bijkomen, schaalt de verbindingsopbouw beter als elk filiaal zijn eigen verbindingspogingen herhaalt, in plaats van dat het hoofdkantoor alle filiaalverbindingen opnieuw moet proberen.

Maak op het filiaal de Policy-based-verbinding met Gateway type Initiate the connection. Spiegel de toewijzing volledig:

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

Local en Remote subnet bevatten dus de vertaalde netwerken, terwijl Original subnet het werkelijke lokale netwerk bevat. Als netwerkgrootte of richting niet overeenkomt, kan Phase 2 toch ontstaan, maar wordt het verkeer verkeerd vertaald of ontbreekt de retourroute.

Automatische firewallregels controleren

Met Create firewall rule maakt SFOS inkomende en uitgaande VPN-regels. Controleer ze onder Rules and policies > Firewall rules in de groep Automatic VPN rules. De regels moeten de vertaalde netwerken in de juiste richting en alleen de werkelijk benodigde diensten toestaan. Een bestaande algemene VPN-regel kan worden aangepast; per tunnel is geen afzonderlijke brede regel verplicht.

Regels worden van boven naar beneden beoordeeld. Plaats deze VPN-regels boven eventuele bredere conflicterende regels en controleer tijdens een echte test Rule ID, bron- en doelzones, bron- en doelnetwerken, diensten en logging. Firewallregels maken op Sophos Firewall beschrijft de algemene regelwerking.

De verbinding zo nodig opbouwen

Controleer de tunnelstatus pas nadat beide locaties zijn geconfigureerd en de firewallregels zijn nagekeken. Activate on save activeert de configuratie, maar bewijst niet dat de tunnel is opgebouwd. Als de tunnel nog niet is opgebouwd en handmatige verbindingsopbouw nodig is, ga dan aan de initiërende kant – het filiaal in dit voorbeeld – naar Site-to-site VPN > IPsec en klik op de statusknop in de kolom Connection van de betreffende verbinding.

Verbreek of herstart hiervoor geen reeds opgebouwde productie-SA; op het antwoordende hoofdkantoor is zo’n klik niet nodig. Een groene verbindingsindicator bevestigt de tunnelopbouw, niet dat het gegevenspad werkt: voer daarna in beide richtingen de hieronder beschreven controles van de dienst, Child SA en capture uit.

Route-based Any-to-Any met DNAT en SNAT configureren

Deze methode vereist een werkende route-based Any-to-Any-tunnel. De XFRM-interface heeft een uniek transitadres, passende LAN-to-VPN- en VPN-to-LAN-regels bestaan en een statische, SD-WAN- of dynamische route verwijst naar het vertaalde netwerk van de peer. Pas daarna wordt NAT toegevoegd.

Route-based verbindingen met specifieke traffic selectors gebruiken deze procedure niet. Net als policy-based IPsec gebruiken ze de NAT-instellingen in de IPsec-verbinding. Dit is een afzonderlijke Sophos-procedure en mag niet met de DNAT/SNAT-regels voor Any-to-Any worden gecombineerd.

NAT op het hoofdkantoor

Maak onder Rules and policies > NAT rules > Add NAT rule > New NAT rule een DNAT-regel. Deze vertaalt inkomende pakketten voor het virtuele hoofdkantoornetwerk naar het werkelijke lokale netwerk:

• Original source: vertaald filiaalnetwerk 203.0.113.0/24
• Translated source: Original
• Original destination: vertaald hoofdkantoornetwerk 198.51.100.0/24
• Translated destination: werkelijk hoofdkantoornetwerk 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• Create reflexive rule: ingeschakeld
• Load balancing method: One-to-one

Gebruik netwerk- of IP range-objecten van gelijke grootte voor de koppeling. Open na het opslaan de gegenereerde regel Reflexive_NAT#_<DNAT_rule_name>. Uitgaand moet deze het werkelijke hoofdkantoornetwerk naar 198.51.100.0/24 vertalen en het vertaalde filiaalnetwerk 203.0.113.0/24 als Original destination gebruiken.

NAT op het filiaal

Pas hetzelfde principe gespiegeld toe op het filiaal:

• Original source: vertaald hoofdkantoornetwerk 198.51.100.0/24
• Translated source: Original
• Original destination: vertaald filiaalnetwerk 203.0.113.0/24
• Translated destination: werkelijk filiaalnetwerk 192.0.2.0/24
• Original service: Any
• Translated service: Original
• Inbound interface: Any
• Outbound interface: Any
• Create reflexive rule: ingeschakeld
• Load balancing method: One-to-one

De reflexive regel moet het werkelijke filiaalnetwerk uitgaand naar 203.0.113.0/24 vertalen. De waarde Any voor beide interfaces is in dit gedocumenteerde patroon opzettelijk; vervang deze niet door WAN alleen omdat de IPsec-peer via WAN wordt bereikt. De objecten voor de vertaalde adressen en de firewallregels zorgen voor de beperkte scope. Een algemenere SNAT- of MASQ-regel erboven mag het verkeer niet eerder vangen.

SFOS vergelijkt een NAT-regel met de oorspronkelijke bron, bestemming en dienst vóór NAT en met de inkomende en uitgaande interfaces. NAT wordt alleen op het eerste pakket van een verbinding toegepast. Elke test na een NAT-wijziging moet daarom een nieuwe verbinding met een nieuwe vijf-tuple gebruiken. Bewijs volgorde en matching met NAT Rule ID en Packet Capture in plaats van ze alleen uit de lijst af te leiden. NAT op Sophos Firewall begrijpen beschrijft reflexive regels en het first-match-principe.

De Any-to-Any-firewallregels exact koppelen

Een NAT-regel staat geen verkeer toe. Maak onder Rules and policies > Firewall rules > Add firewall rule > New firewall rule daarom per benodigde richting beperkte regels. Op het hoofdkantoor geldt:

• uitgaand: Source zone LAN, Source network werkelijk hoofdkantoornetwerk, Destination zone VPN, Destination network vertaald filiaalnetwerk;
• inkomend: Source zone VPN, Source network vertaald filiaalnetwerk, Destination zone LAN, Destination network vertaald hoofdkantoornetwerk uit Original destination van de DNAT-regel;
• beperk Services tot de geteste bedrijfsdienst en schakel Log firewall traffic voor de acceptatietest in.

Spiegel hoofdkantoor en filiaal op de andere kant. Bij uitgaand verkeer controleert SFOS eerst de firewallregel en daarna SNAT. Bij inkomend DNAT wordt de Destination zone bepaald door het vertaalde werkelijke doelnetwerk; Destination network blijft het oorspronkelijk benaderde vertaalde netwerk. Dit volgt de algemene DNAT-matching en staat los van de NAT-instellingen in een IPsec-verbinding met specifieke traffic selectors. Bewijs voor dit Any-to-Any-voorbeeld vóór productievrijgave de regelmatch, NAT Rule ID en het pakketpad met de hieronder beschreven nieuwe testflow.

Routing, DNS en toepassingen samen controleren

Bij route-based Any-to-Any moet aan elke kant een zelf geconfigureerde statische, SD-WAN- of dynamische route naar het externe vertaalde netwerk via de juiste XFRM-interface of de bijbehorende bewaakte gateway lopen. Bij meerdere routes worden Route Precedence, Administrative Distance en SD-WAN-selectie samen gecontroleerd. Bij route-based met specifieke traffic selectors wordt daarentegen automatisch een statische route aangemaakt zodra de tunnel wordt opgebouwd; hierbij worden deze route en de bijbehorende selectors gecontroleerd. Bij policy-based IPsec maakt SFOS bij het opbouwen van de tunnel een VPN-route in de backend aan en wordt het verkeer toegewezen op basis van de VPN-policy of de Local en Remote subnets; een eigen XFRM-route hoort niet bij deze methode. Het identieke werkelijke netwerk moet bij alle drie de varianten lokaal blijven en mag niet door een route naar het externe netwerk de tunnel in worden getrokken.

Ook de toepassing moet het vertaalde doel gebruiken. Statische configuraties, ACL’s, DNS-antwoorden, monitoring en serverlogs mogen niet het werkelijke externe adres blijven verwachten. Een NAT-test met alleen ping bewijst daarom nog niet dat het bedrijfsproces werkt.

Het gegevenspad in beide richtingen valideren

Begin met één bekende host en een echte TCP- of UDP-dienst aan elke kant. Controleer Current activities > IPsec connections en Reports > VPN. Onder Diagnostics > Packet capture > Configure beperkt een BPF-filter zoals host 203.0.113.10 de capture tot de test. Benader vanaf het hoofdkantoor het vertaalde filiaaladres en test daarna vanaf het filiaal het vertaalde hoofdkantooradres. Controleer voor hetzelfde tijdstip:

1. De IPsec-verbinding en Child SA zijn actief.
2. De verwachte Firewall Rule ID staat de flow toe.
3. Bij Any-to-Any tonen de verwachte Rule IDs van de DNAT- en reflexive SNAT-regels de geplande bron- en doelvertaling aan. Bij policy-based IPsec en route-based met specifieke traffic selectors worden in plaats daarvan de opgeslagen waarden voor Original subnet, Local subnet en Remote subnet aan beide kanten, de onderhandelde selectors en de daadwerkelijke originele en vertaalde adressen in de testflow vergeleken. Voor deze NAT binnen de verbinding is geen afzonderlijke NAT Rule ID vereist.
4. Packet Capture toont aan de hand van In interface, Out interface, Rule ID, Status en Reason de ingang, doorsturing en het retourpad. Bron- en doeladressen vóór en na de vertaling worden met het adresplan vergeleken; het filter moet de originele of vertaalde adressen omvatten die op dat moment worden gecontroleerd. Bij route-based wordt de bijbehorende XFRM-interface gecontroleerd, bij policy-based het IPsec-pad via de gedeelde IPsec-interface, niet een eigen XFRM-interface. NAT ID wordt bij Any-to-Any daarnaast gebruikt om de afzonderlijke NAT-regel te identificeren en is geen verplicht bewijs voor NAT binnen de verbinding.
5. De doelserver ziet het geplande bronadres en antwoordt via hetzelfde pad.

Als negatieve controle wordt vervolgens het identieke werkelijke adres 192.0.2.10 benaderd: dit moet lokaal blijven en mag bij geen van de drie varianten door het VPN gaan. Voeg pas meer hosts, diensten en DNS-namen toe wanneer de positieve en negatieve tests in beide richtingen het geplande resultaat tonen. Packet Capture op Sophos Firewall helpt bij de vergelijking vóór en na NAT; Sophos Firewall IPsec-troubleshooting behandelt de volledige tunnelcontrole.

Fouten per symptoom afbakenen

Tunnel is groen, maar de bestemming antwoordt lokaal

De client gebruikt waarschijnlijk het werkelijke adres, dat ook lokaal bestaat, in plaats van het externe vertaalde netwerk. Controleer DNS-antwoord, hosts-bestand, toepassingsconfiguratie en doelroute. De fout ontstaat dan vóór de tunnel.

Heenweg werkt, maar retourpad ontbreekt

De vertalingen moeten op beide firewalls gespiegeld zijn. Bij Any-to-Any worden Original source en Translated source en het ongewijzigde externe doeladres in de reflexive SNAT-regel vergeleken; bij policy-based IPsec en route-based met specifieke traffic selectors worden de toewijzingen van Original subnet, Local subnet en Remote subnet en de onderhandelde selectors van de verbinding vergeleken. Daarnaast worden de servergateway en de firewallregels in de omgekeerde richting gecontroleerd. Eenzijdige vertaling kan geen stabiele bidirectionele flow opleveren.

De verkeerde NAT-regel matcht

Bij Any-to-Any worden NAT Rule ID en de volgorde van de afzonderlijke DNAT-/SNAT-regels gecontroleerd. Een brede MASQ-, Default-SNAT- of eerdere DNAT-regel kan vóór de specifieke VPN-regel matchen. Schakel niet op goed geluk alle NAT-regels uit; correleer eerst de afzonderlijke testflow op tijdstip en corrigeer daarna alleen de conflicterende regel. Bij policy-based IPsec en route-based met specifieke traffic selectors wordt een onjuiste vertaling in plaats daarvan afgebakend aan de hand van de NAT-velden van de IPsec-verbinding, de onderhandelde selectors en de daadwerkelijke adressen vóór en na NAT; een ontbrekende afzonderlijke NAT Rule ID is hier geen fout.

Sommige hosts werken en andere niet

Bij n:n moeten het originele en het vertaalde bereik even groot en gelijk gepositioneerd zijn. Controleer IP range-objecten, subnetmaskers, uitgesloten adressen, hostfirewall en de werkelijk benaderde offset. Succes voor .10 bewijst niet de koppeling van het hele bereik.

Rollback en beheer

Bereid vóór de wijziging een configuratiebackup, screenshots of exports van tunnel-, NAT-, firewall- en routingconfiguratie en onafhankelijke beheerstoegang voor. Noteer ook namen, ID’s, volgorde en ingeschakelde status van alle betrokken regels en routes, samen met de vorige DNS- en toepassingswaarden. Schakel oude regels tijdens de migratie pas uit nadat hun exacte vorige status is vastgelegd.

Herstel bij een mislukte validatie eerst de vastgelegde DNS- en toepassingswaarden. Schakel bij Any-to-Any alleen de nieuwe firewallregels, het DNAT/reflexive-SNAT-paar en de route naar het vertaalde netwerk uit; herstel bij policy-based de opgeslagen Local, Remote en Original subnet-velden. Herstel daarna de eerdere volgorde en activeringsstatus van regels en routes en test nieuwe verbindingen in beide richtingen. Bestaande sessies behouden de NAT-toewijzing die bij het eerste pakket is vastgelegd en bewijzen geen rollback: laat niet-betrokken sessies doorlopen en beëindig, als onmiddellijk bewijs nodig is, vóór de hertest alleen de betrokken testsessies. Wis niet alle verbindingen. Verwijder XFRM-adressen en objecten pas als Object usage geen afhankelijkheid toont. Verwijder vertaalde netwerken pas uit DNS, monitoring en documentatie wanneer er geen afhankelijkheid meer bestaat.

Beheer de vertaalde netwerken tijdens gebruik in het centrale IP-adresplan. Controleer nieuwe locaties, cloudnetwerken, Remote Access-pools en thuisnetwerken tegen zowel originele als vertaalde netwerken. Anders verplaatst de overlap zich alleen naar een andere plaats.

Veelgestelde vragen