IPsec/IKEv2: la trampa NAT-T que rompe los túneles sitio a sitio

NAT-T en una frase (y por qué duele)

NAT traversal permite que IPsec siga funcionando cuando alguno de los pares está detrás de NAT encapsulando ESP dentro de UDP/4500, pero la más pequeña discrepancia en detección, puertos, timers o filtrado convierte el “transporte seguro” en “silencio seguro”.

Aquí está el dolor central: el ESP simple (protocolo IP 50) no es amigo del NAT porque NAT necesita puertos de capa de transporte para rastrear flujos. ESP no tiene. NAT-T lo soluciona envolviendo ESP en UDP, dándole al NAT algo sobre qué indexar (IP origen/destino + puerto origen/destino). La envoltura es simple. El ecosistema alrededor no lo es.

Cuando NAT-T falla, tiende a hacerlo de formas que te hacen perder tiempo:

• La IKE SA se establece (UDP/500 funciona), pero las CHILD SAs transportan cero bytes.
• Funciona por un tiempo y luego muere tras periodos de inactividad (expiración del mapeo NAT).
• Solo falla en una dirección (filtrado asimétrico, enrutamiento o mismatch de políticas).
• Solo falla cuando el tráfico es grande (PMTUD/fragmentación/MTU).

Una regla práctica relevante: si ves “túnel arriba, sin tráfico”, deja de mirar propuestas de crypto y empieza a verificar NAT-T y la alcanzabilidad del plano de datos.

Broma #1: NAT es como un gato: ignora los estándares, hace lo que quiere y aun así tienes que mantenerlo.

Qué ocurre realmente en la red: IKEv2 + detección NAT + encapsulación UDP

Fases de IKEv2 que importan para NAT-T

IKEv2 es más limpio que IKEv1, pero las piezas de NAT siguen siendo sutiles. El flujo de alto nivel:

1. IKE_SA_INIT: negocia algoritmos, hace Diffie-Hellman, intercambia nonces y realiza la detección NAT.
2. IKE_AUTH: autentica pares (PSK/certs), establece la IKE SA y configura la(s) primera(s) CHILD SA(s).
3. Rekey de CHILD SA: rekeying periódico de las SAs del plano de datos.

La detección NAT se hace mediante payloads NAT-D. Cada lado hashea lo que cree que debe ser el 4-tupla (direcciones y puertos). Si los hashes no coinciden con lo que el peer ve, los pares concluyen que hay NAT en el camino y cambian al comportamiento NAT-T.

Puertos: UDP/500, UDP/4500 y la parte que la gente olvida

IKEv2 básico usa UDP/500. Si se detecta NAT, el túnel normalmente pasa a UDP/4500 para IKE y para ESP encapsulado. Eso significa:

• UDP/500 debe funcionar (al menos para la negociación inicial).
• UDP/4500 debe funcionar para mensajes IKE continuos y para el plano de datos cuando NAT-T está en uso.
• Algunos dispositivos arrancan en UDP/500, detectan NAT y luego continúan en UDP/4500. Si tu firewall permite 500 pero no 4500, obtienes el clásico “handshake parece bien, el tráfico está muerto”.

ESP vs encapsulación NAT-T

Sin NAT-T, el plano de datos es ESP (protocolo IP 50). Con NAT-T, el plano de datos pasa a ser UDP/4500 llevando ESP. Eso cambia lo que ven los middleboxes:

• Los firewalls stateful ahora necesitan estado UDP para el flujo.
• Los timers de conntrack ahora importan (UDP es “sin conexión”, pero NAT stateful finge lo contrario).
• Algunos dispositivos de seguridad inspeccionan UDP/4500 de forma deficiente o lo rate-limitan agresivamente.

El asesino silencioso: timers de mapeo NAT y keepalives

Los NAT olvidan los mapeos UDP rápido. Treinta segundos es común. Algunos son incluso más cortos bajo carga. Las túneles IPsec, mientras tanto, pueden estar inactivos durante minutos—especialmente enlaces sitio a sitio “de respaldo” o “solo gestión”. Resultado: el mapeo se evapora, el peer sigue enviando paquetes cifrados UDP/4500 al vacío y nadie te lo dice hasta que el siguiente paquete importa.

