NO_PROPOSAL_CHOSEN en L2TP ? Examinez d’abord la passerelle

L’invite du nom d’utilisateur n’apparaît jamais, et le client signale NO_PROPOSAL_CHOSEN. À ce stade, les identifiants et la clé prépartagée sont sans importance, car les deux extrémités ne se sont pas accordées sur la manière de protéger la phase 1. La plupart des gens réagissent en collant une chaîne de chiffrement trouvée en ligne. Une analyse de la passerelle répond à la même question avec des preuves et prend à peu près le même temps.

Ce que le message exclut

Le rejet se produit en mode principal, avant tout échange L2TP ou PPP, donc le tunnel et la base d’utilisateurs n’ont pas été consultés. La phase 1 négocie le chiffrement, l’intégrité et un groupe Diffie-Hellman. La phase 2 négocie la proposition ESP pour les données. Une défaillance de la phase 1 ne se corrige pas en modifiant un réglage PFS de la phase 2, et une association IKE terminée ne prouve pas que la proposition ESP convient.

Notez le backend avant de modifier la syntaxe : ipsec --version. libreswan et strongSwan acceptent des orthographes différentes de la proposition pour les mêmes algorithmes.

Lisez ensuite le rejet dans son contexte avec journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Analysez la passerelle pour connaître son jeu de transformations

Un scanner demande directement à la passerelle quelles transformations elle négociera. Arrêtez d’abord le service IPsec local pour que la sonde ne concurrence pas votre propre client, puis lisez les lignes SA. Traitez la liste comme une preuve concernant l’homologue, non comme un menu à activer en bloc.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Les équipements plus anciens proposent souvent 3DES, SHA1 et MODP1024, car c’étaient les valeurs par défaut à la livraison du produit et personne ne les a revues. Conservez la sortie brute de l’analyse, car c’est la seule trace de ce que l’homologue proposait ce jour-là. Si c’est le chevauchement le plus fort disponible, l’escalade correcte va vers le propriétaire de la passerelle, pas vers une configuration client qui réactive une cryptographie faible pour tout le monde.

Faites correspondre le chevauchement sans désactiver la sécurité

Ne saisissez que les transformations présentes à la fois dans l’analyse et dans votre politique. L’exemple ci-dessous reflète une passerelle proposant 3DES, SHA1 et MODP1024 en phase 1. Notez la réserve sur le backend : libreswan 4.x ne compile pas le groupe modp1024, donc cela vaut pour strongSwan ou une compilation de libreswan avec prise en charge de DH2. Vérifiez la version avant de conclure que le client est défectueux.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Un point d’exclamation final épingle une seule proposition. Servez-vous-en pour isoler un test, puis retirez-le pour que la passerelle puisse négocier plus fort plus tard.

Vérifiez le démon et le port avant de réessayer

NetworkManager-l2tp démarre sa propre instance de xl2tpd. Si le service système possède déjà le port UDP 1701, le client se rabat sur un port source éphémère, ce que le RFC 3193 autorise et que certains serveurs écartent silencieusement. Vérifiez le propriétaire de la socket avant la prochaine tentative.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Les secrets générés obsolètes sont une autre cause silencieuse. Les fichiers sous /etc/ipsec.d/ nommés d’après une ancienne connexion peuvent survivre au profil qui les a créés ; supprimez donc ceux que rien ne référence et réessayez.

Enfin, vérifiez d’où vient le conseil. Un ipsec.conf écrit pour IKEv1 XAuth décrit un autre type de VPN, et sa proposition n’est pas la seule ligne qui sera fausse dans un profil L2TP. Notez le jeu de transformations saisi à côté du profil, pour que la personne suivante ne refasse pas la sonde.