FortiGate achter NAT: local-gw, localid en het publieke IP

Een FortiGate achter NAT kan 10.0.0.2 bezitten op zijn WAN-interface, terwijl het internet hem presenteert als 198.51.100.40, en beide nummers zijn echt. Het adres waaraan het apparaat bindt en de identiteit die het tijdens IKE-authenticatie stuurt, zijn afzonderlijke keuzes, gemaakt in afzonderlijke velden, voor afzonderlijk publiek. NAT herschrijft de buitenste adressering onderweg; het herschrijft een geauthenticeerde identiteit niet naar wat de verre peer verwacht. De meeste fouten in fase 1 in deze vorm komen doordat de juiste waarde in het verkeerde veld belandt.

Drie waarden, drie eigenaren

Begin met het benoemen van de drie waarden en wie elk ervan bezit. local-gw is het adres dat de FortiGate als bron voor IKE op zijn externe interface gebruikt, en het moet een adres zijn dat het apparaat werkelijk heeft. Het publieke eindpunt is het adres van het NAT-apparaat en is eigendom van degene die de vertaling uitvoert. De IKE-identiteit is een tekenreeks die de peer met zijn eigen configuratie vergelijkt, en die hoeft helemaal geen IP-adres te zijn.

De veldnamen liggen dicht genoeg bij elkaar om verwisseling uit te lokken, en dat is de valkuil. localid en localid-type beschrijven identificatie; local-gw beschrijft lokale binding.

Een voorbeeld maakt het onderscheid concreet. Open op de FortiGate config vpn ipsec phase1-interface, dan set interface "wan1" en set local-gw 10.0.0.2 — een adres dat de doos bezit, en dat is wat de IKE-socket met succes laat binden. Laat local-gw op 0.0.0.0 staan en het interfaceadres wordt gebruikt, wat meestal hetzelfde is maar minder expliciet. Zet local-gw niet op 198.51.100.40, want het apparaat bezit dat adres niet en de socket zal er niet aan binden. Twee waarden op papier gelijk laten lijken is geen configuratie.

Stap 1: kies de identiteit die de peer accepteert

Nu de identiteit, wat een andere beslissing is. set localid neemt de waarde die de peer vergelijkt, en set localid-type vertelt de FortiGate hoe die te interpreteren: een adres, een FQDN, een gebruikers-FQDN of een sleutel-ID. Met auto leidt het apparaat die af, meestal uit het adres van de uitgaande interface, precies de waarde die een NAT-apparaat op het punt staat te wijzigen.

Die afleiding is de reden waarom een expliciete identiteit in deze topologie belangrijk is. Als de peer een adresidentiteit verwacht, zet localid-type address en localid op het publieke adres dat de peer zal zien, en bevestig dan dat de peer die waarde als identiteit accepteert en niet als routeringsdoel. Als de peer een FQDN verwacht, gebruik localid-type fqdn en de naam waarmee die is geconfigureerd. Controleer met diagnose vpn ike gateway list wat er werkelijk is verzonden; dat toont de gatewaystatus en de gebruikte identificaties, niet wat u van plan was te typen. Ga er niet van uit dat een identiteitstype-optie een willekeurig niet-lokaal adres accepteert; controleer eerst de gedocumenteerde semantiek van de release.

Stap 2: stuur UDP 500 en 4500 door naar het apparaat

De derde waarde is eigendom van het NAT-apparaat, en dat is degene die mensen vergeten te controleren. Het publieke eindpunt moet UDP 500 en UDP 4500 doorsturen naar de FortiGate, omdat NAT-T-detectie en de daaropvolgende ingekapselde ESP beide afhankelijk zijn van het aankomen van die poorten. Dit ontwerp veronderstelt een een-op-een-toewijzing; het delen van één publiek adres via poorten tussen meerdere peers is een andere topologie met andere grenzen.

Bevestig de doorsturing met een opname en niet met hoop: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 toont of pakketten aankomen en of antwoorden vertrekken.

Google Cloud VPN documenteert een-op-een-NAT met NAT-T als de ondersteunde regeling voor een peer achter NAT, en dat is de beperking waartegen moet worden ontworpen als de verre kant een Cloud VPN-gateway is. Een-op-veel of delen via poorten is niet dezelfde ondersteunde topologie, en geen enkele lokale identiteitsafstemming verandert dat. Als de verre zijde een ander apparaat is, bepaalt de eigen documentatie daarvan wat het als identiteit accepteert en of het een vertaald peeradres tolereert. Lees dat voordat u een lokaal veld wijzigt, want de lokale zijde kan geen regel onderhandelen die de verre zijde niet implementeert.

Stap 3: controleer wat fase 1 niet oplost

NAT-traversal brengt de tunnel omhoog, identiteitsovereenstemming bepaalt of de peer die accepteert, en routering van het binnenste prefix bepaalt wat er werkelijk passeert. Een correcte lokale ID kan geen ontbrekende statische route of ontbrekende verkeersselector leveren.

Controleer dus in lagen. get vpn ipsec tunnel details toont of de tunnel omhoog is en welke selectors zijn onderhandeld, en een verschil tussen het geconfigureerde verre subnet en de onderhandelde selector is een routeringsprobleem in een fase 2-kostuum. execute vpn ike gateway clear forceert een nieuwe onderhandeling, dus u test de huidige configuratie en niet een sessie die vóór uw laatste wijziging tot stand kwam. Stuur daarna verkeer naar een host in het verre prefix en bevestig dat de tellers bewegen, want een tunnel die omhoog staat en niets doorlaat ziet er identiek uit als een werkende tot u het controleert.

Houd de drie waarden op één plek in uw notities: het lokale adres dat het apparaat bezit, het publieke eindpunt dat het NAT-apparaat presenteert, en de identiteitstekenreeks die de peer verwacht. Ze veranderen om verschillende redenen en op verschillende momenten.

Het hernummeren van het NAT-apparaat is geen reden om local-gw van de FortiGate aan te raken, en een identiteitswijziging is geen reden om iets te hernummeren. De twee door elkaar halen is hoe een werkende tunnel tijdens een losstaand onderhoudsvenster opnieuw wordt opgebouwd. De Cloud VPN NAT-richtlijn is de referentie voor de ondersteunde topologie aan die kant.

De test die het beslecht is saai en snel: leg vast op de externe interface, bevestig dat UDP 500 en 4500 van de peer aankomen, bevestig dat de identiteit in de IKE-uitwisseling overeenkomt met wat de peer geconfigureerd was te verwachten, en bevestig dan dat de onderhandelde selectors de subnetten dekken die u belangrijk vindt. Als de eerste controle faalt, is het NAT-apparaat de verdachte. Als de tweede faalt, zijn het de identiteitsvelden. Als de derde faalt, waren NAT noch identiteit ooit het probleem.