L2TP/IPsec échoue lorsque le service IKEEXT est désactivé

Un portable atteint une passerelle IKEv2 mais échoue face à une passerelle L2TP/IPsec, et l'erreur arrive avant qu'un nom d'utilisateur soit envoyé. Le profil est généralement le premier suspect et généralement le mauvais. Windows exécute l'échange de clés IPsec dans un service, et tant que ce service est désactivé, le client intégré n'a pas de pile avec laquelle négocier. Vérifiez le service avant de toucher au moindre champ du profil, puis découvrez ce qui l'a désactivé.

Le service derrière la panne

IKE and AuthIP IPsec Keying Modules, affiché comme IKEEXT dans la liste des services, effectue l'échange de clés et détient les sockets UDP 500 et 4500 sous Windows. Désactivez-le et L2TP/IPsec comme IKEv2 perdent leur négociateur, tandis que PPTP et SSTP peuvent continuer de fonctionner car ils n'en dépendent pas. Cette répartition explique qu'un utilisateur signale qu'un type de VPN fonctionne et qu'un autre est mort sur la même machine. Le service fait partie du système d'exploitation, donc aucun réglage de profil ne peut le remplacer.

Libérer ces deux ports est l'effet secondaire qui produit les mauvais conseils. Un outil ou un message de forum remarque que 500 et 4500 sont occupés, arrête le service pour les libérer et retire ainsi silencieusement IPsec de l'hôte. Les deux effets sont une seule action, donc tout guide qui recommande de dégager les ports décrit un échange et non une réparation.

Rétablir le service sans deviner

Posez deux questions au gestionnaire de services : quel est le type de démarrage, et quel est l'état actuel. La première indique si le service reviendra après un redémarrage ; la seconde s'il tourne maintenant. Exécutez les deux requêtes depuis une invite élevée pour que le même shell puisse modifier le réglage ensuite.

sc qc ikeext
sc query ikeext

Un type de démarrage Disabled explique tout le symptôme, et la solution consiste à le remettre sur Automatic et à démarrer le service. Dans la console Services, l'entrée apparaît sous son nom d'affichage, IKE and AuthIP IPsec Keying Modules, donc chercher IKEEXT dans cette liste ne donne rien. Redémarrez si le service a été démarré après qu'une connexion échouée avait déjà été exécutée, car une pile initialisée dans cet ordre peut échouer de façons qui semblent sans rapport.

sc config ikeext start= auto
net start ikeext

Ce qui le désactive à nouveau

Certaines suites VPN tierces embarquent leur propre implémentation IPsec et désactivent IKEEXT pendant l'installation, après quoi le client Windows cesse de fonctionner. La suppression de l'autre produit a rétabli L2TP/IPsec sur des machines où les modifications de profil n'obtenaient rien, et sa réinstallation sans le composant conflictuel aussi. Le service a été désactivé à l'installation, et non basculé par l'utilisateur.

Les stratégies de groupe peuvent aussi figer le type de démarrage ; dans ce cas, une modification locale est annulée à la prochaine actualisation et l'administrateur propriétaire de la stratégie doit la changer. Notez le type de démarrage avant un redémarrage, après un redémarrage et après la mise à jour de l'autre produit, avec la date à chaque fois. Une valeur qui revient sans cesse sur Disabled trahit son propriétaire par le schéma, pas par conjecture.

Lisez l'étape, puis le journal

Une fois le service en marche, l'étape de la panne décide où regarder ensuite. Un blocage pendant IKE signifie généralement qu'UDP 500 ou 4500 n'a jamais atteint le serveur, ou que le serveur se trouve derrière NAT sans le réglage d'encapsulation correspondant. Atteindre l'invite d'identification et y échouer est un problème d'authentification PPP, pas d'IPsec. Un tunnel qui monte et n'atteint rien est une défaillance de routage ou de tunnel divisé, et seule la première de ces trois se trouve dans le profil VPN.

Les profils à certificat ajoutent une étape propre. Le client doit faire confiance à l'autorité émettrice et le certificat doit nommer le serveur validé ; si l'une des deux conditions échoue, la boîte de dialogue signale toujours une erreur de négociation initiale, c'est donc le journal d'événements qui révèle la vraie raison. Lisez l'entrée du journal avant de modifier le profil, car la boîte de dialogue comprime plusieurs défaillances distinctes en une seule phrase. Un certificat expiré produit la même boîte de dialogue qu'un service désactivé, et c'est pourquoi l'entrée du journal compte.

Notez l'étape qui échoue, le texte de l'erreur et l'horodatage pour chaque tentative. Ces trois champs séparent un problème de joignabilité d'un problème d'authentification et d'un problème de routage, et ils font du changement suivant une décision plutôt qu'une supposition.

Ce qu'une réparation locale ne peut pas prouver

Rétablir le service corrige la moitié du chemin qui se trouve sur le portable. Un service qui fonctionne ne prouve que la moitié locale : l'extrémité distante doit encore accepter la proposition choisie, les identifiants fournis et l'adresse source d'où arrive le paquet. Rien de ce qui est fait sur le portable ne compense un pare-feu qui rejette UDP 500 avant qu'il n'atteigne le pair. Un état de service correct est une condition préalable, pas la preuve que le tunnel montera.

Désactiver IKEEXT pour libérer les ports n'est défendable que si vous acceptez que les VPN IPsec de Windows cessent de fonctionner. Cela résout un conflit de ports en supprimant la fonction qui avait besoin du port, ce qui est rarement l'échange voulu par l'utilisateur. Avant de changer quoi que ce soit, confirmez que le service est présent, réglé sur Automatic et en cours d'exécution, qu'aucune seconde pile IPsec n'est installée et que la clé pré-partagée ou la chaîne de certificats correspond à la passerelle.

• IKEEXT est présent, réglé sur Automatic et en cours d'exécution avant que le client se connecte.
• Rien d'autre n'occupe UDP 500 ou 4500.
• Aucune seconde pile IPsec ne subsiste d'un ancien client.
• La clé ou la chaîne de certificats correspond à la configuration de la passerelle.
• L'étape qui a échoué a été notée avant la modification du profil.