GCP HA VPN rechaza FortiGate: el tipo de ID local no coincide
Google compara la identidad que declara un FortiGate, no solo la clave precompartida. Un ID local de tipo FQDN falla esa comprobación mientras el registro sigue diciendo autenticación.
El AUTHENTICATION_FAILED de Google Cloud HA VPN suele devolver a la gente a la clave precompartida, y la clave normalmente es correcta. El túnel se atasca en la fase 1 porque Google compara algo más: la identidad que el par declara durante el intercambio IKE. En un FortiGate esa identidad puede cambiar de tipo sin que nadie edite una dirección. Lea el registro como una discrepancia de identidad una vez que la clave se ha vuelto a introducir dos veces.
Un fallo, dos comprobaciones
IKE verifica un par en dos pasos separados. La clave precompartida demuestra que ambos extremos tienen el mismo secreto, y una identidad declarada dice al respondedor quién afirma ser el par. Google comprueba esa identidad contra el par con el que se configuró. Si se deja solo, un FortiGate envía una identidad basada en dirección derivada de su interfaz de salida, y la comparación pasa sin que nadie lo note.
Ambos pasos caen en el mismo cajón del registro, lo que explica el conocido bucle de reescribir la clave cuatro veces antes de que alguien lea la carga de identidad.
Qué pone un FortiGate en la carga de identidad
El problema empieza cuando alguien fija un ID local para que ambos lados coincidan. Las compilaciones recientes de FortiOS marcan esa identidad como un nombre de dominio totalmente cualificado incluso cuando el valor escrito es una dirección con puntos. Google recibe por tanto una identidad FQDN mientras espera una dirección, y rechaza la sesión. Nada en el mensaje dice qué mitad falló, así que el informe se lee como un fallo de autenticación.
Repródalo una vez con la depuración IKE activada y lea la carga de identidad que el cortafuegos emite realmente.
En la misma pasada, confirme tres hechos baratos: la versión de IKE que usan ambos extremos, la clave exacta incluidos los caracteres finales invisibles, y la dirección del par que Google espera. Responden a preguntas distintas, y una clave coincidente no dice nada sobre la identidad.
Opciones y qué cuesta cada una
Cada salida arregla una capa distinta, y ninguna está disponible para todo despliegue.
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
Corregir la identidad en el cortafuegos es la respuesta más limpia donde el firmware le permite elegir el tipo y conservar el valor. El campo existe en algunas compilaciones y rellena mal el tipo en otras, así que pruebe su versión en vez de fiarse de las notas de la versión.
Una dirección pública enrutable en la interfaz de negociación es el rodeo documentado, porque entonces la identidad por defecto coincide con lo que Google espera y no hace falta ninguna anulación. Es donde acaban la mayoría de despliegues, si el cortafuegos puede siquiera mantener tal dirección.
Terminar en un par que valida lo que usted produce es un cambio de topología. Trátelo como una decisión de diseño y no como un rodeo con una descripción más amable.
Cuando NAT elimina una opción
Detrás de NAT la salida por dirección pública desaparece, y lo que queda depende de un comportamiento del firmware que usted no controla. Ese es el punto para elegir deliberadamente entre actualizar, reubicar el par o aceptar otro punto final en la nube. Son tres presupuestos distintos, y elegir uno por accidente es como un rodeo temporal se convierte en arquitectura. Escriba la elección y su motivo junto al túnel.
Antes de interpretar nada de esto, confirme el estado del túnel en el lado de Google y que IKE no se está simplemente descartando en el camino. Un paquete descartado caduca; no produce un rechazo.
Qué anotar mientras funciona
Anote el tipo de identidad, su valor, la versión del firmware y la dirección del par que estaban vigentes cuando el túnel subió por última vez. Una actualización del firmware puede volver a cambiar el valor por defecto, y el siguiente fallo se verá exactamente como una discrepancia de clave. Con la identidad guardada junto a la clave y la dirección del par, la siguiente persona empieza por las comprobaciones baratas.
Ese registro es también la única forma de saber si un rodeo sigue siendo necesario tras la próxima actualización.