IPsec NAT-T: por qué la VPN no se establece detrás de NAT y cómo solucionarlo

diciembre 3, 2025 • febrero 3, 2026 • Lectura: 27 min • Views: 9

¿Te fue útil?

No hay nada que te haga cuestionar tus decisiones profesionales como una VPN IPsec “simple” que funciona desde una red y muere en cuanto mueves el cliente detrás de un router doméstico, una Wi‑Fi de hotel o una granja de NAT corporativa. Los logs dicen que el túnel está “arriba”. Los usuarios dicen que la aplicación está “caída”. Tu firewall dice que “lo permite todo”. Y, sin embargo: no hay tráfico.

IPsec detrás de NAT falla de unas pocas maneras repetibles. El truco es dejar de adivinar cuál tienes. NAT‑Traversal (NAT‑T) debería hacerlo aburrido. Cuando no lo es, la falla suele ser ruidosa—solo que no en el lugar donde estás mirando.

Qué le hace realmente el NAT a IPsec (y por qué es incómodo)

Aclararemos el vocabulario, porque las fallas de IPsec a menudo son fallas de vocabulario con pasos extra.

IKE es plano de control; ESP es plano de datos

En el mundo moderno normalmente estás tratando con IKEv2. Este negocia claves y parámetros sobre UDP puerto 500. Una vez que los pares acuerdan, el tráfico cifrado real fluye vía:

ESP (Encapsulating Security Payload): protocolo IP 50 (no TCP/UDP). Este es el modo clásico, hostil a NAT.
ESP encapsulado por NAT‑T: ESP envuelto dentro de UDP/4500. Así sobrevive IPsec al NAT.

Así que necesitas dos cosas para tener éxito: IKE tiene que completarse, y el plano de datos tiene que transportar tráfico. Puedes tener IKE “arriba” con una ruta de datos muerta. Eso no es una paradoja. Eso es un martes.

Por qué NAT rompe el ESP “nativo”

Los dispositivos NAT reescriben direcciones IP (y muchas veces puertos). ESP no tiene puertos. Muchos equipos NAT no pueden mantener estado estable para un protocolo que no les da un 5‑tupla (IP origen, IP destino, puerto origen, puerto destino, protocolo). Algunos pueden hacer “ESP passthrough”, que es un término de marketing que significa “lo intentamos”.

Peor aún: la integridad de IPsec cubre partes del paquete que al NAT le gusta reescribir. Así que si usas AH (Authentication Header, protocolo 51), la reescritura del NAT invalida la comprobación de integridad. AH y NAT son básicamente incompatibles por diseño. ESP puede sobrevivir al NAT si el dispositivo NAT lo rastrea y no toca los campos protegidos, pero eso no es algo en lo que debas apostar en producción.

El truco central de NAT‑T

NAT‑T cambia el transporte exterior a UDP, para que los dispositivos NAT puedan rastrear un flujo mapeado por puerto. Tras la detección de NAT, ambos pares suelen cambiar a UDP/4500. La carga útil cifrada (ESP) se convierte en una carga UDP. El dispositivo NAT se pone contento porque ahora puede hacer lo que hace todo el día: mantener estado UDP.

Pero NAT‑T añade sobrecarga. Eso importa para MTU y fragmentación. Y depende de timeouts de estado NAT y keepalives. Eso importa para “se conecta y luego muere tras 30 segundos”.

Una idea parafraseada, a menudo atribuida a Werner Vogels, encaja con el trabajo de fiabilidad: Todo falla; diseña para que falle de forma predecible y se recupere automáticamente. Los problemas de NAT‑T son predecibles una vez que conoces el puñado de trampas.

Las tres arquitecturas más comunes “detrás de NAT”

Road warrior: portátil/teléfono detrás de NAT de consumo hacia una pasarela VPN. Normalmente lo más fácil—si se permiten UDP/500 y UDP/4500.
Sitio a sitio con un lado NATeado: sucursal detrás del router ISP que hace NAT. Funciona, pero debes planear la IP pública dinámica y los mapeos NAT.
Double NAT / CGNAT: estás detrás de dos NATs (router doméstico + NAT de operador). NAT‑T puede funcionar, pero entras en el territorio de timeouts agresivos, reescritura de puertos y “por favor déjenme usar WireGuard”.

NAT-T en la práctica: puertos, encapsulación y estado

Detección de NAT y el cambio a UDP/4500

IKEv2 hace la detección de NAT mediante hashing de tuplas IP/puerto y comparando lo que cada lado piensa que son las direcciones/puertos exteriores. Si los hashes no coinciden, existe NAT en algún lugar del camino. Entonces los pares típicamente acuerdan usar encapsulación UDP en el puerto 4500.

