L2TP NO_PROPOSAL_CHOSEN : quelle phase a réellement échoué ?

NO_PROPOSAL_CHOSEN arrive avant que le moindre nom d’utilisateur PPP soit examiné, ce qui est un fait utile et aussi la raison pour laquelle le message trompe. Il signale qu’un côté a rejeté une proposition ; il ne précise pas quel paramètre divergeait et ne dit rien sur le fait que le rejet a eu lieu pendant la construction de l’association IKE ou plus tard, pendant la négociation de la protection du trafic. Deux correctifs différents se cachent derrière ces deux possibilités, et un seul engage la case PFS vers laquelle on se tourne d’abord.

Un message, deux ensembles de propositions

La disposition IKEv1 L2TP/IPsec comporte deux négociations successives. La phase 1 construit l’association de sécurité IKE à partir d’un algorithme de chiffrement, d’un algorithme d’intégrité et d’un groupe Diffie-Hellman. La phase 2 négocie ensuite la protection du trafic, et l’exigence de PFS appartient à cette seconde conversation.

Comme les phases sont séquentielles, la position de l’échec vous indique quelle liste comparer. C’est toute la valeur diagnostique du message, et elle mérite d’être extraite avant de toucher à un réglage.

Pourquoi une case PFS ne peut pas réparer la phase 1

Désactiver PFS change une propriété de la phase 2. Si les pairs ne se sont jamais entendus sur la phase 1, la conversation ESP n’a jamais lieu, donc la case n’a aucun effet sur le rejet, et c’est pourquoi la basculer produit la même erreur avec un horodatage différent.

L’erreur inverse est tout aussi fréquente. Une association IKE réussie ne prouve pas que la proposition ESP est acceptable, et elle ne prouve certainement pas que le groupe de la phase 2 correspond. Traitez un tunnel de gestion établi comme une preuve concernant la phase 1 seulement. Les gens lisent la ligne verte comme « le tunnel est monté », puis passent une heure sur la mauvaise phase parce que rien ne leur a dit que la seconde négociation n’avait pas commencé.

Lisez le journal avant de choisir les algorithmes

Recueillez les messages qui précèdent immédiatement le rejet depuis le backend qui traite réellement la connexion, et corrélez-les avec la même tentative. Sans cette corrélation, vous lisez l’historique d’une autre connexion et en tirez des conclusions.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

À partir de ces lignes, répondez à deux questions : une association de phase 1 s’est-elle établie, et quel échange a échoué. Ces deux réponses réduisent la recherche à une seule liste d’attributs. Une notification nue sans contexte autour ne peut pas le faire, aussi tentant soit-il de essayer une proposition tirée d’un fil de forum. Copier une chaîne qui fonctionne depuis une machine dotée d’un autre backend remplace généralement un rejet par un autre, un peu plus tard.

La syntaxe du backend ne voyage pas

Notez la version de NetworkManager-l2tp et celle du backend IPsec avant de comparer quoi que ce soit. Libreswan et strongSwan ne partagent ni la syntaxe des propositions ni des jeux d’algorithmes identiques, si bien qu’une chaîne qui fonctionne dans l’un est une erreur de syntaxe dans l’autre. Le backend installé peut aussi refuser IKEv1 par politique, auquel cas aucune proposition ne sera jamais acceptée.

Le README du projet documente ces différences entre backends et garde les champs de phase 1 et de phase 2 séparés. Lisez-le comme une documentation de la structure, non comme une invitation à activer chaque chiffrement historique et un groupe faible, car une connexion qui ne réussit qu’ainsi n’est pas celle qu’on vous a demandé de construire.

Convenez de la suite, puis vérifiez les étapes

Demandez à l’exploitant de la passerelle quelles suites IKE et ESP sont prises en charge et approuvées, puis comparez cette réponse aux propositions effectives du client plutôt qu’à son fichier de configuration. Si le désaccord porte précisément sur le PFS de phase 2, retenez un groupe pris en charge ou une politique sans PFS explicitement approuvée. N’inférez pas la politique du nom de l’erreur.

Quand le seul recouvrement exige une cryptographie que l’organisation n’accepte plus, la décision revient à la passerelle ou à une migration de protocole. Élargir la chaîne du client jusqu’à ce que quelque chose négocie est une façon de livrer une faiblesse connue avec une coche verte à côté.

Après avoir corrigé la vraie divergence, confirmez l’établissement d’IPsec avant d’examiner L2TP et PPP, et traitez tout rejet d’authentification ultérieur comme relevant de l’étape suivante. Testez ensuite le renouvellement dans le processus de test approuvé, car établir la première association ne dit rien du reste de sa durée de vie.