FortiGate detrás de NAT: local-gw, localid y la IP pública

Un FortiGate detrás de NAT puede tener 10.0.0.2 en su interfaz WAN mientras internet lo presenta como 198.51.100.40, y ambos números son reales. La dirección a la que se vincula el dispositivo y la identidad que envía durante la autenticación IKE son decisiones separadas, tomadas en campos separados, para audiencias separadas. NAT reescribe el direccionamiento exterior al pasar; no reescribe una identidad autenticada en lo que espera el peer remoto. La mayoría de fallos de fase 1 en esta forma vienen de poner el valor correcto en el campo equivocado.

Tres valores, tres propietarios

Empiece nombrando los tres valores y quién posee cada uno. local-gw es la dirección que FortiGate usa como origen de IKE en su interfaz externa, y debe ser una dirección que el dispositivo realmente tenga. El extremo público es la dirección del dispositivo NAT, y la posee quien realiza la traducción. La identidad IKE es una cadena que el peer compara con su propia configuración, y no es necesario que sea una dirección IP en absoluto.

Los nombres de los campos son lo bastante parecidos como para invitar a la sustitución, y esa es la trampa. localid y localid-type describen la identificación; local-gw describe el enlace local.

Un ejemplo hace concreta la distinción. En el FortiGate, abra config vpn ipsec phase1-interface, luego set interface "wan1" y set local-gw 10.0.0.2 — una dirección que la caja posee, y eso es lo que hace que el socket IKE se enlace correctamente. Deje local-gw en 0.0.0.0 y se usa la dirección de la interfaz, que suele ser lo mismo pero menos explícito. No ponga local-gw en 198.51.100.40, porque el dispositivo no posee esa dirección y el socket no se enlazará a ella. Hacer que dos valores parezcan iguales sobre el papel no es una configuración.

Paso 1: elija la identidad que el peer aceptará

Ahora la identidad, que es una decisión distinta. set localid toma el valor que el peer comparará, y set localid-type dice al FortiGate cómo interpretarlo: una dirección, un FQDN, un FQDN de usuario o un ID de clave. Con auto el dispositivo la deriva, normalmente de la dirección de la interfaz de salida, que es exactamente el valor que un dispositivo NAT está a punto de cambiar.

Esa derivación es la razón por la que una identidad explícita importa en esta topología. Si el peer espera una identidad de dirección, ponga localid-type address y localid en la dirección pública que el peer verá, y luego confirme que el peer acepta ese valor como identidad y no como destino de enrutamiento. Si el peer espera un FQDN, use localid-type fqdn y el nombre con el que se configuró. Verifique qué se envió realmente con diagnose vpn ike gateway list, que muestra el estado de la pasarela y los identificadores en uso, no lo que pensaba escribir. No asuma que una opción de tipo de identidad acepta una dirección no local arbitraria; compruebe primero la semántica documentada de la versión.

Paso 2: reenvíe UDP 500 y 4500 al dispositivo

El tercer valor pertenece al dispositivo NAT, y es el que la gente olvida comprobar. El extremo público debe reenviar UDP 500 y UDP 4500 al FortiGate, porque la detección de NAT-T y el ESP encapsulado que sigue dependen ambos de que lleguen esos puertos. Este diseño asume una correspondencia uno a uno; compartir una única dirección pública por puertos entre varios peers es otra topología con otros límites.

Confirme el reenvío con una captura y no con una esperanza: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 muestra si llegan paquetes y si salen respuestas.

Google Cloud VPN documenta NAT uno a uno con NAT-T como la disposición admitida para un peer detrás de NAT, y esa es la restricción con la que hay que diseñar si el extremo remoto es una pasarela de Cloud VPN. Compartir uno a muchos o por puertos no es la misma topología admitida, y ningún ajuste local de identidad lo cambia. Si el lado remoto es otro dispositivo, su propia documentación define qué aceptará como identidad y si tolera una dirección de peer traducida. Léalo antes de cambiar un campo local, porque el lado local no puede negociar una regla que el lado remoto no implementa.

Paso 3: compruebe qué no resuelve la fase 1

El recorrido NAT levanta el túnel, el acuerdo de identidad decide si el peer lo acepta, y el enrutamiento del prefijo interno decide qué cruza realmente. Un ID local correcto no puede suplir una ruta estática ausente ni un selector de tráfico ausente.

Así que verifique por capas. get vpn ipsec tunnel details muestra si el túnel está levantado y qué selectores se negociaron, y una discrepancia entre la subred remota configurada y el selector negociado es un problema de enrutamiento con disfraz de fase 2. execute vpn ike gateway clear fuerza una renegociación, así que prueba la configuración actual y no una sesión establecida antes de su último cambio. Luego envíe tráfico a un host del prefijo remoto y confirme que los contadores se mueven, porque un túnel levantado que no pasa nada es idéntico a uno que funciona hasta que lo comprueba.

Mantenga los tres valores en un solo lugar en sus notas: la dirección local que posee el dispositivo, el extremo público que presenta el dispositivo NAT y la cadena de identidad que espera el peer. Cambian por motivos distintos y en momentos distintos.

Renumerar el dispositivo NAT no es motivo para tocar el local-gw del FortiGate, y un cambio de identidad no es motivo para renumerar nada. Mezclar las dos cosas es cómo se reconstruye un túnel que funciona durante una ventana de mantenimiento no relacionada. La guía de NAT de Cloud VPN es la referencia para la topología admitida en ese lado.

La prueba que lo resuelve es aburrida y rápida: capture en la interfaz externa, confirme que UDP 500 y 4500 llegan del peer, confirme que la identidad en el intercambio IKE coincide con lo que el peer estaba configurado para esperar, y luego confirme que los selectores negociados cubren las subredes que le importan. Si la primera comprobación falla, el sospechoso es el dispositivo NAT. Si falla la segunda, son los campos de identidad. Si falla la tercera, ni NAT ni identidad fueron nunca el problema.