Si ves mensajes IKE en UDP/500 pero nunca ves UDP/4500, o bien no se detectó NAT (raro), NAT‑T no está habilitado/negociado (configuración errónea común), o un firewall bloquea UDP/4500 (muy común).

Keepalives: porque el estado UDP se evapora

Los dispositivos NAT agotan rápidamente los mapeos UDP—a veces en 30 segundos, a veces en unos minutos. NAT‑T usa keepalives periódicos (a menudo alrededor de 20 segundos) para mantener ese mapeo vivo. Si los keepalives están deshabilitados o bloqueados, el túnel se levanta, el tráfico pasa brevemente y luego muere hasta un rekey o reconexión.

Broma corta #1: NAT es como un pez dorado: olvida que tu flujo UDP existe en el momento en que dejas de agitar paquetes frente a él.

MTU, fragmentación y por qué “funciona con ping” es irrelevante

NAT‑T añade sobrecarga: cabecera IP exterior + cabecera UDP + marcador non-ESP + sobrecarga ESP. Si no lo tienes en cuenta, obtienes problemas de MTU de ruta. El túnel “funciona” con paquetes pequeños (pings, banners SSH), pero los paquetes grandes caen en un agujero negro. Verás sesiones TCP atascadas, retransmisiones, o “el sitio web carga pero las descargas fallan”.

PMTUD a menudo falla a través de IPsec + NAT porque los mensajes ICMP “Fragmentation Needed” están bloqueados o no se mapean correctamente de vuelta. Así que puede que tengas que fijar MSS o establecer un MTU más bajo explícitamente.

NAT‑T con múltiples clientes detrás del mismo NAT

Múltiples clientes detrás de un NAT conectando al mismo gateway es normal. El dispositivo NAT usa diferentes puertos origen para cada flujo UDP/4500 del cliente. Si la pasarela VPN o los middleboxes asumen “un par por IP pública”, obtienes túneles inestables, selección de SA equivocada, o un usuario roba la sesión de otro. Esto casi siempre es una búsqueda de políticas rota o una expectativa de ID de par demasiado estricta.

Selección de políticas IPsec y “rightid/leftid”

Cuando hay NAT, las direcciones IP son identificadores menos estables. Usa identidades IKE (FQDN, IDs tipo email, subjectAltName de certificados) en lugar de “el par debe venir de X IP pública”. ¿Sitio a sitio detrás de IP dinámica? Usa coincidencia de identidad agresiva pero controlada, y constriñe con certificados/PSK además de propuestas más restrictivas.

Guía rápida de diagnóstico (primero/segundo/tercero)

Este es el orden que realmente ahorra tiempo en producción. No empieces leyendo cada línea de log desde 2019.

Primero: prueba que existen paquetes (UDP/500 y UDP/4500) en ambos extremos

Captura en el lado cliente: ¿envías UDP/500? ¿Luego envías UDP/4500?
Captura en la interfaz WAN del gateway: ¿los recibes?
Si ves UDP/500 pero no UDP/4500 después de la detección de NAT, asume que UDP/4500 está bloqueado hasta probar lo contrario.

Segundo: confirma qué estado cree tener cada par (IKE SA vs CHILD SA)

¿IKE SA está establecido pero no hay CHILD SA? Eso suele ser incompatibilidad de propuestas o desajuste de política/selección de tráfico.
¿CHILD SA instalado pero no pasa tráfico? Eso suele ser enrutamiento, firewall, o MTU/fragmentación.
¿Pasa tráfico durante 30–120 segundos y luego se detiene? Eso suele ser timeout de mapeo NAT / keepalives.

Tercero: revisa MTU/MSS y enrutamiento asimétrico

Ejecuta un ping con DF (o tracepath) a través del túnel y encuentra el MTU usable real.
Trunca el MSS de TCP en la interfaz del túnel o en el gateway si es necesario.
Verifica el camino de retorno: IPsec es alérgico al enrutamiento asimétrico cuando hay firewalls stateful involucrados.

Si haces esos tres pasos, solucionas gran parte de los incidentes “detrás de NAT” sin una sala de crisis.

Hechos interesantes y breve historia (lo que explica el desorden actual)

