L2TP/IPsec a través de NAT: qué se rompe de verdad y por qué

La afirmación de que NAT rompe L2TP/IPsec es medio cierta y por eso inútil. La traducción de direcciones es normal, el traversal NAT existe precisamente para sobrevivirla, y millones de clientes se conectan cada día desde detrás de un router. Lo que se rompe es una etapa concreta de un intercambio concreto: IKE nunca recibe respuesta, el túnel encapsulado se descarta por una política que solo permite un protocolo, o el mapeo de traducción caduca mientras el túnel está inactivo. Cuando sabe en qué etapa está, el arreglo suele ser una sola regla o un keepalive, no un diseño nuevo de VPN.

El mito es la pregunta equivocada

La pregunta útil no es si NAT rompe esto, sino qué parte del intercambio se traduce y qué hace con ella el dispositivo que traduce. L2TP/IPsec es un protocolo por capas: IKE negocia, ESP protege, y L2TP transporta PPP dentro de esa protección. La traducción de direcciones interactúa de forma distinta con cada capa, y las firmas de fallo se distinguen si mira la etapa de negociación en lugar del diálogo de error.

Un router que navega por la web con éxito solo demuestra que TCP con traducción de puerto de origen funciona. No dice nada sobre UDP 500, UDP 4500 ni el protocolo 50, y esas son las tres cosas de las que depende este despliegue.

Etapa 1: IKE tiene que recibir alguna respuesta

El primer intercambio va al respondedor por UDP 500. Si no vuelve ninguna respuesta, nada más importa: la clave precompartida, la propuesta y las credenciales quedan sin leer. Observe la petición y la respuesta en lugar de deducirlo del tiempo de espera del cliente:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Una petición sin respuesta normalmente significa que un cortafuegos o el operador aguas arriba descarta el paquete, no que el servidor lo haya rechazado. Una respuesta con una carga de notificación que nombra una propuesta o un problema de certificado significa que los paquetes llegaron y que la negociación falló por el contenido, lo cual es un arreglo completamente distinto.

Cuando ambos extremos están detrás de traducción, el iniciador solo tiene que alcanzar al respondedor, así que la mayoría de los despliegues del lado del cliente funcionan desde la etapa 1. El alojamiento del lado del servidor es donde empieza el problema de entrada, y por eso las dos situaciones nunca deben tratarse como una sola.

Etapa 2: la encapsulación cambia lo que ve el cortafuegos

ESP es un protocolo IP, no un puerto TCP o UDP, y la traducción de direcciones de puertos ordinaria no tiene ningún campo de puerto que reescribir. Por eso el traversal NAT mueve la carga protegida dentro de UDP 4500: la encapsulación da al dispositivo que traduce algo que sabe traducir. Cuando eso ocurre, una regla de cortafuegos escrita solo para UDP 500 permite la negociación y descarta el túnel, lo que produce el resultado confuso en el que el registro muestra una fase 1 correcta y ningún tráfico.

El propio intercambio IKE también puede pasar a UDP 4500 tras detectarse un NAT, lo que sorprende a quienes han permitido 500 y nada más. Permita ambos puertos en ambas direcciones en la ruta, y recuerde que un cortafuegos con estado solo puede mantener el flujo mientras ve tráfico.

El protocolo 50 sigue importando en rutas sin traducción, y en rutas donde un dispositivo intermedio está configurado para permitirlo. Si diagnostica por eliminación, desactive la hipótesis en lugar de añadir reglas en bloque: permita 500, 4500 y ESP, confirme que el túnel sube y luego elimine lo que resultó innecesario. Una regla que nadie puede explicar es una regla que nadie eliminará cuando se convierta en la causa de la próxima caída. Escriba el estrechamiento en el registro de cambios junto con la etapa que corrigió, para que el siguiente ingeniero empiece por sus pruebas y no por la misma regla general.

Etapa 3: el mapeo caduca y el túnel muere

Un dispositivo que traduce mantiene estado de los flujos que reenvía, y ese estado tiene una vida útil. Un túnel L2TP/IPsec transporta poco tráfico cuando nadie lo usa, así que un túnel inactivo puede sobrevivir a su mapeo y dejar de recibir tráfico de vuelta. El cliente sigue convencido de que está conectado, el servidor no ve nada, y el primer síntoma suele ser un tiempo de espera de una aplicación y no un error de VPN.

La detección de par muerto y los keepalives de NAT existen para esto, y ambos extremos deben estar dispuestos a enviarlos. Si su servidor está detrás de traducción, el requisito en Windows es un ajuste de registro documentado que hace que el servidor asuma encapsulación UDP para sus propios paquetes salientes; sin él, el respondedor envía ESP que el dispositivo que traduce no puede volver a mapear. Es un problema de configuración del servidor, no del cliente.

Un cambio de dirección WAN produce el mismo resultado desde otra dirección: el mapeo se reconstruye alrededor de una dirección nueva, y la antigua asociación de seguridad ahora apunta a una tupla que ya no existe. El comportamiento de reconexión pertenece a la implementación del cliente, y por eso «reconectar tras reiniciar el router» funciona en un cliente y en otro exige un conmutador manual.

Alojar detrás de un NAT de operador es un problema distinto

Si quiere alojar un servidor L2TP/IPsec en casa y alcanzarlo desde fuera, el requisito es accesibilidad de entrada no solicitada, y eso no es lo que ofrece el traversal NAT. Un NAT de operador delante de su router significa que no hay ningún puerto que pueda reenviar y que le haga accesible, porque la dirección pública es compartida y el mapeo es solo de salida.

Ninguna casilla de IPsec pass-through cambia eso, y ninguna cantidad de configuración del cliente lo compensa. Las respuestas admitidas son una dirección realmente accesible, un punto final alojado o una arquitectura en la que cada participante hace una conexión saliente. La especificación de encapsulación UDP resuelve el problema de traducción para los flujos que existen; no crea una ruta de entrada donde el operador no ofrece ninguna.

Así que compare redes en lugar de adivinar. Lleve el mismo dispositivo y perfil a otra red permitida y observe qué etapa falla allí. Si funciona en otro sitio, la diferencia está en la ruta, y eso reduce la búsqueda a las tres etapas anteriores en lugar de a toda la configuración.