L2TP NO_PROPOSAL_CHOSEN: ¿qué fase falló realmente?

NO_PROPOSAL_CHOSEN llega antes de que se examine cualquier nombre de usuario PPP, lo que es un dato útil y también la razón por la que el mensaje engaña. Informa de que un lado rechazó una propuesta; no informa de qué parámetro no coincidía y no dice nada sobre si el rechazo ocurrió al construir la asociación IKE o más tarde, al negociar la protección del tráfico. Detrás de esas dos posibilidades hay dos correcciones distintas, y solo una implica la casilla PFS a la que la gente acude primero.

Un mensaje, dos conjuntos de propuestas

La disposición IKEv1 L2TP/IPsec tiene dos negociaciones en secuencia. La fase 1 construye la asociación de seguridad IKE a partir de un algoritmo de cifrado, un algoritmo de integridad y un grupo Diffie-Hellman. La fase 2 negocia después cómo se protege el tráfico, y el requisito de PFS pertenece a esa segunda conversación.

Como las fases son secuenciales, la posición del fallo te dice qué lista comparar. Ese es todo el valor de diagnóstico del mensaje, y merece la pena extraerlo antes de tocar cualquier ajuste.

Por qué una casilla PFS no puede reparar la fase 1

Desactivar PFS cambia una propiedad de la fase 2. Si las partes nunca acordaron la fase 1, la conversación ESP nunca tiene lugar, así que la casilla no influye en absoluto en el rechazo, y por eso cambiarla produce el mismo error con una marca de tiempo distinta.

El error inverso es igual de común. Una asociación IKE correcta no demuestra que la propuesta ESP sea aceptable y desde luego no demuestra que el grupo de la fase 2 coincida. Trata un túnel de gestión establecido como evidencia solo sobre la fase 1. La gente lee la línea verde como «el túnel está activo» y luego pasa una hora en la fase equivocada porque nada les dijo que la segunda negociación no había comenzado.

Lee el registro antes de elegir algoritmos

Recoge los mensajes inmediatamente anteriores al rechazo del backend que realmente atiende la conexión y correlaciónalos con el mismo intento. Sin esa correlación estás leyendo el historial de otra conexión y sacando conclusiones de él.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

A partir de esas líneas, responde dos preguntas: si se estableció una asociación de fase 1 y qué intercambio falló. Esas dos respuestas reducen la búsqueda a una sola lista de atributos. Una notificación desnuda sin contexto alrededor no puede hacerlo, por tentador que sea probar una propuesta de un hilo de foro. Copiar una cadena que funciona de una máquina con otro backend suele sustituir un rechazo por otro, un poco más tarde.

La sintaxis del backend no viaja

Anota la versión de NetworkManager-l2tp y la versión del backend IPsec antes de comparar nada. Libreswan y strongSwan no comparten sintaxis de propuestas ni conjuntos de algoritmos idénticos, así que una cadena que funciona en uno es un error de sintaxis en el otro. El backend instalado también puede rechazar IKEv1 por política, y entonces ninguna propuesta será aceptada jamás.

El README del proyecto documenta esas diferencias entre backends y mantiene separados los campos de fase 1 y fase 2. Léelo como documentación de la estructura, no como una invitación a habilitar todos los cifrados históricos y un grupo débil, porque una conexión que solo tiene éxito haciendo eso no es la conexión que se te pidió construir.

Acordad el conjunto y luego verificad las etapas

Pregunta al operador de la puerta de enlace qué conjuntos IKE y ESP están soportados y aprobados, y luego compara esa respuesta con las propuestas efectivas del cliente en lugar de con su archivo de configuración. Si el desacuerdo es concretamente sobre PFS de fase 2, decídete por un grupo soportado o por una política sin PFS aprobada explícitamente. No infieras la política del nombre del error.

Cuando el único solapamiento exige criptografía que la organización ya no acepta, la decisión corresponde a la puerta de enlace o a una migración de protocolo. Ampliar la cadena del cliente hasta que algo negocie es una forma de entregar una debilidad conocida con una marca verde al lado.

Después de corregir la discrepancia real, confirma el establecimiento de IPsec antes de investigar L2TP y PPP, y trata cualquier rechazo de autenticación posterior como perteneciente a la etapa siguiente. Luego prueba la renovación en el proceso de pruebas aprobado, porque establecer la primera asociación no dice nada sobre el resto de su vida.