GCP HA VPN rejette le FortiGate : type d’ID local incompatible
Google compare l’identité qu’un FortiGate revendique, pas seulement la clé pré-partagée. Un ID local de type FQDN échoue à ce contrôle alors que le journal parle encore d’authentification.
L’AUTHENTICATION_FAILED de Google Cloud HA VPN renvoie généralement les gens vers la clé pré-partagée, et la clé est normalement correcte. Le tunnel se bloque en phase 1 parce que Google compare aussi autre chose : l’identité que le pair revendique pendant l’échange IKE. Sur un FortiGate, cette identité peut changer de type sans que personne ne modifie une adresse. Lisez le journal comme une incompatibilité d’identité une fois la clé ressaisie deux fois.
Un échec, deux contrôles
IKE vérifie un pair en deux étapes distinctes. La clé pré-partagée prouve que les deux extrémités détiennent le même secret, et une identité revendiquée indique au répondeur qui le pair prétend être. Google compare cette identité au pair avec lequel il a été configuré. Laissé seul, un FortiGate envoie une identité fondée sur une adresse, dérivée de son interface sortante, et la comparaison passe sans que personne ne s’en aperçoive.
Les deux étapes tombent dans le même seau du journal, ce qui explique la boucle familière consistant à ressaisir la clé quatre fois avant que quelqu’un ne lise la charge utile d’identité.
Ce qu’un FortiGate met dans la charge utile d’identité
Le problème commence quand quelqu’un définit un ID local pour faire coïncider les deux côtés. Les versions récentes de FortiOS marquent cette identité comme un nom de domaine pleinement qualifié, même lorsque la valeur saisie est une adresse pointée. Google reçoit donc une identité FQDN alors qu’il attend une adresse, et il refuse la session. Rien dans le message ne dit quelle moitié a échoué, si bien que le rapport se lit comme un échec d’authentification.
Reproduisez-le une fois avec le débogage IKE activé et lisez la charge utile d’identité que le pare-feu émet réellement.
Dans la même passe, confirmez trois faits peu coûteux : la version d’IKE utilisée par les deux extrémités, la clé exacte, y compris les caractères finaux invisibles, et l’adresse du pair que Google attend. Ils répondent à des questions différentes, et une clé identique ne dit rien de l’identité.
Les options, et ce que chacune coûte
Chaque sortie corrige une couche différente, et aucune n’est disponible pour tous les déploiements.
| 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 |
Corriger l’identité sur le pare-feu est la réponse la plus propre là où le micrologiciel permet de choisir le type et de conserver la valeur. Le champ existe dans certaines versions et remplit mal le type dans d’autres, alors testez votre version au lieu de faire confiance aux notes de version.
Une adresse publique routable sur l’interface de négociation est le contournement documenté, car l’identité par défaut correspond alors à ce que Google attend et aucune substitution n’est nécessaire. C’est là que la plupart des déploiements aboutissent, si le pare-feu peut seulement détenir une telle adresse.
Terminer sur un pair qui valide ce que vous produisez est un changement de topologie. Traitez-le comme une décision de conception et non comme un contournement à la description plus aimable.
Quand NAT supprime une option
Derrière NAT, la sortie par adresse publique disparaît, et ce qui reste dépend d’un comportement du micrologiciel que vous ne maîtrisez pas. C’est le moment de choisir délibérément entre mettre à niveau, déplacer le pair ou accepter un autre point de terminaison cloud. Ce sont trois budgets différents, et en choisir un par accident est la façon dont un contournement temporaire devient de l’architecture. Écrivez le choix et sa raison à côté du tunnel.
Avant d’interpréter quoi que ce soit, confirmez l’état du tunnel côté Google et que IKE n’est pas simplement abandonné en route. Un paquet abandonné expire ; il ne produit pas de rejet.
Ce qu’il faut noter pendant que ça marche
Notez le type d’identité, sa valeur, la version du micrologiciel et l’adresse du pair qui étaient en vigueur lors de la dernière montée du tunnel. Une mise à jour du micrologiciel peut changer à nouveau la valeur par défaut, et la panne suivante ressemblera exactement à une incompatibilité de clé. Avec l’identité stockée à côté de la clé et de l’adresse du pair, la personne suivante commence par les contrôles peu coûteux.
Cette trace est aussi le seul moyen de savoir si un contournement est encore nécessaire après la prochaine mise à niveau.