IPsec se diseñó con optimismo para IPv6. La mentalidad original asumía que el direccionamiento de extremo a extremo sería común; NAT no era la estrella del espectáculo.
AH (protocolo IP 51) básicamente no puede sobrevivir al NAT. NAT modifica cabeceras que AH autentica. ESP es la opción práctica en entornos NATeados.
NAT‑T se estandarizó porque el “ESP passthrough” no era fiable. Los vendedores enviaron hacks; la interoperabilidad fue… aspiracional.
UDP/4500 es la convención para NAT‑T. Ahora los firewalls lo reconocen ampliamente como “el puerto IPsec NAT‑T”, lo que es útil y también un fingerprint.
NAT‑T usa un marcador non‑ESP. En paquetes ESP encapsulados por UDP, un marcador de 4 bytes a cero diferencia el tráfico IKE del payload ESP‑in‑UDP.
Los borradores tempranos de NAT‑T compitieron. Existieron implementaciones distintas antes de la estandarización; equipos legacy a veces muestran comportamientos extraños.
Los timeouts NAT de UDP varían enormemente. Routers de consumo, firewalls empresariales y cajas CGNAT eligen distintos valores por defecto; tus ajustes de keepalive deben cubrir el peor caso.
Las redes móviles son hostiles por defecto. Algunos operadores y hotspots limitan o remodelan flujos UDP; IPsec sobre NAT‑T puede parecer “UDP aleatorio” para ellos.
IKEv2 mejoró la resiliencia. En comparación con IKEv1, la máquina de estados de IKEv2 y el soporte MOBIKE manejan mejor cambios de dirección—cuando están habilitados y soportados.

Tareas prácticas: comandos, salida esperada y decisiones

A continuación hay tareas prácticas que puedes ejecutar en clientes/gateways basados en Linux. Los comandos son realistas; adapta nombres de interfaces e IPs. Cada tarea incluye: comando, qué significa la salida y la decisión que tomas.

Tarea 1: Confirma que hay un NAT en el camino (lado cliente)

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
wlan0            UP             192.168.1.50/24 fe80::a00:27ff:fe4e:66a1/64

Significado: Tu cliente tiene una dirección privada RFC1918 (192.168.1.50). Estás detrás de NAT.

Decisión: Asume que NAT‑T es necesario a menos que la VPN use un protocolo UDP puro. Para IPsec, necesitarás alcance a UDP/4500.

Tarea 2: Comprueba la ruta por defecto e interfaz de salida (lado cliente)

cr0x@server:~$ ip route show default
default via 192.168.1.1 dev wlan0 proto dhcp metric 600

Significado: El tráfico sale vía 192.168.1.1 por wlan0. Ese es tu gateway NAT.

Decisión: Si la VPN falla solo en esta red, sospecha de este dispositivo NAT o de su política upstream.

Tarea 3: Verifica que UDP/500 y UDP/4500 no estén bloqueados localmente (firewall del cliente)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy accept;
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Significado: El firewall local es permisivo (policy accept). Si el tuyo es “drop”, busca permisos explícitos.

Decisión: Si ves drops para UDP/500 o UDP/4500, arréglalo localmente antes de culpar a la red.

Tarea 4: Prueba que el cliente envía paquetes IKE (tcpdump)

cr0x@server:~$ sudo tcpdump -ni wlan0 udp port 500 or udp port 4500
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:41.102345 IP 192.168.1.50.55612 > 203.0.113.10.500: isakmp: parent_sa ikev2_init[I]
12:10:41.256789 IP 203.0.113.10.500 > 192.168.1.50.55612: isakmp: parent_sa ikev2_init[R]

Significado: IKEv2 INIT está ocurriendo en UDP/500. Así que la alcanzabilidad básica existe.

Decisión: Pasa a ver si NAT‑T (UDP/4500) empieza tras la detección de NAT.

Tarea 5: Confirma que el cambio a NAT‑T (UDP/4500) realmente ocurre

cr0x@server:~$ sudo tcpdump -ni wlan0 udp port 4500
listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:42.001122 IP 192.168.1.50.4500 > 203.0.113.10.4500: UDP-encap: NONESP-encap: isakmp: parent_sa ikev2_auth[I]
12:10:42.140055 IP 203.0.113.10.4500 > 192.168.1.50.4500: UDP-encap: NONESP-encap: isakmp: parent_sa ikev2_auth[R]
12:10:43.000211 IP 192.168.1.50.4500 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1a2b3c4,seq=0x1)

Significado: Tienes NAT‑T (UDP/4500) y ves paquetes ESP‑in‑UDP. Esa es la forma correcta.

Decisión: Si faltan paquetes UDP/4500, arregla firewall/ACL/reglas NAT en el camino. Si están presentes pero no funciona tráfico, mira CHILD SA y enrutamiento/MTU.

Tarea 6: Si nunca ves UDP/4500, prueba si la red lo bloquea

cr0x@server:~$ sudo nmap -sU -p 4500 203.0.113.10
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-28 12:12 UTC
Nmap scan report for 203.0.113.10
Host is up.
PORT     STATE         SERVICE
4500/udp open|filtered nat-t-ike

Significado: Los escaneos UDP no distinguen de forma fiable “open” de “filtered”. Pero si devuelve “closed”, tienes una señal fuerte de que algo lo rechaza.

Decisión: Si el entorno es sospechoso (hotel/café), prueba otra red o mueve IPsec a un transporte más permisivo (o usa IKEv2 sobre TCP si está soportado, pero eso es específico del proveedor y no siempre es sensato).