La solución suele ser un keepalive o ajustar DPD/heartbeats. No “hacer la crypto más fuerte”. No “rekeyear cada 5 minutos”. Mantén vivo el mapeo NAT, o acepta que el primer paquete tras inactividad será sacrificado.

Por qué la fragmentación y los problemas de MTU aparecen más con NAT-T

NAT-T añade overhead UDP. IPsec añade overhead ESP. Si ya tenías MTU ajustada (MPLS, PPPoE, GRE, VNets en la nube, lo que sea), NAT-T te empuja por encima del límite.

Cuando PMTUD está bloqueado (ICMP filtrado), los paquetes grandes desaparecen. Los pings pequeños funcionan. SSH funciona. Las transferencias de archivos se cuelgan. Las conexiones a bases de datos se ralentizan bajo carga. Por eso “me funciona” a menudo significa “solo probé con 56 bytes”.

Broma #2: Lo único más optimista que “hace ping” es “hace ping, así que no es la red”.

Una cita sobre fiabilidad, porque ops tiene recibos

La esperanza no es una estrategia. — Gen. Gordon R. Sullivan

En términos de VPN: no esperes que NAT-T esté bien porque el túnel diga ESTABLISHED. Mide el plano de datos.

Guía rápida de diagnóstico

Este es el orden que encuentra fallos reales rápido. Está sesgado hacia lo que más se rompe en producción: filtrado, estado NAT, enrutamiento/política y MTU.

Primero: confirma qué transporte está usando realmente el túnel

• ¿Está IKE en UDP/500 solamente, o ha cambiado a UDP/4500?
• ¿El plano de datos es ESP (proto 50) o está encapsulado en UDP/4500?

Si no sabes esto, estás solucionando a ciegas. “Permitir IPsec” no es una regla de firewall; es una frase de marketing.

Segundo: demuestra la alcanzabilidad bidireccional de UDP/4500 (no solo “abierto”)

• Captura de paquetes en ambos pares, buscando UDP/4500 saliente y entrante.
• Verifica que el dispositivo NAT mantiene el mapeo el tiempo suficiente (timers/keepalives).

Tercero: valida selectores/políticas y enrutamiento para las subredes protegidas

• ¿Coinciden los traffic selectors (subredes local/remota) en ambos extremos?
• ¿Existe una ruta que apunte las subredes protegidas hacia la interfaz/política del túnel?
• ¿Estás accidentalmente NATeando el tráfico que debería estar cifrado?

Cuarto: si “parte del tráfico funciona”, ve directo a MTU/MSS y fragmentación

• Prueba con DF marcado y tamaños de payload mayores.
• Busca ICMP “fragmentation needed” bloqueados.
• Ajusta el clamp MSS para TCP si es necesario.

Quinto: solo entonces investiga propuestas de crypto y timers de rekey

Sí, los desajustes de propuesta ocurren. Pero las fallas NAT-T suelen ser post-negociación y se ven como “crypto está bien, datos muertos”. Trata los síntomas honestamente.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las tareas que realmente ejecuto cuando un túnel IPsec sitio a sitio está “arriba” pero se comporta como si estuviera embrujado. Cada una incluye un comando realista, salida de muestra, lo que significa y la decisión que tomas.

