L2TP/IPsec falla cuando el servicio IKEEXT está deshabilitado

Un portátil llega a una puerta de enlace IKEv2 pero falla contra una de L2TP/IPsec, y el error aparece antes de que se envíe ningún nombre de usuario. El perfil suele ser el primer sospechoso y casi siempre el equivocado. Windows ejecuta el intercambio de claves IPsec en un servicio, y mientras ese servicio está deshabilitado, el cliente integrado no tiene pila con la que negociar. Compruebe el servicio antes de tocar un solo campo del perfil y luego averigüe qué lo deshabilitó.

El servicio que hay detrás del fallo

IKE and AuthIP IPsec Keying Modules, que aparece como IKEEXT en la lista de servicios, realiza el intercambio de claves y mantiene los sockets UDP 500 y 4500 en Windows. Deshabilítelo y tanto L2TP/IPsec como IKEv2 pierden su negociador, mientras que PPTP y SSTP pueden seguir funcionando porque no dependen de él. Esa división explica que un usuario informe de que un tipo de VPN funciona y otro está muerto en la misma máquina. El servicio forma parte del sistema operativo, así que ninguna opción del perfil puede sustituirlo.

Liberar esos dos puertos es el efecto secundario que genera los malos consejos. Una herramienta o un mensaje de foro observa que 500 y 4500 están ocupados, detiene el servicio para liberarlos y con ello elimina IPsec del equipo sin avisar. Los dos efectos son una sola acción, así que cualquier guía que recomiende despejar los puertos describe un intercambio y no una reparación.

Devolver el servicio a su sitio sin adivinar

Haga dos preguntas al administrador de servicios: cuál es el tipo de inicio y cuál es el estado actual. La primera indica si el servicio volverá tras un reinicio; la segunda, si se está ejecutando ahora. Ejecute ambas consultas desde un símbolo del sistema elevado para que el mismo shell pueda cambiar la configuración después.

sc qc ikeext
sc query ikeext

Un tipo de inicio Disabled explica todo el síntoma, y la solución es volver a ponerlo en Automatic e iniciar el servicio. En la consola de Servicios la entrada aparece con su nombre para mostrar, IKE and AuthIP IPsec Keying Modules, así que buscar IKEEXT en esa lista no encuentra nada. Reinicie si el servicio se inició después de que ya se hubiera ejecutado una conexión fallida, porque una pila inicializada en ese orden puede fallar de formas que parecen no tener relación.

sc config ikeext start= auto
net start ikeext

Qué lo vuelve a apagar

Algunas suites de VPN de terceros incluyen su propia implementación de IPsec y deshabilitan IKEEXT durante la instalación, tras lo cual el cliente de Windows deja de funcionar. Quitar el otro producto ha restaurado L2TP/IPsec en máquinas donde las ediciones del perfil no lograban nada, y lo mismo ha hecho reinstalarlo sin el componente en conflicto. El servicio se deshabilitó al instalar, no lo cambió el usuario.

Las directivas de grupo también pueden fijar el tipo de inicio; en ese caso, un cambio local se revierte en la siguiente actualización y el administrador dueño de la directiva tiene que cambiarlo. Anote el tipo de inicio antes de un reinicio, después de un reinicio y después de que se actualice el otro producto, con la fecha cada vez. Un valor que vuelve una y otra vez a Disabled delata a su dueño por el patrón, no por conjeturas.

Lea la fase y luego el registro

Con el servicio en marcha, la fase del fallo decide dónde mirar después. Un bloqueo durante IKE suele significar que UDP 500 o 4500 nunca llegó al servidor, o que el servidor está detrás de NAT sin la configuración de encapsulación correspondiente. Llegar al aviso de credenciales y fallar allí es un problema de autenticación PPP, no de IPsec. Un túnel que se levanta y no alcanza nada es un fallo de enrutamiento o de túnel dividido, y solo el primero de esos tres vive en el perfil de la VPN.

Los perfiles con certificado añaden una fase propia. El cliente tiene que confiar en la autoridad emisora y el certificado tiene que nombrar al servidor que se valida; cuando falla cualquiera de las dos condiciones, el diálogo sigue informando de un error de negociación inicial, así que el registro de eventos es donde aparece el motivo real. Lea la entrada del registro antes de editar el perfil, porque el diálogo comprime varios fallos distintos en una sola frase. Un certificado caducado produce el mismo diálogo que un servicio deshabilitado, y por eso importa la entrada del registro.

Anote la fase que falla, el texto del error y la marca de tiempo de cada intento. Esos tres campos separan un problema de accesibilidad de uno de autenticación y de uno de enrutamiento, y convierten el siguiente cambio en una decisión en lugar de una conjetura.

Lo que una reparación local no puede demostrar

Restaurar el servicio arregla la mitad del camino que está en el portátil. Un servicio que funciona solo demuestra la mitad local: el extremo remoto todavía tiene que aceptar la propuesta elegida, las credenciales enviadas y la dirección de origen de la que llega el paquete. Nada de lo que se haga en el portátil compensa un cortafuegos que descarta UDP 500 antes de que llegue al par. Un estado de servicio correcto es una condición previa, no una prueba de que el túnel vaya a levantarse.

Deshabilitar IKEEXT para liberar los puertos solo es defendible si acepta que las VPN IPsec de Windows dejan de funcionar. Resuelve un conflicto de puertos eliminando la función que necesitaba el puerto, que rara vez es el intercambio que el usuario pretendía. Antes de cambiar nada, confirme que el servicio está presente, puesto en Automatic y en ejecución, que no hay una segunda pila IPsec instalada y que la clave precompartida o la cadena de certificados coincide con la puerta de enlace.

• IKEEXT está presente, puesto en Automatic y en ejecución antes de que el cliente se conecte.
• Nada más retiene UDP 500 ni 4500.
• No queda una segunda pila IPsec de un cliente antiguo.
• La clave o la cadena de certificados coincide con la configuración de la puerta de enlace.
• La fase que falló quedó registrada antes de editar el perfil.