Tarea 7: En el gateway VPN, confirma que los paquetes llegan en WAN

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 500 or udp port 4500
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:41.103111 IP 198.51.100.25.55612 > 203.0.113.10.500: isakmp: parent_sa ikev2_init[I]
12:10:42.001901 IP 198.51.100.25.4500 > 203.0.113.10.4500: UDP-encap: NONESP-encap: isakmp: parent_sa ikev2_auth[I]

Significado: El gateway ve al cliente como 198.51.100.25 (la IP pública del NAT), no como la privada 192.168.1.50. Eso es esperado.

Decisión: Si el gateway ve UDP/500 pero no UDP/4500, el bloqueo está entre cliente y gateway (a menudo el dispositivo NAT, firewall upstream o ISP).

Tarea 8: Comprueba estado IKE/CHILD SA en un gateway strongSwan

cr0x@server:~$ sudo swanctl --list-sas
ikev2-vpn: #12, ESTABLISHED, IKEv2, 3c4d5e6f7a8b9c0d_i* 9f8e7d6c5b4a3210_r
  local  'vpn-gw.example' @ 203.0.113.10[4500]
  remote 'roadwarrior' @ 198.51.100.25[4500]
  AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256
  established 62s ago, rekeying in 51m
  ike CHILD_SA: net-traffic{24} ESTABLISHED
    local  10.10.0.0/16
    remote 10.50.20.0/24
    AES_GCM_16-256/ECP_256, 12345678_i 9abcdef0_o, rekeying in 47m
    bytes_i 10492, bytes_o 8891, packets_i 120, packets_o 97

Significado: IKE SA está establecido y existe un CHILD SA. Los contadores aumentan. El plano de datos se mueve.

Decisión: Si falta CHILD SA o está atascado en “INSTALLING”, soluciona propuestas, PSK/certs y selectores de tráfico. Si los contadores se quedan en cero, revisa enrutamiento/firewall/MTU.

Tarea 9: Detecta “túnel arriba, sin tráfico” vía xfrm state/policy (gateway Linux)

cr0x@server:~$ sudo ip xfrm state | sed -n '1,60p'
src 203.0.113.10 dst 198.51.100.25
	proto esp spi 0x12345678 reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 128
src 198.51.100.25 dst 203.0.113.10
	proto esp spi 0x9abcdef0 reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0xbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 128

Significado: Existen SAs en el kernel. Si faltan, la negociación no los instaló.

Decisión: Si existe estado pero la política no coincide con tus subredes, tienes un desajuste de selectores. Si ambos existen, pasa a comprobaciones de enrutamiento y MTU.

Tarea 10: Verifica keepalives NAT‑T observando paquetes pequeños periódicos

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 4500 and host 198.51.100.25
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:15:00.000100 IP 198.51.100.25.4500 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1a2b3c4,seq=0x35)
12:15:20.002210 IP 198.51.100.25.4500 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1a2b3c4,seq=0x36)

Significado: El tráfico continúa. Si ves una ráfaga, luego silencio y después una reconexión, eso huele a timeout de estado UDP.

Decisión: Habilita/ajusta keepalives NAT (cliente y/o gateway) y acorta intervalos DPD/keepalive para sobrevivir NATs agresivos.

Tarea 11: Encuentra el MTU efectivo del camino con tracepath

cr0x@server:~$ tracepath -n 10.10.1.10
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.50.20.1                                            2.145ms
 2:  10.10.1.10                                            5.621ms reached
     Resume: pmtu 1380 hops 2 back 2

Significado: El MTU de ruta parece ser 1380. Eso es menor que Ethernet 1500 debido a la sobrecarga de encapsulación y posiblemente una restricción upstream.

Decisión: Ajusta el MTU de la interfaz/túnel alrededor de 1380 (o un poco menos) y/o trunca MSS TCP. Si PMTUD es inestable, sé conservador.

Tarea 12: Confirma síntomas de PMTUD/fragmentación con ping DF

cr0x@server:~$ ping -M do -s 1400 10.10.1.10 -c 3
PING 10.10.1.10 (10.10.1.10) 1400(1428) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- 10.10.1.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Significado: Tu MTU de interfaz local es 1500 pero el MTU efectivo del túnel es menor. El paquete DF no puede enviarse tal cual.

Decisión: Reduce MTU en la interfaz VPN y/o trunca MSS TCP (comúnmente a ~1360–1380 según la encapsulación).

Tarea 13: Truncar MSS TCP con nftables (gateway)