Task 1: Confirmar SAs IKEv2 y si NAT-T está en uso (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
IKE SAs:
corp-vpn[3]: ESTABLISHED 12 minutes ago, 203.0.113.10[gw-a]...198.51.100.20[gw-b]
corp-vpn[3]: IKEv2, rekeying in 46 minutes
corp-vpn[3]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
corp-vpn{7}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c3b8a9d2_i c9b6a331_o
corp-vpn{7}:  10.10.0.0/16 === 10.20.0.0/16

Qué significa: “ESP in UDP” confirma encapsulación NAT-T en UDP/4500 para el plano de datos.

Decisión: Asegura que UDP/4500 esté permitido de extremo a extremo y que los timers de mapeo NAT no expiren. Si UDP/4500 no está explícitamente permitido, corrígelo antes de tocar propuestas.

Task 2: Buscar mensajes de detección NAT en logs (strongSwan/charon)

cr0x@server:~$ sudo journalctl -u strongswan --since "30 min ago" | egrep -i "NAT|4500|encap|DPD" | tail -n 20
Feb 04 09:12:31 gw-a charon[1123]: 11[IKE] local host is behind NAT, sending keep alives
Feb 04 09:12:31 gw-a charon[1123]: 11[IKE] remote host is behind NAT
Feb 04 09:12:31 gw-a charon[1123]: 11[IKE] switching to NAT-T
Feb 04 09:12:41 gw-a charon[1123]: 11[IKE] sending keep alive to 198.51.100.20[4500]

Qué significa: Se detectó NAT; el daemon cambió a NAT-T y está enviando keepalives.

Decisión: Si el tráfico aún muere, los keepalives pueden no ser lo bastante frecuentes, o el firewall/NAT no permite respuestas entrantes en UDP/4500.

Task 3: Verificar sockets locales en escucha (¿está el daemon enlazado correctamente?)

cr0x@server:~$ sudo ss -ulnp | egrep ':500|:4500'
UNCONN 0      0            0.0.0.0:500       0.0.0.0:*    users:(("charon",pid=1123,fd=10))
UNCONN 0      0            0.0.0.0:4500      0.0.0.0:*    users:(("charon",pid=1123,fd=11))

Qué significa: El daemon IKE está escuchando en UDP/500 y UDP/4500.

Decisión: Si 4500 no escucha, NAT-T no puede funcionar. Corrige la configuración del stack IPsec o verifica capacidades/módulos del kernel.

Task 4: Revisar reglas de firewall para UDP/500 y UDP/4500 (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '/table inet filter/,/}/p' | egrep -n "udp dport (500|4500)|ip protocol esp|drop"
24: udp dport { 500, 4500 } accept
31: ip protocol esp accept
78: counter drop

Qué significa: Este firewall local permite IKE y NAT-T, además de ESP crudo. Bien.

Decisión: Si ves UDP/500 permitido pero no UDP/4500, añade 4500. Si ves drops incrementando, captura y refina reglas.

Task 5: Confirmar que llegan paquetes en UDP/4500 (tcpdump)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 4500 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:14:02.112233 IP 198.51.100.20.4500 > 203.0.113.10.4500: UDP, length 92
09:14:12.112998 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP, length 92
09:14:22.113554 IP 198.51.100.20.4500 > 203.0.113.10.4500: UDP, length 300

Qué significa: Existe tráfico UDP/4500 bidireccional. Al menos el camino de transporte está vivo.

Decisión: Si solo ves saliente o solo entrante, sospecha asimetría en firewall/NAT o filtrado en upstream. Escala al borde de red con capturas como evidencia.

Task 6: Confirmar que el tráfico protegido se está cifrando (estado XFRM)

cr0x@server:~$ sudo ip -s xfrm state
src 203.0.113.10 dst 198.51.100.20
	proto esp spi 0xc9b6a331 reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x... 256 bits
	anti-replay context: seq 0x0000002a, oseq 0x0
	lifetime current: 780s, bytes 12480, packets 104
src 198.51.100.20 dst 203.0.113.10
	proto esp spi 0xc3b8a9d2 reqid 1 mode tunnel
	lifetime current: 780s, bytes 9800, packets 91

Qué significa: Los contadores de paquetes y bytes están aumentando. El cifrado ocurre en el kernel.

Decisión: Si los contadores se mantienen en cero mientras generas tráfico, tus selectores/enrutamiento/política son incorrectos (el tráfico no coincide con la política IPsec), o los paquetes se bloquean antes de alcanzar XFRM.

Task 7: Verificar selectores de política (XFRM policy)

cr0x@server:~$ sudo ip xfrm policy
src 10.10.0.0/16 dst 10.20.0.0/16
	dir out priority 3750 ptype main
	tmpl src 203.0.113.10 dst 198.51.100.20 proto esp reqid 1 mode tunnel
src 10.20.0.0/16 dst 10.10.0.0/16
	dir in priority 3750 ptype main
	tmpl src 198.51.100.20 dst 203.0.113.10 proto esp reqid 1 mode tunnel

Qué significa: El kernel espera que el tráfico entre estas subredes sea tunelizado.

Decisión: Si tus redes reales son /24s pero la política es /16 (o viceversa), tendrás fallos parciales extraños. Corrige los selectores para que coincidan con las rutas reales y el dominio de cifrado previsto.

Task 8: Confirmar que el enrutamiento envía el tráfico protegido al lugar correcto

cr0x@server:~$ ip route get 10.20.5.10 from 10.10.5.10
10.20.5.10 from 10.10.5.10 dev eth0  src 203.0.113.10  uid 0
    cache

Qué significa: En IPsec basado en política, el tráfico a menudo sigue “enrutamiento normal” (por ejemplo, sale por eth0) y es recogido por la política XFRM. Eso está bien.

Decisión: Si la ruta apunta a algún lugar inesperado (egress incorrecto, IP de origen equivocada), corrige enrutamiento/selección de origen. Un origen incorrecto puede romper la detección NAT y el emparejamiento de selectores.

Task 9: Generar tráfico y vigilar que los contadores suban (ping + XFRM)

cr0x@server:~$ ping -c 3 10.20.5.10
PING 10.20.5.10 (10.20.5.10) 56(84) bytes of data.
64 bytes from 10.20.5.10: icmp_seq=1 ttl=63 time=22.3 ms
64 bytes from 10.20.5.10: icmp_seq=2 ttl=63 time=21.9 ms
64 bytes from 10.20.5.10: icmp_seq=3 ttl=63 time=22.1 ms

--- 10.20.5.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 21.9/22.1/22.3/0.2 ms

Qué significa: El plano de datos funciona para paquetes pequeños.

Decisión: Prueba inmediatamente MTU con DF y tamaños mayores. “El ping pequeño funciona” no es éxito; es una trampa.

Task 10: Probar MTU/fragmentación con DF establecido

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

--- 10.20.5.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2034ms

Qué significa: Tu MTU efectiva de camino es menor de lo esperado (aquí 1392). El overhead de IPsec/NAT-T la redujo. Si ICMP está bloqueado en otro punto, podrías ver pérdidas silenciosas en lugar de un error local.

Decisión: Limita TCP MSS (para aplicaciones TCP intensivas) y/o reduce la MTU de la interfaz en la ruta del túnel. Si no controlas las redes intermedias, el clamp MSS suele ser la solución pragmática.

Task 11: Revisar reglas de clamp TCP MSS (ejemplo iptables)

cr0x@server:~$ sudo iptables -t mangle -S | egrep "TCPMSS|clamp-mss-to-pmtu"
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Qué significa: El clamp MSS está activado en paquetes TCP SYN reenviados.

Decisión: Si tienes blackholes de MTU y no puedes arreglar ICMP, añade clamp MSS en el gateway y vuelve a probar transferencias de archivos y handshakes TLS.

Task 12: Validar que no se aplica NAT al tráfico protegido (tabla NAT iptables)

cr0x@server:~$ sudo iptables -t nat -S POSTROUTING
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.10.0.0/16 -o eth0 -j MASQUERADE

Qué significa: Esto haría NAT a todo el tráfico desde 10.10.0.0/16 saliendo por eth0, incluyendo tráfico que debería cifrarse hacia 10.20.0.0/16.

Decisión: Añade una regla de exención NAT para el destino VPN antes de MASQUERADE, o ajusta la regla MASQUERADE para excluir la subred remota protegida.

Task 13: Inspeccionar timeouts de conntrack para UDP/4500

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_udp_timeout net.netfilter.nf_conntrack_udp_timeout_stream
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180

Qué significa: El estado “conexión” UDP expira rápido (30s para flujos sin respuesta). Eso puede matar túneles NAT-T inactivos si los keepalives son muy espaciados.

Decisión: Prefiere configurar keepalives/DPD en IKE; ajustar timeouts de conntrack puede ayudar pero afecta a toda la máquina y puede tener efectos no deseados.

Task 14: Verificar que rekey/DPD no causen caídas autoinfligidas (estado strongSwan)

cr0x@server:~$ sudo swanctl --list-conns | sed -n '/corp-vpn/,/}/p'
corp-vpn: IKEv2, dpd_delay=30s, dpd_timeout=120s, rekey_time=1h
  local:  203.0.113.10
  remote: 198.51.100.20
  local_ts: 10.10.0.0/16
  remote_ts: 10.20.0.0/16

Qué significa: DPD está configurado. El intervalo de rekey es razonable.

Decisión: Si ves DPD super agresivo (por ejemplo, delay 5s, timeout 15s) en un WAN con pérdida, provocarás caídas. Ajusta según el enlace real, no según el deseado.

Task 15: Probar si UDP/4500 está bloqueado upstream (nmap UDP con precaución)

cr0x@server:~$ sudo nmap -sU -p 500,4500 198.51.100.20
Starting Nmap 7.94 ( https://nmap.org ) at 2026-02-04 09:22 UTC
Nmap scan report for 198.51.100.20
Host is up (0.021s latency).

PORT     STATE         SERVICE
500/udp  open|filtered isakmp
4500/udp open|filtered nat-t-ike

Nmap done: 1 IP address (1 host up) scanned in 2.49 seconds

Qué significa: Los resultados del escaneo UDP son ambiguos (“open|filtered” es común). No prueba que esté abierto, pero te dice que el host es alcanzable y no está devolviendo ICMP port-unreachable.

Decisión: Usa tcpdump como fuente de la verdad. Si ves tus paquetes salir pero nunca ves respuestas, escala con capturas.

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

1) “IKE SA establecido, pero no pasa tráfico”

Síntoma: El plano de control se levanta. Contadores del plano de datos en cero.

Causa raíz: UDP/4500 bloqueado (o ESP bloqueado cuando NAT-T está off). O los selectores no coinciden, por lo que los paquetes nunca llegan a XFRM.

Solución: Confirma “ESP in UDP” (o no) en la salida de SA, luego permite UDP/4500 bidireccionalmente. Valida que los selectores XFRM coincidan con las subredes reales y que existan exenciones NAT.

2) “Funciona un rato, luego muere tras inactividad”

Síntoma: Tras 5–30 minutos de inactividad, el primer flujo nuevo entra en timeout; el túnel puede recuperarse después.

Causa raíz: Expiración del mapeo NAT para UDP/4500; keepalives/DPD demasiado lentos; estado UDP upstream expirando.

Solución: Habilita keepalives NAT / checks de liveness IKEv2 afinados para ser más frecuentes que el timeout NAT más corto en el camino. Si no puedes conocer el timeout, asume 20–30 segundos y diseña para eso.

3) “Una dirección funciona, la otra no”

