L2TP: señal fatal 15, NO_PROPOSAL_CHOSEN y modp1024 ausente

La conexión se cuelga, el cliente sale y la última línea en pantalla es death_handler: Fatal signal 15 received. Esa línea informa de una interrupción, no de una causa. Una línea más arriba en el registro de IPsec casi siempre hay NO_PROPOSAL_CHOSEN, y el par apunta a la fase 2 del intercambio, donde los extremos comparan opciones de cifrado y de hash y se detienen cuando no comparten ninguna. En esa etapa aún no se han enviado las credenciales, así que volver a escribir la contraseña no puede cambiar el resultado.

Normalmente dos cosas vacían esa intersección en un cliente Linux. Puede que el demonio local ya no implemente el grupo Diffie-Hellman que pide el perfil, o que el perfil lleve una propuesta de fase 1 en un campo de fase 2. Ambas dejan rastro en el registro, y ninguna es un problema de cuenta.

Qué dicen en realidad los dos mensajes

IKE negocia por pasadas. La fase 1 construye un canal protegido y elige sus propios algoritmos; la fase 2, la SA hija, transporta tráfico con un conjunto aparte. NO_PROPOSAL_CHOSEN es la notificación que devuelve el respondedor cuando ninguna de las combinaciones ofrecidas es aceptable, y aparece como [ HASH N(NO_PROP) ] dentro de un intercambio INFORMATIONAL.

La señal 15 es otro suceso: algo dijo al proceso local que se detuviera y el gestor lo registró. Cuando ambas líneas aparecen juntas, el orden es causal: primero el rechazo y después el apagado.

Lea la negociación antes de tocar las credenciales

Sube el nivel de registro donde escribe el demonio y vuelve a conectar mientras observas la salida. En un equipo con NetworkManager el complemento L2TP pasa ese nivel al backend, y los mensajes acaban en el journal o en el archivo syslog clásico según la distribución. Cualquiera de estos dos mostrará el intercambio: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' o tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Una línea que nombra pluto viene de libreswan, charon de strongSwan, y las dos describen la misma condición con palabras distintas. La forma que merece la pena buscar es la que nombra el grupo que falta, como algorithm 'modp1024' is not supported, porque convierte un fallo vago en uno concreto.

Adónde fue modp1024

El grupo 2 de Diffie-Hellman es lo bastante débil como para que varias distribuciones dejaran de compilarlo dentro de libreswan a partir de la 3.30. Entonces un perfil escrito hace años, o copiado de una guía de pasarela que solo lista aes128-sha1-modp1024, pide al demonio local algo que no puede ejecutar en absoluto. Las compilaciones más recientes de NetworkManager-l2tp hacen ese desenlace más probable: desde la 1.2.16 sustituyen el conjunto por propuestas al estilo de Windows 10 e iOS y descartan modp1024 en cuanto detectan libreswan. El extremo remoto suele ser inocente y sigue ofreciendo exactamente el grupo que configuró.

Esa asimetría es lo que hace que el fallo parezca aleatorio. Un cliente antiguo se conecta, el mismo perfil en un portátil actualizado no, y la configuración del servidor nunca se movió. El daño lo hace la deriva de versiones.

Dos reparaciones con alcance distinto

La reparación barata es dejar de fijar los algoritmos a mano. Vacía los dos campos de propuestas del editor y deja que el complemento elija un conjunto que el extremo remoto acepte; si la pasarela admite grupos modernos, la negociación termina sin más trabajo.

La segunda reparación mantiene accesible una pasarela antigua instalando strongSwan, cuyos paquetes aún implementan el grupo 2 en la mayoría de las distribuciones. Eso es un cambio de demonio, así que tiene un coste: confirma si otros túneles del equipo dependen de la configuración de libreswan antes de quitarlo, y espera denegaciones de SELinux entre NetworkManager y el complemento strongSwan en Fedora. Esas denegaciones aparecen en el registro de auditoría y no en la traza de IKE, por eso un túnel puede parecer roto justo después de una instalación correcta. El orden que funciona es primero dnf install strongswan y después rpm -e libreswan.

Cadenas de propuestas que encajan, y las trampas que las rodean

Cuando los campos hay que rellenarlos a mano, la fase 1 y la fase 2 toman valores distintos. Una pareja que se sabe que funciona contra un extremo de estilo Meraki ofrece aes128-sha1-modp1024 en la fase 1 con 3des-sha1-modp1024 detrás, ambas cerradas con un signo de exclamación que hace estricto el conjunto, de modo que solo se envían esas propuestas.

Después la fase 2 se estrecha a aes128-sha1 y 3des-sha1 con el mismo marcador estricto y sin ningún sufijo Diffie-Hellman. Una línea de fase 2 que lleva -modp1024 es un valor de fase 1 en el campo equivocado, y el respondedor la rechaza en cada reintento. Copia esa línea en un segundo perfil y el segundo perfil falla igual, y así una errata se convierte en un incidente para toda la flota.

Otras fallas llevan el mismo cuadro emergente sin ser desajustes de propuestas. En KDE el tipo L2TP puede aparecer listado con el complemento instalado mientras cada conexión muere al instante, porque el editor de conexiones y los auxiliares de tiempo de ejecución se distribuyen como paquetes separados. Los equipos sin pantalla pueden reutilizar un perfil de un escritorio que funciona: cópielo desde /etc/NetworkManager/system-connections/, ponga el modo en 600 y luego ejecute nmcli con reload. Súbalo con nmcli con up id work-l2tp, ya que la forma desnuda pide un UUID, y elimine cualquier entrada ifname obsoleta, o el gestor responde Could not find source connection mientras todo lo demás es correcto.

Una clave precompartida puede guardarse como texto claro o como 0s seguido de base64; ambas formas funcionan, pero el valor debe coincidir con la pasarela byte a byte, incluidos los espacios finales que copió con ella.