cr0x@server:~$ sudo nft add table inet mangle
cr0x@server:~$ sudo nft add chain inet mangle forward '{ type filter hook forward priority -150; }'
cr0x@server:~$ sudo nft add rule inet mangle forward tcp flags syn tcp option maxseg size set 1360
cr0x@server:~$ sudo nft list table inet mangle
table inet mangle {
	chain forward {
		type filter hook forward priority -150; policy accept;
		tcp flags syn tcp option maxseg size set 1360
	}
}

Significado: Las nuevas conexiones TCP que atraviesan el gateway tienen MSS truncado a 1360.

Decisión: Si el blackholing de MTU es tu problema, esto suele arreglar “algunos sitios funcionan, otros se estancan” sin tocar cada cliente.

Tarea 14: Verifica que el firewall permita UDP/500 y UDP/4500 en el gateway

cr0x@server:~$ sudo nft list ruleset | grep -E 'udp dport (500|4500)'
udp dport 500 accept
udp dport 4500 accept

Significado: El firewall del gateway está permitiendo IKE y NAT‑T.

Decisión: Si faltan estas reglas (o están después de un drop), añádelas. Si existen, el bloqueo está upstream o en el cliente.

Tarea 15: Comprueba el estado conntrack para UDP/4500 (dispositivo NAT / gateway que hace NAT)

cr0x@server:~$ sudo conntrack -L -p udp --dport 4500 | head
udp      17 28 src=192.168.1.50 dst=203.0.113.10 sport=4500 dport=4500 src=203.0.113.10 dst=198.51.100.25 sport=4500 dport=4500 [ASSURED] mark=0 use=1

Significado: Hay un mapeo NAT/conntrack con 28 segundos restantes (ejemplo). Si baja a cero y desaparece rápido, tu timeout es demasiado agresivo.

Decisión: Aumenta el timeout UDP si controlas el NAT, o reduce el intervalo de keepalive si no lo controlas.

Tarea 16: Confirma que la subred VPN está realmente enrutada al túnel

cr0x@server:~$ ip route get 10.10.1.10
10.10.1.10 dev vti0 src 10.50.20.2 uid 0
    cache

Significado: El kernel enviará tráfico a 10.10.1.10 vía vti0. Bien.

Decisión: Si se enruta por WAN en su lugar, tienes un problema de enrutamiento/policy routing, no de IPsec.

Tres micro-historias corporativas desde las trincheras NAT‑T

Micro-historia #1: El incidente provocado por una suposición equivocada

La configuración parecía rutinaria: un socio necesitaba un túnel IPsec sitio‑a‑sitio hacia un entorno de staging. El ingeniero del socio proporcionó una única “IP de par” y sus subredes internas. Permitimos UDP/500 y UDP/4500 desde esa IP de par. El túnel se levantó en el laboratorio. Todos declararon victoria.

Dos días después, staging quedó en silencio—solo para ese socio. Nuestros paneles mostraban el IKE SA establecido, luego fluctuando cada pocos minutos. La captura de paquetes en nuestra pasarela mostró paquetes IKE provenientes de una IP pública diferente a la que habíamos permitido. El equipo de seguridad insistió en que estábamos bajo ataque porque “la IP del par cambió”.

La suposición equivocada fue simple: que el socio tenía una IP pública estable. No la tenían. Estaban detrás de un pool NAT upstream y la IP de salida cambiaba según la carga, no con el tiempo. Su “IP de par” era la dirección que su UI de firewall mostraba, no lo que Internet veía los martes.

La solución fue igualmente simple y políticamente complicada: dejamos de ligar el túnel a una sola IP origen y en su lugar lo ligamos a la identidad del certificado, propuestas estrictas y selectores de tráfico acotados. Seguimos restringiendo IPs origen, pero a un pequeño rango del proveedor aprobado por control de cambios. El túnel dejó de fluctuar. El incidente terminó. Todos fingieron que así había sido el plan desde el principio.

Lección: si haces coincidencia solo por IP pública, apuestas la fiabilidad a la arquitectura NAT de otro. Eso no es “seguridad”. Es ruleta con papeleo.

Micro-historia #2: La optimización que salió mal

Un equipo de red interno quería conmutación por error más rápida para usuarios remotos. Su lógica: reducir el ruido de keepalive/DPD para ahorrar ancho de banda y CPU, porque “el túnel está mayormente inactivo”. Alargaron intervalos de keepalive NAT y aumentaron timeouts DPD. En el papel, menos paquetes, menos interrupciones, firewalls más felices.

El primer día todo parecía bien. Luego llegaron tickets: “La VPN se conecta pero se cae cuando dejo de escribir”. Podías poner un reloj: alrededor de un minuto de inactividad y el túnel se convertía en zombi. La UI del cliente seguía mostrando “conectado”, pero el tráfico no iba a ninguna parte. Reconectar lo arreglaba—hasta la siguiente pausa para el café.