Síntoma: Sitio A puede alcanzar Sitio B, pero no al revés (o solo algunas subredes funcionan).

Causa raíz: Enrutamiento asimétrico, ruta de retorno faltante, subredes solapadas, mismatch de políticas o NAT en solo un lado sin permisos simétricos.

Solución: Compara los traffic selectors en ambos extremos; revisa tablas de enrutamiento; asegura que no haya solapamientos; verifica reglas de firewall en ambas direcciones; confirma que los paquetes están encapsulados y se ven en ambos extremos con tcpdump.

4) “El ping funciona, SMB/HTTPS/transferencias de archivos se cuelgan”

Síntoma: Paquetes pequeños tienen éxito; cargas mayores se cuelgan o se reinician.

Causa raíz: Blackhole de MTU por overhead IPsec + NAT-T; PMTUD roto; ICMP filtrado; fragmentación mal manejada por el NAT.

Solución: Prueba con pings DF, aplica clamp MSS y/o ajusta MTU en interfaces relevantes. También permite tipos ICMP necesarios si tu postura de seguridad lo permite.

5) “El túnel hace flap durante rekey, especialmente con NAT”

Síntoma: Caídas periódicas alineadas con timers de rekey; logs muestran retransmisiones y churn de CHILD SA.

Causa raíz: Colisiones de rekey, mala estabilidad NAT, pinholes estrictos del firewall o DPD agresivo interactuando con pérdida transitoria.

