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.168.2.0/24. Elke kant krijgt een eigen virtueel netwerk voor de tunnel:
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
Een client op het hoofdkantoor benadert een filiaalserver daarom via zijn adres in 192.168.3.0/24. Een filiaalclient gebruikt het overeenkomstige adres uit 192.168.1.0/24 voor een server op het hoofdkantoor. Het werkelijke adres 192.168.2.x blijft op elke locatie lokaal.
De drie netwerken zijn documentatiewaarden 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
Voor policy-based IPsec zijn op elke firewall drie IP host-objecten 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.168.2.0, HO_LAN_NAT_192.168.1.0 en BO_LAN_NAT_192.168.3.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:
- Local subnet:
HO_LAN_NAT_192.168.1.0 - Remote subnet:
BO_LAN_NAT_192.168.3.0 - Network address translation (NAT): ingeschakeld
- Original subnet:
HO_LAN_REAL_192.168.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
Maak op het filiaal de Policy-based-verbinding met Gateway type Initiate the connection. Spiegel de toewijzing volledig:
- Local subnet:
BO_LAN_NAT_192.168.3.0 - Remote subnet:
HO_LAN_NAT_192.168.1.0 - Network address translation (NAT): ingeschakeld
- Original subnet:
BO_LAN_REAL_192.168.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. 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.
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. Als hun verkeer in plaats daarvan een MASQ-regel raakt, kan SFOS het laten vallen omdat aan deze XFRM-interfaces geen IP-adres is toegewezen.
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
192.168.3.0/24 - Translated source:
Original - Original destination: vertaald hoofdkantoornetwerk
192.168.1.0/24 - Translated destination: werkelijk hoofdkantoornetwerk
192.168.2.0/24 - 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 192.168.1.0/24 vertalen en het vertaalde filiaalnetwerk 192.168.3.0/24 als Original destination gebruiken.
NAT op het filiaal
Pas hetzelfde principe gespiegeld toe op het filiaal:
- Original source: vertaald hoofdkantoornetwerk
192.168.1.0/24 - Translated source:
Original - Original destination: vertaald filiaalnetwerk
192.168.3.0/24 - Translated destination: werkelijk filiaalnetwerk
192.168.2.0/24 - Create reflexive rule: ingeschakeld
- Load balancing method:
One-to-one
De reflexive regel moet het werkelijke filiaalnetwerk uitgaand naar 192.168.3.0/24 vertalen. Een algemenere SNAT- of MASQ-regel erboven mag het verkeer niet eerder vangen. 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.
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. 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.
- Packet Capture toont ingang, vertaling, XFRM-uitgang en retourpad.
- De doelserver ziet het geplande bronadres en antwoordt via hetzelfde pad.
Voeg pas meer hosts, diensten en DNS-namen toe als beide richtingen werken. 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. Schakel oude regels tijdens de migratie alleen uit als een eenduidige terugkeer is gedocumenteerd.
Als de validatie mislukt, schakelt u de nieuwe NAT-regels en routes uit, herstelt u de vorige tunnelconfiguratie en test u het oorspronkelijke lokale verkeer opnieuw. 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.