Capturamos tráfico en el gateway. El mapeo NAT upstream expiraba a 30 segundos para UDP. El keepalive se había estirado más allá de eso. Así que el mapeo murió silenciosamente, y el siguiente paquete real fue descartado porque el NAT había olvidado dónde enviarlo. Cuando el cliente retransmitía o rekeyeaba, creaba un nuevo mapeo. Los usuarios lo percibieron como caídas aleatorias.

Revertimos la “optimización”, fijamos keepalives a un valor probado contra el peor NAT que pudimos encontrar y documentamos eso como un parámetro SLA no negociable. También enseñamos al equipo una verdad dura: el ancho de banda ahorrado desactivando keepalives a menudo se paga con creces en dolor de usuarios.

Micro-historia #3: La práctica aburrida pero correcta que salvó el día

Otra organización, diferente ambiente: altamente regulada, control de cambios y alérgica a la resolución heroica. Su estándar IPsec requería dos cosas que parecían exageradas hasta que no lo eran: puntos obligatorios de captura de paquetes y un “forma de paquete esperada” por túnel documentada (UDP/500 primero, luego UDP/4500, luego ESP‑in‑UDP).

Durante una migración de ISP, un subconjunto de sitios remotos dejó de pasar tráfico. Las páginas de estado de túnel lucían verdes. Los propietarios de aplicaciones escalaron inmediatamente, porque por supuesto lo hicieron.

El SRE de guardia siguió el runbook y realizó los pasos aburridos. Captura en WAN: UDP/500 y UDP/4500 llegaron. Captura en la interfaz interna: no había tráfico desencriptado. Eso lo acotó a selección de políticas, no a alcanzabilidad. Compararon los selectores instalados con el estándar y hallaron que la migración del ISP cambió el comportamiento NAT de la sucursal—los puertos de origen se reescribían más agresivamente y el firewall de la sucursal estaba haciendo match de pares por IP pública y combinación de puerto. Eso se rompió cuando el NAT eligió otro puerto.

La solución fue un cambio de configuración que ya tenían aprobado: coincidencia de pares por identidad, no por 5‑tupla. Lo aplicaron, verificaron que los contadores aumentaban y cerraron el incidente. Sin drama. Sin llamadas a medianoche con proveedores. Solo la satisfacción sosa de un runbook que funciona.

Errores comunes: síntoma → causa raíz → solución

Esta sección es intencionalmente específica. Si no puedes mapear tu síntoma a una causa raíz, no estás diagnosticando—estás coleccionando sentimientos.

1) Síntoma: IKE SA se establece en UDP/500, luego nada; no se ve UDP/4500

Causa raíz: NAT‑T no negociado o UDP/4500 bloqueado. A veces causado por deshabilitar NAT‑T en un par o por un middlebox que filtra “UDP desconocido”.

Solución: Habilita NAT‑T en ambos pares. Permite UDP/4500 entrante/saliente. Verifica con tcpdump en ambos extremos. Si un firewall hace “IPsec helper”, considera deshabilitar el helper si manipula el tráfico—los helpers son famosos por ser útiles como un mapache en tu cocina.

2) Síntoma: Túnel “arriba” pero sin tráfico; falta CHILD SA

Causa raíz: Incompatibilidad de propuestas (cipher/PRF/DH) o desajuste de selectores de tráfico (subredes no alineadas). NAT no causa esto directamente pero a menudo lo revela cuando los pares eligen IDs diferentes.

Solución: Compara propuestas y selectores. Usa subredes explícitas y acotadas. Confirma IDs (leftid/rightid). Si un lado espera una IP pública como ID pero el otro envía un FQDN, la negociación puede tener éxito parcialmente y luego fallar en CHILD SA.

3) Síntoma: El tráfico pasa ~30–120 segundos, luego se estanca hasta reconectar

Causa raíz: Timeout de mapeo NAT para UDP/4500; keepalives demasiado infrecuentes o bloqueados.

Solución: Reduce intervalo de keepalive NAT; habilita DPD con timers razonables. Si estás detrás de CGNAT o redes móviles, ajusta agresivamente. Observa la continuidad UDP/4500 con tcpdump.

4) Síntoma: Ping funciona, pero descargas grandes se estancan; algunos sitios cargan, otros cuelgan

Causa raíz: MTU/PMTUD falla por sobrecarga NAT‑T y mensajes ICMP fragmentation-needed bloqueados.

Solución: Trunca MSS (el gateway es lo más sencillo), o reduce MTU en la interfaz del túnel/VTI. Valida con tracepath y ping DF. No “arregles” esto deshabilitando características de cifrado; arregla el tamaño de los paquetes.

5) Síntoma: Un usuario detrás de un NAT puede conectar; segundo usuario falla o expulsa al primero

Causa raíz: El gateway identifica pares solo por IP origen, o la búsqueda de políticas colisiona cuando varios clientes comparten una IP pública.

