Por qué L2TP/IPsec necesita UDP 1701 además de IPsec

Los cortafuegos que permiten IKE y ESP pero no UDP 1701 rompen las conexiones L2TP de una forma que parece un problema de credenciales. La razón es que L2TP es un segundo protocolo que viaja dentro del primero. IPsec transporta y autentica el intercambio, y L2TP ejecuta su propio túnel sobre UDP 1701, que la pila local todavía tiene que entregar. Saber dónde aparece cada cabecera explica qué dispositivo necesita qué regla.

Dos protocolos, dos conjuntos de puertos

Una conexión L2TP/IPsec usa IKE en UDP 500, atravesamiento NAT en UDP 4500 donde hay traducción, y ESP como protocolo IP 50 donde no la hay. El propio L2TP es un protocolo de túnel en UDP 1701, y se ejecuta después de que IPsec haya autenticado al par. Las dos mitades fallan de forma distinta, y las líneas de registro que informan de ellas vienen de componentes diferentes. Un conjunto de reglas que solo cubre la primera mitad produce una conexión que negocia y luego muere en la etapa del túnel.

Los números de puerto describen extremos de transporte, y ESP no es un puerto en absoluto. Por eso una interfaz de cortafuegos que solo ofrece reglas TCP y UDP no puede expresar una política IPsec completa. El protocolo 50 debe permitirse como protocolo, y una regla que solo menciona UDP nunca coincidirá con él.

La envoltura explica el puerto

En el cable, una conexión L2TP/IPsec muestra normalmente IKE en 500 y ESP encapsulado en 4500. La cabecera UDP 1701 se sitúa dentro de la carga protegida, por lo que una captura en la interfaz exterior no la muestra. El equipo local todavía tiene que entregar ese datagrama al demonio L2TP, y la entrega ocurre tras el desencapsulado. Por eso la regla 1701 pertenece al cortafuegos del propio extremo, incluso cuando ningún dispositivo intermedio ve nunca el puerto.

El orden de procesamiento explica la mayor parte de la confusión. Si la pila aplica la política IPsec antes del filtro del equipo, el paquete L2TP desencapsulado se compara como UDP 1701; si el orden se invierte, los puertos exteriores son lo que ve el conjunto de reglas. Ambos comportamientos existen en la práctica, por eso el mismo conjunto de reglas parece funcionar en una plataforma y fallar en otra.

Comprueba la ruta en orden

Captura primero la interfaz exterior y confirma que IKE y ESP encapsulado se mueven en ambas direcciones. Después revisa los contadores del cortafuegos local para el tráfico desencapsulado. El orden importa, porque una captura que no muestra nada en absoluto significa que el problema está más arriba del equipo.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

La captura confirma la primera mitad del intercambio y muestra si el par responde. El listado de reglas muestra si existe una regla 1701 y dónde se sitúa respecto de cualquier política de descarte. El listado de sockets confirma que el demonio L2TP está enlazado y escuchando, lo que descarta un servicio que nunca se inició. Lee las tres cosas antes de cambiar una regla, porque un oyente ausente y un puerto filtrado producen quejas idénticas del usuario.

Lo que un escaneo de puertos no puede mostrar

Un escaneo externo de UDP 1701 contra un servidor bien configurado normalmente no informa de nada, y ese es el resultado esperado. El puerto no está expuesto a internet; solo se llega a él después de que IPsec haya autenticado al par. Tratar el resultado cerrado como una avería lleva a abrir un puerto que debería permanecer cerrado. El escaneo no puede ver dentro del túnel más de lo que puede ver el tráfico de la aplicación.

Prueba con un cliente real en su lugar, y lee la etapa a la que llega. Si la conexión negocia y luego se atasca, el sospechoso es el demonio L2TP o el filtro local; si nunca negocia, son los puertos exteriores. Esa única división elimina la mayor parte de las conjeturas sobre qué regla añadir, y el estratificado del protocolo lo hace predecible en lugar de misterioso.