Solución: Escalonar tiempos de rekey, evitar lifetimes ultra-cortos, afinar DPD y asegurar que UDP/4500 no esté rate-limited ni sujeto a timers cortos de conntrack.

6) “Todo se rompe tras cambiar de ISP/modem/router”

Síntoma: Mismas configuraciones, nuevo equipo de acceso, ahora NAT-T falla.

Causa raíz: Nuevo dispositivo hace NAT simétrico, cambia preservación de puertos o “optimiza” UDP agresivamente. Algunos también bloquean UDP/4500 por defecto.

Solución: Coloca el gateway VPN en una IP pública o en modo bridge cuando sea posible; de lo contrario, ajusta keepalives y verifica paso de UDP/4500 explícitamente.

7) “La nube dice conectado; on-prem no ve inbound”

Síntoma: Lado cloud está contento; on-prem muestra IKE arriba; falta el plano de datos inbound.

Causa raíz: El borde on-prem permite outbound pero no inbound UDP/4500; o el dispositivo NAT no preserva puertos; o reglas de security group incompletas.

Solución: Valida reglas simétricas en ambos extremos. Captura en la interfaz WAN on-prem para probar si llega tráfico encapsulado inbound.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición errónea

Tuvieron una VPN sitio a sitio entre una oficina pequeña y un DC central. Había funcionado durante años. Luego la oficina cambió de piso y recibió una “sencilla” renovación de red: un nuevo circuito ISP, un nuevo firewall de borde y un rediseño de VLAN que dejó los diagramas muy limpios.