Solución: Empareja por identidad IKE, no por IP. Asegura IDs/certs únicos. Evita configuraciones que asuman “un par por IP”.

6) Síntoma: Funciona desde algunas redes, falla en hoteles/cafés

Causa raíz: UDP/4500 filtrado, rate‑limited o moldeado; portales cautivos y equipos Wi‑Fi “de seguridad” pueden ser agresivamente tontos.

Solución: Proporciona una alternativa (otra red, transporte VPN alternativo o opciones en el gateway). Como mínimo, detecta y comunica claramente: “Tu red bloquea UDP/4500”.

7) Síntoma: IKE completa, CHILD SA instala, pero el tráfico de retorno nunca llega

Causa raíz: Enrutamiento asimétrico o rutas faltantes; tráfico desencriptado sale por la interfaz equivocada; firewall stateful descarta paquetes de retorno.

Solución: Valida enrutamiento con ip route get. Asegura policy routing si es necesario. Confirma que las subredes protegidas están enrutadas de vuelta al túnel.

8) Síntoma: El rekey provoca cortes cada N minutos

Causa raíz: Desajuste de tiempos de rekey, dispositivos NAT con bugs que eliminan estado durante el rekey, o lifetimes incompatibles que causan SAs superpuestas y reruteo.

Solución: Alinea lifetimes; usa márgenes de rekey sensatos; actualiza firmware; reduce la complejidad. Si no puedes actualizar el dispositivo NAT, reduce la ventana problemática con timers más deterministas.

Broma corta #2: Si tu VPN solo funciona hasta el rekey, felicitaciones: has construido un generador de interrupciones periódicas con cifrado de grado empresarial.

Listas de verificación / plan paso a paso

Checklist A: Levantar IPsec NAT‑T detrás de NAT (sitio‑a‑sitio o road warrior)

Decide identidades primero. Usa identidades FQDN/certificados. Evita “el par debe venir de esta IP” a menos que sea realmente estática.
Abre los puertos correctos. UDP/500 y UDP/4500 entrante/saliente al gateway. Si insistes en permitir ESP (protocolo 50), vale, pero no confíes en ello detrás de NAT.
Habilita NAT‑T explícitamente en ambos pares si tu plataforma lo permite como opcional.
Confirma que las propuestas coinciden. Cipher, integridad, PRF, grupo DH; mantenlo moderno e interoperable.
Define selectores de tráfico/subredes cuidadosamente. Sin solapamientos. No “0.0.0.0/0 a menos que lo quieras”.
Planifica MTU/MSS. Empieza con MTU conservador (p. ej., ~1380) o trunca MSS en el gateway.
Configura keepalives/DPD para el peor NAT. Estás afinando para el dispositivo más cascarrabias del camino, no la mejor red de laboratorio.
Instrumenta. Puntos de captura (egreso cliente, WAN del gateway). Registra estados IKE y CHILD SA y contadores de bytes.

Checklist B: Cuando está roto, aisla capa por capa

Forma de paquete: ¿Ves UDP/500? ¿Ves UDP/4500? ¿Ves ESP‑in‑UDP?
Estado: ¿IKE establecido? ¿CHILD SA instalado? ¿Los contadores incrementan?
Política: ¿Los selectores coinciden con subredes esperadas? ¿Las rutas son correctas en ambos lados?
Transporte: ¿Llegaste a límites de MTU? ¿Se bloquean errores ICMP? ¿Se agota UDP?
Middleboxes: ¿ALG/helper IPsec/inspección haciendo cosas “inteligentes”? Considera apagar ese “inteligente”.

Checklist C: Opciones de endurecimiento que hacen NAT‑T menos frágil

Prefiere IKEv2. Mejor gestión de estado; soporta movilidad como MOBIKE cuando está disponible.
Usa certificados en entornos corporativos. Los PSK escalan mal y llevan a coincidencias de pares descuidadas.
Estandariza timers. DPD + keepalives consistentes entre pares; evita la ruleta de valores por defecto de proveedores.
Baselina MTU/MSS. Elige una configuración conocida y documenta por tipo de túnel.
Monitoriza contadores de bytes, no “túnel arriba”. “Arriba” es un concepto de UI. Los bytes son física.

Preguntas frecuentes

1) ¿Por qué IPsec funciona en el hotspot de mi teléfono pero no en la Wi‑Fi de la oficina?

Diferentes middleboxes. La Wi‑Fi de oficina suele incluir firewalls, proxies, IDS/IPS y filtrado UDP “útil”. Los hotspots móviles comúnmente permiten UDP/4500 porque los operadores esperan uso de VPN. Captura tráfico: si UDP/4500 nunca sale o nunca llega, has encontrado al culpable.

2) ¿Necesito permitir ESP (protocolo IP 50) si tengo NAT‑T?

