FortiGate derrière NAT : local-gw, localid et l'IP publique

Un FortiGate derrière NAT peut posséder 10.0.0.2 sur son interface WAN alors qu'internet le présente comme 198.51.100.40, et les deux nombres sont réels. L'adresse à laquelle l'équipement se lie et l'identité qu'il envoie pendant l'authentification IKE sont des choix distincts, faits dans des champs distincts, pour des publics distincts. NAT réécrit l'adressage externe au passage ; il ne réécrit pas une identité authentifiée en ce que le peer distant attend. La plupart des échecs de phase 1 dans cette forme viennent du fait de mettre la bonne valeur dans le mauvais champ.

Trois valeurs, trois propriétaires

Commencez par nommer les trois valeurs et qui possède chacune. local-gw est l'adresse que le FortiGate utilise comme source pour IKE sur son interface externe, et elle doit être une adresse que l'équipement possède réellement. Le point de sortie public est l'adresse de l'équipement NAT, possédée par celui qui effectue la traduction. L'identité IKE est une chaîne que le peer compare à sa propre configuration, et elle n'a pas du tout besoin d'être une adresse IP.

Les noms des champs sont assez proches pour inviter à la substitution, et c'est le piège. localid et localid-type décrivent l'identification ; local-gw décrit la liaison locale.

Un exemple rend la distinction concrète. Sur le FortiGate, ouvrez config vpn ipsec phase1-interface, puis set interface "wan1" et set local-gw 10.0.0.2 — une adresse que la machine possède, et c'est ce qui permet au socket IKE de se lier correctement. Laissez local-gw à 0.0.0.0 et l'adresse de l'interface est utilisée, ce qui est généralement la même chose mais moins explicite. Ne réglez pas local-gw sur 198.51.100.40, car l'équipement ne possède pas cette adresse et le socket ne s'y liera pas. Faire paraître deux valeurs égales sur le papier n'est pas une configuration.

Étape 1 : choisissez l'identité que le peer acceptera

Maintenant l'identité, qui est une décision différente. set localid prend la valeur que le peer comparera, et set localid-type indique au FortiGate comment l'interpréter : une adresse, un FQDN, un FQDN utilisateur ou un ID de clé. Avec auto l'équipement la dérive, généralement de l'adresse de l'interface sortante, qui est exactement la valeur qu'un équipement NAT s'apprête à changer.

Cette dérivation est la raison pour laquelle une identité explicite compte dans cette topologie. Si le peer attend une identité d'adresse, réglez localid-type address et localid sur l'adresse publique que le peer verra, puis confirmez que le peer accepte cette valeur comme une identité et non comme une cible de routage. Si le peer attend un FQDN, utilisez localid-type fqdn et le nom avec lequel il a été configuré. Vérifiez ce qui a réellement été envoyé avec diagnose vpn ike gateway list, qui montre l'état de la passerelle et les identifiants utilisés plutôt que ce que vous comptiez saisir. Ne supposez pas qu'une option de type d'identité accepte une adresse non locale arbitraire ; vérifiez d'abord la sémantique documentée de la version.

Étape 2 : transférez UDP 500 et 4500 vers l'équipement

La troisième valeur appartient à l'équipement NAT, et c'est celle que les gens oublient de vérifier. Le point de sortie public doit transférer UDP 500 et UDP 4500 vers le FortiGate, car la détection NAT-T et l'ESP encapsulé qui suit dépendent tous deux de l'arrivée de ces ports. Cette conception suppose une correspondance un pour un ; le partage par ports d'une seule adresse publique entre plusieurs peers est une autre topologie avec d'autres limites.

Confirmez le transfert par une capture plutôt que par un espoir : diagnose sniffer packet any "udp port 500 or udp port 4500" 4 montre si les paquets arrivent et si les réponses partent.

Google Cloud VPN documente le NAT un pour un avec NAT-T comme la disposition prise en charge pour un peer derrière NAT, et c'est la contrainte à respecter si l'extrémité distante est une passerelle Cloud VPN. Le partage un vers plusieurs ou par ports n'est pas la même topologie prise en charge, et aucun réglage local d'identité n'y change rien. Si le côté distant est un autre équipement, sa propre documentation définit ce qu'il acceptera comme identité et s'il tolère une adresse de peer traduite. Lisez-la avant de modifier un champ local, car le côté local ne peut pas négocier une règle que le côté distant n'implémente pas.

Étape 3 : vérifiez ce que la phase 1 ne résout pas

La traversée NAT monte le tunnel, l'accord d'identité décide si le peer l'accepte, et le routage du préfixe interne décide de ce qui passe réellement. Un ID local correct ne peut pas fournir une route statique manquante ni un sélecteur de trafic manquant.

Vérifiez donc par couches. get vpn ipsec tunnel details montre si le tunnel est monté et quels sélecteurs ont été négociés, et un écart entre le sous-réseau distant configuré et le sélecteur négocié est un problème de routage déguisé en phase 2. execute vpn ike gateway clear force une renégociation, vous testez donc la configuration actuelle et non une session établie avant votre dernière modification. Envoyez ensuite du trafic vers un hôte du préfixe distant et confirmez que les compteurs bougent, car un tunnel monté qui ne fait rien passer est identique à un tunnel fonctionnel jusqu'à ce que vous vérifiiez.

Gardez les trois valeurs au même endroit dans vos notes : l'adresse locale que possède l'équipement, le point de sortie public que présente l'équipement NAT et la chaîne d'identité que le peer attend. Elles changent pour des raisons différentes et à des moments différents.

Une renumérotation de l'équipement NAT n'est pas une raison de toucher au local-gw du FortiGate, et un changement d'identité n'est pas une raison de renuméroter quoi que ce soit. Mélanger les deux, c'est ainsi qu'un tunnel qui fonctionne est reconstruit pendant une fenêtre de maintenance sans rapport. Le guide NAT de Cloud VPN est la référence pour la topologie prise en charge de ce côté.

Le test qui tranche est ennuyeux et rapide : capturez sur l'interface externe, confirmez que UDP 500 et 4500 arrivent du peer, confirmez que l'identité dans l'échange IKE correspond à ce que le peer était configuré pour attendre, puis confirmez que les sélecteurs négociés couvrent les sous-réseaux qui vous importent. Si la première vérification échoue, l'équipement NAT est le suspect. Si la deuxième échoue, ce sont les champs d'identité. Si la troisième échoue, ni NAT ni l'identité n'ont jamais été le problème.