El lunes por la mañana el túnel se levantó. Su monitorización vio IKE establecido y declaró victoria. Pero el tráfico del cliente ERP estaba muerto. La primera respuesta del vendor fue la habitual: “Parece su firewall.” La primera respuesta del equipo de red también fue la habitual: “El túnel está arriba, así que no es nuestra culpa.” Ese estancamiento consumió medio día.

La suposición errónea fue sutil: asumieron que porque UDP/500 estaba permitido y IKE se negociaba, NAT-T “simplemente funcionaría.” En el nuevo firewall, UDP/4500 no estaba permitido inbound por defecto. El dispositivo sí permitía outbound. Así que la oficina podía iniciar, pero el DC no podía enviar de forma fiable tráfico encapsulado de vuelta tras rekeys e inactividad.

Lo que lo arregló no fue heroísmo. Fueron dos capturas de paquetes y una reunión incómoda. Un tcpdump en la WAN de la oficina mostró UDP/4500 saliendo. Una captura en el borde del DC no mostró nada llegando. Con esa evidencia, el debate terminó. Añadieron reglas simétricas para UDP/4500, activaron keepalives en el gateway de la oficina y el túnel dejó de mentir.

Microhistoria 2: La “optimización” que salió mal

Otra compañía tenía una malla global de VPNs, y alguien se puso ambicioso por “reducir ruido”. Notaron keepalives NAT periódicos y probes DPD y decidieron alargar timers—menos ruido, menos CPU, menos logs. Sonaba responsable. También rompió la realidad.

Sus NATs de borde, particularmente en sitios pequeños, tenían timeouts UDP agresivos. Con intervalos de keepalive más largos, los mapeos NAT expiraban durante periodos de calma. El siguiente pico de tráfico empresarial golpeaba un mapeo muerto. El peer remoto retransmitía. DPD declaraba el peer muerto. El tiempo de rekey derivó. Desde el lado de la aplicación, parecía cortes aleatorios de 30–90 segundos algunas veces al día.

Como el túnel a menudo se sanaba solo, la primera reacción fue culpar al ISP o “la nube”. Pero las capturas mostraron que el gateway remoto enviaba diligentemente paquetes UDP/4500 a una combinación de dirección/puerto que el NAT ya no encaminaba. Nada en el exterior estaba “down”. El estado se había ido.

La solución fue deshacer la optimización y aceptar un pequeño goteo de keepalives como el coste de operar detrás de NAT. También impusieron una política: si cambias timers de liveness, debes validar contra el timeout NAT más corto de la flota, no contra el mejor. El túnel ruidoso se volvió confiable. En ops, lo aburrido es una característica.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una organización financiera tenía control de cambios estricto y una costumbre molesta: cada cambio de red requería una captura previa y una captura posterior para enlaces críticos. Los ingenieros se quejaban. A nadie le gusta esa “teatralidad” de proceso. Pero esto resultó ser teatro real: del tipo donde atrapas al villano antes del tercer acto.

Planearon una actualización de firewall en un sitio remoto. Antes del cambio, capturaron 60 segundos de tráfico en la interfaz WAN y lo guardaron con el registro del cambio. Tras la actualización, el túnel se levantó—pero la app del call center empezó a fallar en respuestas grandes. Las pruebas pequeñas pasaban. El vendor dijo “no somos nosotros.” El equipo de apps dijo “red.” Ya conoces el coro.

Porque tenían pcaps antes/después, pudieron comparar. La captura post-upgrade mostró paquetes UDP/4500 más grandes que antes y un cambio en el comportamiento de fragmentación. El nuevo firewall estaba descartando fragmentos IP más agresivamente en el lado WAN. Eso no es un problema IKE; es una realidad del plano de datos.