No estrictamente. NAT‑T encapsula ESP dentro de UDP/4500, así que el camino solo necesita UDP. Permitir ESP puede ayudar si no hay NAT y ambos pares prefieren ESP nativo, pero detrás de NAT no es fiable. Abre primero UDP/500 y UDP/4500.

3) Mis logs dicen “NAT detected”, pero luego la negociación falla. ¿Qué ahora?

La detección de NAT exitosa solo significa que ambos lados notaron la traducción de direcciones. Fallar después suele ser UDP/4500 bloqueado, NAT‑T deshabilitado en un lado, o un desajuste de identidad/selectores que aparece durante AUTH/CHILD SA. Confirma el cambio a UDP/4500 con tcpdump.

4) ¿Cuál es la diferencia entre DPD y keepalives NAT?

DPD (Dead Peer Detection) comprueba si el par está vivo en la capa IKE. Los keepalives NAT son paquetes pequeños periódicos destinados a mantener mapeos NAT UDP. A menudo quieres ambos: keepalives para evitar expiración silenciosa NAT, y DPD para detectar fallos reales del par.

5) ¿Por qué el túnel muestra “conectado” pero no pasa tráfico?

Porque “conectado” generalmente refleja el estado IKE SA. Los datos requieren un CHILD SA más el enrutamiento/política correcta y un MTU no roto. Comprueba contadores CHILD SA y ejecuta ip route get para una IP protegida. Si los contadores no se mueven, el tráfico ni siquiera entra en el túnel.

6) ¿Es el doble NAT (router doméstico + CGNAT ISP) un problema para NAT‑T?

No necesariamente, pero aumenta la probabilidad de timeouts UDP agresivos y reescritura de puertos. Si no puedes controlar el camino, ajusta keepalives agresivamente y considera soporte de movilidad (MOBIKE) para clientes que cambian de red.

7) ¿Debo bajar MTU en el cliente o en el gateway?

Prefiere truncar MSS en el lado gateway para TCP: un cambio arregla muchos clientes. Para protocolos no TCP o si controlas la flota de clientes, fijar un MTU de túnel en el cliente puede ser más limpio. Valida con ping DF/tracepath.

8) ¿Cómo detecto si UDP/4500 está bloqueado sin Wireshark en el cliente?

Revisa capturas en el gateway: si nunca ves UDP/4500 desde ese usuario/red, está bloqueado upstream. Si sí lo ves pero el cliente dice “conectando”, el problema probablemente está en el firewall del host cliente o en el software VPN. También puedes comparar comportamiento entre redes: si funciona en LTE pero no en esa Wi‑Fi, la Wi‑Fi es culpable hasta que se demuestre lo contrario.

9) ¿Puede “IPsec passthrough” en un router romper NAT‑T?

Sí. Algunos dispositivos implementan helpers/ALGs que intentan rastrear y reescribir IKE/ESP. Cuando fallan, manglean paquetes o estado, especialmente con múltiples clientes. Si puedes, desactiva funciones helper IPsec y confía en reenvío UDP simple/NAT stateful.

10) ¿Por qué múltiples usuarios detrás del mismo NAT causan rarezas en algunas pasarelas?

Si la pasarela indexa sesiones solo por IP origen, dos usuarios comparten esa IP y colisionan. Implementaciones correctas usan identidades IKE y valores SPI para desambiguar. La solución es configurar coincidencia por ID o actualizar una pasarela que todavía piensa que NAT es una moda temporal.

Conclusión: qué cambiar el lunes por la mañana

IPsec NAT‑T no es magia; es una capa de compatibilidad para un diseño de red (NAT por todas partes) que IPsec no asumió originalmente. Cuando la VPN no se establece detrás de NAT, raramente es misterioso. Normalmente es una de cuatro cosas: UDP/4500 bloqueado, mapeo NAT que expira, blackholing por MTU, o desajustes de identidad/política empeorados por la traducción de direcciones.

Próximos pasos prácticos:

Instrumenta con capturas de paquetes en el egreso cliente y en la WAN del gateway. Prueba UDP/500 y UDP/4500 en ambas direcciones.
Deja de confiar en “túnel arriba”. Monitoriza contadores de bytes de CHILD SA y la corrección de rutas.
Estandariza timers (DPD + keepalives) para el peor NAT que esperes, no la mejor red de laboratorio.
Haz que MTU sea aburrido con truncado MSS o MTU explícito, y documenta los valores elegidos.
Empareja pares por identidad (cert/FQDN) en lugar de suposiciones frágiles de IP pública, especialmente para sucursales NATeadas y usuarios remotos.

Haz eso, y NAT‑T se convierte en lo que siempre debió ser: tubería anodina. El mejor incidente de VPN es el del que nunca te enteras.