FortiGate Azure rekey : la proposition de SA du peer ne correspond pas à la politique locale

Le tunnel est monté, le trafic a circulé, et plus tard le journal affiche peer SA proposal not match local policy. La plupart des gens lisent cette ligne comme la preuve que les deux configurations n’ont jamais correspondu. Elle signifie généralement quelque chose de plus étroit : elles correspondaient pour la première CHILD SA et ont cessé de correspondre au premier renouvellement, parce que la première association n’a jamais eu besoin de l’échange qu’effectuent les suivantes. C’est cette distinction qui décide où chercher.

La première CHILD SA hérite, les suivantes négocient

Dans IKEv2, la CHILD SA initiale est créée pendant IKE_AUTH, et ses clés sont dérivées du matériel de clé de l’IKE SA. Il n’y a pas d’échange Diffie-Hellman séparé à ce moment-là, donc un groupe PFS qu’un peer ne peut pas accepter n’est simplement pas encore testé. Le tunnel paraît sain parce que l’exigence à laquelle vous échouerez plus tard n’a jamais été éprouvée.

Un renouvellement de clé CHILD_SA est une autre séquence de messages. Quand PFS est configuré, les peers exécutent un nouvel échange de clés et doivent s’accorder sur un groupe que les deux côtés acceptent, ainsi que sur la proposition ESP de la nouvelle association. C’est le moment où l’écart devient visible, et c’est pourquoi l’erreur nomme une proposition plutôt qu’une route.

Donc « ça marchait hier » ne vous dit rien sur la proposition. Cela vous dit que l’échange initial a réussi, ce que vous saviez déjà.

Lisez l’échange échoué, pas le premier ping

Recueillez l’authentification IKE réussie, la CHILD SA initiale et le remplacement échoué des deux côtés avant de changer quoi que ce soit. Nommez ensuite l’opération avec précision : le renouvellement de clé de l’IKE SA, la réauthentification IKE et le renouvellement de clé de la CHILD SA sont trois événements différents, et « phase 2 » les couvre tous dans une conversation courante.

Comparez les champs ci-dessous pour la connexion qui a échoué, pas pour le tunnel en général.

Sur le FortiGate, ouvrez la proposition de phase-2, le réglage PFS et les groupes DH acceptés pour ce tunnel. Lisez les valeurs chargées plutôt que de les déduire d’une connexion établie auparavant. Une capture d’écran de la page de l’interface graphique est une preuve plus faible que la configuration en cours, car les deux peuvent diverger après une mise à niveau. Exportez la section que vous avez modifiée et conservez-la avec le ticket.

La politique par défaut d’Azure reste une politique

L’absence de politique personnalisée attachée à la connexion ne signifie pas qu’Azure n’en applique aucune. La connexion se rabat sur le jeu de propositions par défaut de la passerelle, qui peut être plus large ou plus étroit que ce que propose votre FortiGate. Si les deux ensembles se recouvrent pour IKE mais pas pour ESP avec PFS, vous obtenez exactement ce schéma d’échec.

Cette vue en lecture seule montre la politique réellement attachée, sans déverser de secrets :

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

Utilisez les vrais noms de vos ressources. Quand une politique explicite est nécessaire, définissez-la sur la ressource de connexion. Ce n’est pas un commutateur à l’échelle de la passerelle, et elle ne s’applique pas silencieusement aux autres tunnels de la même passerelle.

Dans le portail, la page Configuration de cette connexion est l’endroit où va une politique IPsec/IKE personnalisée. Le guide Microsoft des politiques personnalisées répertorie les paramètres pris en charge et les exigences de SKU. Azure prend une combinaison complète par connexion, donc vous spécifiez les champs IKE et les champs IPsec ensemble, pas un à la fois.

PFS est une exigence, pas un commutateur à basculer

Si votre base de sécurité exige PFS, la solution est un groupe que les deux peers acceptent des deux côtés, exprimé par une politique correspondante. Désactiver PFS pour faire disparaître l’erreur modifie la propriété de sécurité que vous cherchiez à conserver, et elle réapparaît généralement plus tard sous forme d’un autre écart.

Un piège propre à Azure : quand vous choisissez GCM pour ESP, les sélections de chiffrement et d’intégrité doivent nommer le même algorithme GCM et la même longueur de clé. Mélanger un chiffrement GCM avec un algorithme d’intégrité distinct produit une combinaison que le service rejette, et cela ressemble à un écart entre peers jusqu’à ce que vous lisiez la politique attentivement.

Choisissez la combinaison la plus forte que les deux extrémités prennent en charge et que votre exigence autorise, puis consignez-la dans le journal des changements. La personne suivante comparera à ce journal, pas au souvenir d’un tunnel qui fonctionnait. Inscrivez-y le groupe PFS et la proposition ESP, pas seulement le nom de la politique. Quand quelqu’un demandera plus tard pourquoi un audit a échoué ou pourquoi un renouvellement est lent, cette ligne répond aux deux questions.

Vérifiez l’échange qui a échoué

Planifiez le changement avec un chemin de retour, car modifier la politique peut interrompre le tunnel que vous essayez de réparer. Une fois le trafic revenu, attendez ou déclenchez un renouvellement de CHILD_SA et confirmez que la nouvelle association est établie avec le groupe PFS prévu. Confirmez ensuite que le trafic applicatif continue de passer par elle.

Deux fausses pistes méritent d’être nommées. Les durées de vie des SA sont des spécifications locales, donc des valeurs inégales sont normales et les changer ne fait que déplacer le moment où le problème apparaît. DPD détecte si un peer est vivant ; augmenter son délai d’attente n’aligne pas les choix ESP ou PFS.

Consignez le résultat négocié et l’événement suivant après le changement. Si la connexion échoue maintenant avant la fin de l’authentification IKE, vous regardez les réglages IKE que vous venez de modifier, pas l’échec initial de renouvellement de la CHILD.