L2TP/IPsec conecta en una red y se queda sin respuesta en otra

El mismo portátil, el mismo perfil y la misma contraseña funcionan en un edificio y fallan en otro. Esa comparación es la prueba más útil del caso, y suele ser lo primero que se descarta. Entre dos redes de acceso, el intercambio pasa por una traducción de direcciones distinta, filtros distintos y ayudantes de router distintos. Mantener fijo el cliente y cambiar solo la red es la forma de averiguar cuál de esas cosas importa.

Fije el cliente antes de comparar redes

No cambie nada en el dispositivo hasta tener un registro del caso que funciona: versión del cliente, contenido del perfil, nombre del servidor y hora de la conexión correcta. Después reproduzca el fallo en la segunda red durante la misma sesión, para que el estado del cliente sea lo más parecido posible. Un perfil editado entre los dos intentos invalida toda la comparación. El objetivo es una sola variable, y esa variable es la red.

Confirme primero el acceso normal a internet en la red que falla, incluido un portal de invitados si lo hay. Un portal que nunca se completó produce un tiempo de espera agotado que se parece exactamente a un túnel filtrado, y esa comprobación lleva un minuto.

Cuatro etapas, cuatro mensajes de error distintos

Una conexión L2TP/IPsec atraviesa cuatro etapas, y RFC 3193 describe la disposición que une las dos primeras. La negociación IKE es donde una ruta filtrada produce un tiempo de espera agotado silencioso. La autenticación IPsec es donde un desajuste de certificado o de clave precompartida produce en cambio un rechazo explícito. El montaje del túnel L2TP es donde una asociación de seguridad ya establecida puede no llevar a ninguna parte, y el inicio de sesión PPP es donde una credencial errónea produce por fin un fallo visible. Lea el registro de la etapa que se detuvo, no de la última línea que imprimió.

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

El registro de strongSwan muestra si el intercambio IKE llegó a una propuesta y si el par respondió siquiera, lo que separa la alcanzabilidad de la política. El registro de xl2tpd retoma donde termina IPsec, así que una asociación de seguridad establecida sin nada en ese registro apunta a la etapa L2TP. La consulta de ruta confirma que el cliente envía hacia la dirección de servidor que usted cree, lo que detecta una respuesta DNS obsoleta heredada de la red anterior. Juntas, las tres salidas nombran una etapa en lugar de un síntoma.

Compare la profundidad de NAT y el comportamiento del ayudante

La travesía de NAT traslada el tráfico protegido a la encapsulación UDP cuando se detecta traducción, de modo que los números de puerto que llevan una sesión funcional pueden diferir de los de un diagrama estático. Permitir un solo paquete de configuración no demuestra nada sobre el resto del intercambio, y un escaneo externo de puertos no puede decirle cómo trata el par el tráfico autenticado válido. Una segunda capa de traducción cambia de nuevo el panorama, porque la asignación existe ahora dos veces y caduca según dos calendarios distintos. La traducción de nivel de operador en una conexión móvil es la razón habitual de que un perfil de oficina que funciona falle en un punto de acceso del teléfono.

Los ayudantes del router varían tanto como las redes. Algunos firmwares interceptan y reescriben el intercambio, otros solo dejan de descartarlo, y otros aplican el ajuste únicamente en un modo heredado. Lea la descripción que da el propio firmware de la casilla, y donde exista un modo de compatibilidad, pruébelo como un cambio deliberado en lugar de tres a la vez.

Cliente saliente, servidor entrante: dos problemas distintos

Un cliente saliente y un servidor entrante necesitan distinta alcanzabilidad de subida, y una función de paso que ayuda al primero no hace nada por el segundo. Un router doméstico que deja al portátil llegar a una puerta de enlace remota no acepta por ello conexiones entrantes hacia un servidor detrás de él. Confundir ambos le manda a buscar un reenvío de puertos que nunca fue el problema. Indique qué papel desempeña el dispositivo que falla antes de comparar nada.

Tras un cambio admitido, repita la misma conexión y anote la etapa a la que llegó. Guarde juntos el perfil funcional y la nota sobre la red que falla, y no restablezca las credenciales ni reinstale el cliente, porque eso descarta la prueba sobre la que se construyó la comparación.