Erreur L2TP/IPsec 789, 720 ou 691 : corrigez d’abord la bonne étape
Windows signale 789, 720 ou 691 selon l’étape L2TP/IPsec. Décidez s’il faut corriger la stratégie NAT, la pile d’adaptateur ou les identifiants avant de réinstaller.
Windows 11 signale un numéro différent pour chaque étape de L2TP/IPsec, et ce numéro désigne une étape plutôt qu’il ne note la panne. 789 échoue avant que la liaison PPP existe, 720 échoue pendant que la liaison se monte, et 691 échoue une fois la liaison montée et les identifiants rejetés. La décision utile n’est pas quelle correction est la plus populaire ; c’est quelle étape le code prouve que vous avez atteinte. Lisez cela d’abord, puis changez une couche par tentative afin que le code suivant vous dise encore quelque chose.
Lisez le code comme une étape, pas comme une liste de pannes
Une connexion L2TP traverse trois frontières dans un ordre fixe. IKE négocie les associations de sécurité sur UDP 500, la traversée NAT déplace ce trafic vers UDP 4500, et ce n’est qu’ensuite que le tunnel L2TP transporte une session PPP qui authentifie l’utilisateur et attribue une adresse.
Cet ordre explique pourquoi un code d’erreur changeant est une preuve utile. Passer de 789 à 720 signifie qu’IPsec négocie désormais et que la panne a migré vers l’établissement de la liaison. Passer de 720 à 691 signifie que la liaison s’est montée et que la passerelle a rejeté l’identité. Si vous appliquez cinq corrections à la fois, vous perdez ce signal et ne pouvez pas dire quel changement a fonctionné.
789 : choisir entre le chemin et la stratégie locale
Le code 789 est une erreur de traitement pendant les négociations de sécurité initiales. IPsec n’a jamais produit d’association utilisable, donc le compte n’a pas encore été testé. Commencez par le chemin et la clé partagée, pas par le compte.
Vérifiez que UDP 500 et UDP 4500 atteignent le serveur et que la clé prépartagée correspond octet pour octet, y compris la casse et les espaces de fin. Si le serveur se trouve derrière NAT, Windows peut aussi avoir besoin de la valeur de registre documentée. Utilisez 1 lorsque le serveur est derrière NAT et 2 lorsque les deux extrémités le sont, puis redémarrez, car l’agent de stratégie lit la valeur au démarrage :
reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f
La réparation plus lourde de l’adaptateur appartient à l’autre branche. Retirer le périphérique Wi-Fi et les miniports WAN, puis réanalyser le matériel, se justifie lorsque la pile IPsec locale elle-même est endommagée et que d’autres types de VPN échouent de la même façon. C’est un effort inutile lorsqu’un seul serveur L2TP échoue alors que tous les autres chemins réseau fonctionnent.
720 : choisir entre cet adaptateur et le pool de serveurs
L’erreur 720 indique que la connexion à l’ordinateur distant n’a pas pu être établie, et elle apparaît après la réussite d’IPsec. Le tunnel a atteint le point de monter une interface ou d’obtenir une adresse, puis s’est arrêté. Cela en fait une question d’adaptateur local ou de capacité du serveur.
Utilisez le rayon d’impact pour décider. L’échec d’une seule machine Windows pointe vers un miniport WAN défectueux, un service Remote Access arrêté ou un profil de connexion corrompu. L’échec de plusieurs clients en même temps pointe vers le serveur : un pool d’adresses épuisé, un service RRAS arrêté ou un pool qui ne correspond plus au sous-réseau des clients. Corrigez le côté que le schéma met en cause avant de changer l’autre.
Dans la branche à client unique, retirez les miniports WAN une fois et analysez les changements matériels, puis redémarrez et réessayez. Dans la branche serveur, vérifiez le pool et l’état du service plutôt que le client, car réinstaller un adaptateur qui fonctionne ne peut pas créer une adresse que le serveur n’a pas.
691 : choisir entre l’identifiant et un assistant arrêté
Le code 691 est un rejet d’authentification, et c’est le code le plus souvent mal interprété comme un mot de passe erroné. Le tunnel est monté, la passerelle a vu une identité et l’a rejetée. La cause peut encore se situer hors du champ du mot de passe.
Vérifiez d’abord le champ de domaine, puis les caractères exacts du mot de passe. Un mot de passe contenant un espace, un guillemet ou un caractère spécial du shell peut être altéré avant d’atteindre le serveur ; sous Linux, pppd signale le même rejet que E=691 pour une valeur sans guillemets ou un domaine manquant. Saisissez à nouveau le secret au lieu de le coller, et effacez tout identifiant enregistré qui pourrait contenir une valeur plus ancienne.
La branche que les gens manquent est un service d’assistance arrêté. Lorsqu’un client d’un fournisseur dépend de son propre service pour transmettre les identifiants à la passerelle, un service désactivé ou planté produit 691 même si le mot de passe est correct. Vérifiez l’état du service du fournisseur avant de réinitialiser le compte, surtout après un redémarrage ou une mise à jour.
Pour séparer les branches, testez le même nom d’utilisateur sur un autre profil VPN fonctionnel ou un compte de test RADIUS. Si cela réussit, l’identifiant est bon et le chemin client local est suspect. Si cela échoue de la même façon, le problème vient du compte ou de la stratégie de la passerelle.
Changez une couche par tentative
Travaillez de l’extérieur vers l’intérieur : accessibilité et traversée NAT, puis la clé prépartagée, puis la pile d’adaptateur locale, puis l’identifiant, puis le pool de serveurs et les services. Cet ordre suit les étapes que les codes décrivent et garde chaque résultat attribuable à un seul changement.
Tenez un journal court du code avant et après chaque tentative, de la version du client et de ce qui a été modifié, du serveur ou du client. Une séquence comme 789, puis 720, puis 691 est une carte des progrès ; le même code deux fois signifie que le dernier changement n’a pas traité cette étape. Réinstaller Windows efface cette carte et corrige rarement une panne qui vit sur la passerelle.
Quand le code cesse de changer, cessez de changer les choses. Relevez le code actuel, l’adresse du serveur, la méthode d’authentification et l’heure de la tentative, puis comparez ce relevé à un client qui fonctionne. La différence entre les deux relevés est généralement plus petite que la liste des corrections que les gens essaient par défaut.