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 beperkte regels: uitgaand op het hoofdkantoor LAN, werkelijk hoofdkantoornetwerk, VPN, vertaald filiaalnetwerk; inkomend VPN, vertaald filiaalnetwerk, LAN, werkelijk hoofdkantoornetwerk. Spiegel dit op het filiaal, beperk Services en schakel Log firewall traffic voor de acceptatietest in. Dit volgt de NAT-volgorde: firewall vóór SNAT uitgaand, DNAT vóór firewall inkomend.
Routing, DNS en toepassingen samen controleren
Aan elke kant moet de route naar het externe vertaalde netwerk de juiste XFRM-interface of de bewaakte gateway gebruiken. Een route naar het identieke werkelijke netwerk zou dubbelzinnig zijn en kan lokaal verkeer de tunnel in trekken. Controleer bij meerdere routes Route Precedence, Administrative Distance en SD-WAN-selectie samen.
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:
- De IPsec-verbinding en Child SA zijn actief.
- De verwachte Firewall Rule ID staat de flow toe.
- De verwachte NAT Rule ID vertaalt originele en doeladressen correct.
- In Packet Capture tonen In interface, Out interface, NAT ID, Rule ID, Status en Reason ingang, vertaling, XFRM-uitgang en retourpad.
- De doelserver ziet het geplande bronadres en antwoordt via hetzelfde pad.
Benader als negatieve controle het identieke werkelijke adres 192.0.2.10: dit moet lokaal blijven en mag niet op de XFRM-interface verschijnen. 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. Vergelijk Original en Translated source in de reflexive regel, Remote subnet in de IPsec-verbinding, de servergateway en regels in de omgekeerde richting. Eenzijdige vertaling kan geen stabiele bidirectionele flow opleveren.
De verkeerde NAT-regel matcht
Controleer NAT Rule ID en volgorde. 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 alleen de conflicterende regel.
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.