La solución fue igualmente aburrida: clamp TCP MSS y ajustar la MTU de la interfaz para tener en cuenta el overhead IPsec/NAT-T. El túnel no solo se recuperó: dejó de generar fallos intermitentes extraños. El proceso que todos se burlaban produjo el informe de menor tiempo de inactividad del trimestre.

Listas de verificación / plan paso a paso

Hacerlo bien (nuevo sitio a sitio detrás de NAT)

1. Decide el modelo: Si puedes evitar NAT, evítalo. Pon al menos un par en una IP pública estable cuando sea posible.
2. Abre el tráfico correcto: Permite UDP/500 y UDP/4500 de forma bidireccional. Si alguna vez operas sin NAT-T, también permite ESP (proto IP 50). Sé explícito.
3. Elige lifetimes sensatos: No rekeyees cada pocos minutos a menos que disfrutes el pager.
4. Habilita liveness: Configura DPD y keepalives NAT. Afina para el peor timeout NAT que esperes, no para el mejor.
5. Planifica MTU: Asume overhead. Valida con pruebas DF. Implementa clamp MSS si no controlas ICMP end-to-end.
6. Escribe los selectores: Subredes local/remota y verifica que no se solapen con otros sitios.
7. Implementa exenciones NAT: El tráfico destinado a la VPN no debe ser source-NATeado antes de cifrar.
8. Añade monitorización que mida el plano de datos: No solo “túnel arriba.” Mide flujos exitosos, contadores de bytes y latencia/jitter.

Cámbialo sin romperlo (upgrades de firewall, swaps de ISP, cambios de subred)

1. Captura UDP/500 y UDP/4500 antes del cambio (30–60 segundos con tráfico real).
2. Registra estado actual de SA, selectores y ajustes MTU/MSS.
3. Después del cambio, confirma primero puertos en escucha y reglas de firewall.
4. Vuelve a probar con ping pequeño y ping DF.
5. Verifica que los contadores XFRM o contadores equivalentes del vendor aumenten cuando generas tráfico.
6. Sólo entonces ajusta timers/propuestas si la negociación falla.

Cuando hay incendio (checklist de respuesta a incidentes)

1. ¿Negocia en UDP/500? ¿Cambia a UDP/4500?
2. ¿Ambos lados ven UDP/4500 entrante en una captura?
3. ¿Aumentan los contadores de bytes en las SAs?
4. ¿Coinciden los selectores con las subredes reales? ¿Hay solapamientos?
5. ¿Existe exención NAT? ¿Nuevas reglas MASQUERADE?
6. ¿Pasan pings DF grandes? Si no, aplica clamp MSS ahora y programa trabajo MTU profundo.
7. Revisa cambios recientes de ISP/CPE que introdujeron doble NAT o nuevo filtrado.

Hechos e historia interesantes que puedes usar

• NAT no formaba parte del diseño original de IP. Se hizo popular en los años 90 como respuesta pragmática al agotamiento de IPv4 y a políticas de direccionamiento.
• ESP clásico no tiene puertos. Los NAT típicamente rastrean flujos usando puertos, por eso ESP (protocolo IP 50) es inherentemente hostil al NAT.
• NAT-T estandarizó el enfoque “ESP en UDP”. La idea central es simple: envolver ESP para que NAT lo rastree como cualquier flujo UDP.
• UDP/4500 es el puerto convencional de NAT-T. UDP/500 se usa para IKE; NAT-T comúnmente transiciona a UDP/4500 tras la detección NAT.
• IKEv2 mejoró la estructura de mensajes y la fiabilidad. Comparado con IKEv1, IKEv2 es menos barroco y suele comportarse mejor bajo pérdida de paquetes—pero aún depende del comportamiento del camino de red.
• Algunos NATs son “simétricos”, y eso importa. NAT simétrico puede romper suposiciones sobre preservación de puertos y alcance inbound, especialmente cuando múltiples túneles o peers comparten una dirección.
• Los fallos PMTUD son anteriores a NAT-T. Pero NAT-T aumenta el overhead, haciendo que problemas latentes de MTU aparezcan con mayor frecuencia y dolorosamente.
• DPD y keepalives son herramientas operativas, no lujos. Existen porque los middleboxes caducan estado y porque el “fallo silencioso” es común en Internet.
• Las VPNs en la nube a menudo ocultan complejidad detrás del estado “conectado”. Ese estado suele reflejar salud del control-plane IKE, no si tus subredes y rutas específicas están pasando tráfico real.

FAQ

1) Si IKEv2 muestra ESTABLISHED, ¿por qué no puedo pasar tráfico?

Porque plano de control y plano de datos son distintos. IKE puede tener éxito en UDP/500 mientras UDP/4500 o ESP están bloqueados, los selectores no coinciden, las rutas son incorrectas o los blackholes MTU se comen tus paquetes grandes.

2) ¿Siempre debo abrir ESP (protocolo IP 50)?

Si siempre usas NAT-T, el plano de datos es UDP/4500, no ESP crudo. Pero muchos entornos pueden cambiar de modo según la detección NAT o la configuración, así que permitir ESP puede ser útil. La respuesta real: verifica qué usan tus pares y escribe reglas de firewall en consecuencia.

3) ¿Puedo ejecutar NAT-T aunque no haya NAT?

A menudo sí, dependiendo de la implementación. Pero forzar NAT-T en todas partes puede añadir overhead y exponerte a filtrado/conntrack específico de UDP. Úsalo cuando lo necesites; no por superstición.

4) ¿Por qué el túnel muere sólo tras estar inactivo?

El NAT y los firewalls stateful caducan el estado UDP. Sin keepalives frecuentes, el mapeo desaparece. Tu siguiente paquete llega a un mapeo que ya no existe.

5) ¿Qué intervalo de keepalive debería usar?

Menos que el timeout NAT más corto que esperes en el camino. En entornos empresariales mixtos, asumir ~20–30 segundos es común. El valor “correcto” mantiene los mapeos vivos sin causar churn innecesario. Si vas a adivinar, sé conservador y verifica con mediciones.

6) ¿Por qué los pings pequeños funcionan pero las aplicaciones fallan?

MTU/fragmentación. NAT-T + IPsec reducen la MTU efectiva. Si PMTUD está roto, los paquetes grandes desaparecen. Arregla con clamp MSS y/o ajuste de MTU, y contempla permitir tipos ICMP necesarios.

7) ¿Cuál es la forma más rápida de demostrar que UDP/4500 está bloqueado?

Captura en ambos extremos. Si ves UDP/4500 saliente en un peer y nada llegando al otro, el camino está filtrando o enrutando mal. Las capturas de paquetes vencen las opiniones.

8) ¿Importa el doble NAT?

Sí. Puede cambiar mapeos de puertos, acortar timers e introducir comportamiento NAT simétrico. Si no puedes eliminar doble NAT, normalmente necesitás keepalives más agresivos y reglas de firewall más estrictas y simétricas.

9) ¿Los timers de rekey agresivos son buenos para la seguridad?

La seguridad no mejora volviendo el túnel inutilizable. Lifetimes razonables con comportamiento estable superan rekeys constantes que provocan pérdida de paquetes, colisiones y flaps—especialmente detrás de NAT.

10) ¿Cómo debo monitorizar correctamente un túnel IPsec sitio a sitio?

Monitoriza éxito en el plano de datos: transacciones sintéticas periódicas entre hosts/subredes reales, además de contadores de bytes de SA y eventos de retransmit/DPD. “IKE está arriba” es necesario, no suficiente.

Próximos pasos que deberías hacer

1. Inventaría tus túneles y registra para cada uno: si usa NAT-T (UDP/4500), qué subredes protege y qué timers keepalive/DPD están configurados.
2. Haz explícitas las reglas UDP/4500 en cada firewall entre pares. “IPsec permitido” no pasa una auditoría.
3. Añade una verificación por plano de datos por túnel: un ping pequeño, un ping DF cerca de MTU y una transacción TCP (HTTPS o similar). Alerta por fallo, no por “SA faltante”.
4. Arregla MTU proactivamente: implementa clamp MSS en gateways donde no controlas ICMP y donde los túneles cruzan redes impredecibles.
5. Deja de “optimizar” keepalives a menos que hayas medido timeouts NAT end-to-end. Si reduces chatter, hazlo con evidencia y planes de rollback.
6. Cuando ocurran incidentes, lidera con capturas. Un pcap de 30 segundos en cada interfaz WAN acaba con las discusiones más rápido que cualquier reunión.

Si haces esto, NAT-T vuelve a ser un detalle aburrido—que es exactamente donde pertenece.