Lista de verificación de enrutamiento VPN sitio a sitio para «no puedo alcanzar el otro lado»

Un modelo mental práctico: paquetes, no túneles

«VPN sitio a sitio» suena como un puente mágico entre lugares. En producción es menos poesía y más fontanería:
los paquetes salen de un host, llegan a una decisión de enrutamiento, quizá se les aplique NAT, quizá se filtren, quizá se encapsulen, atraviesan Internet,
luego se desencapsulan, se filtran de nuevo, se enrutan otra vez y finalmente se entregan (o no).

Cuando alguien dice «la VPN está arriba», tradúcelo como: «el intercambio de claves tuvo éxito y quizá existen selectores de Fase 2».
Esa afirmación no garantiza que el plano de datos esté pasando tráfico de extremo a extremo. No garantiza que existan rutas,
no garantiza exenciones de NAT, no garantiza que el tráfico de retorno tome el mismo camino, y definitivamente no garantiza que el MTU no te esté saboteando.

Dos modos de VPN que no debes confundir

La mayoría de las interrupciones en esta categoría empiezan con una discrepancia oculta en las expectativas. La diferencia clave:

• IPsec basado en políticas: el cifrado ocurre cuando el tráfico coincide con los selectores de «tráfico interesante» (traffic selectors / proxy IDs).
  El enrutamiento suele ser «normal», pero el dispositivo VPN decide qué cifrar basándose en pares de subredes origen/destino.
• IPsec basado en rutas: obtienes una interfaz virtual (VTI/interfaz de túnel). Enrutas hacia esa interfaz.
  El cifrado ocurre porque el paquete se enruta hacia la interfaz de túnel, no porque coincida con una lista de selectores (aunque los selectores todavía existan internamente).

Si un lado piensa que es basado en políticas y el otro piensa que es basado en rutas, puedes tener un túnel que «sube»
y un plano de datos que se comporta como un pez muerto.

Regla operativa: depura la ruta del paquete, salto por salto, en ambos extremos.
No depures primero el túnel. El túnel es solo un salto en el medio.

Una cita que vale la pena mantener en tu runbook viene de John Allspaw, repetida en círculos de confiabilidad:
idea parafraseada: el error humano es un síntoma de problemas de sistema más profundos; arregla el sistema, no a la persona.
Aplícalo aquí: «ruta errónea» rara vez es solo «alguien tecleó mal una ruta». Normalmente es falta de protecciones, mala visibilidad o propiedad ambigua.

Guion de diagnóstico rápido (primero/segundo/tercero)

Quieres localizar el cuello de botella rápido. No perfecto. Rápido. Aquí está el orden que normalmente te lleva a una respuesta en minutos.

Primero: demuestra si el tráfico entra al túnel

• Desde un host en el Lado A, haz ping o una prueba TCP a un host en el Lado B.
• En la pasarela VPN del Lado A, comprueba los contadores SA de IPsec (bytes/paquetes). Si no se mueven, no estás coincidiendo selectores ni enrútando hacia el túnel.
• Captura en la interfaz interna: ¿ves el paquete en texto claro llegando a la pasarela?

Segundo: demuestra si el tráfico sale del túnel en el otro extremo

• En la pasarela VPN del Lado B, comprueba los contadores SA. Si Lado A incrementa pero Lado B no, probablemente tengas problemas con el ISP/ACL/NAT-T o peer/PSK/IDs incorrectos (menos común cuando está «arriba»).
• Captura en la interfaz interna del Lado B: ¿ves el paquete desencapsulado saliendo hacia la subred de destino?

Tercero: demuestra que la ruta de retorno es suficientemente simétrica

• La mayoría de los problemas «funciona en una dirección» son por enrutamiento de retorno o problemas de NAT.
• Desde el Lado B, inicia tráfico hacia el Lado A. No asumas que el estado te ayuda.
• Revisa las tablas de enrutamiento en el host destino o su gateway por defecto: ¿sabe la ruta de regreso a la subred remota vía la pasarela VPN?

Broma #1: Si el túnel está arriba pero nada pasa, felicidades: has construido una trituradora de paquetes muy segura.

Datos y contexto interesantes (porque ayuda)

• IPsec nació en los años 1990 como parte de la historia de seguridad de IPv6, luego se convirtió en un complemento práctico para IPv4. Esa historia explica por qué muchos conceptos de IPsec parecen «parches».
• IKEv1 vs IKEv2 no es solo sintaxis. IKEv2 suele ser mejor en rekeying y movilidad y reduce algunos modos de fallo, pero los proveedores aún difieren en valores por defecto y peculiaridades de interoperabilidad.
• Los selectores de «Fase 2» vienen del pensamiento de VPN basada en políticas. Incluso los túneles basados en rutas negocian selectores bajo el capó; algunos proveedores usan 0.0.0.0/0 para «capturar todo», otros insisten en listas explícitas.
• NAT-Traversal (NAT-T) existe porque el NAT rompió ESP de IPsec. ESP no es TCP/UDP, así que los dispositivos NAT clásicos no sabían qué hacer con él; NAT-T envuelve ESP en UDP/4500 para sobrevivir.
• El Path MTU Discovery es frágil bajo encapsulación. Añade la sobrecarga de IPsec y de repente un camino que antes soportaba 1500 bytes empieza a tragar fragmentos.
• Las «asociaciones de seguridad» (SAs) tienen tiempos de vida y comportamiento de rekey. Errores de rekey, problemas de reloj o tiempos de vida desajustados pueden causar tickets periódicos de «cada hora se cae».
• Algunos proveedores implementan túneles basados en rutas como VPN basada en política internamente. Exponen una interfaz de túnel, pero siguen dependiendo de selectores y reglas de coincidencia, lo cual importa cuando añades nuevas subredes.
• BGP sobre IPsec se volvió popular con VPNs en la nube porque convierte la miseria de rutas estáticas en enrutamiento dinámico—hasta que tus temporizadores BGP y el estado del firewall no coinciden.
• El seguimiento de estado del firewall suele ser la tercera parte invisible. No basta con que el enrutamiento sea correcto; la inspección stateful puede descartar tráfico de retorno asimétrico aunque existan rutas.

Listas de verificación / plan paso a paso

Lista A: define el problema en términos de paquetes

• IP de origen (host, no gateway)
• IP de destino
• Protocolo/puerto (ICMP vs TCP/443 importa)
• Direccionalidad (A→B, B→A, o ambas)
• ¿Es «sin ruta», «timeout» o «conexión rechazada»?

Si no puedes nombrar la 5-tupla, estás depurando por sensaciones.

Lista B: confirma el dominio de encriptación / intención de enrutamiento

• ¿Qué subredes deben atravesar la VPN (local y remota)? Haz la lista.
• ¿Es selectores basados en política, o VTI basado en rutas?
• ¿Hay espacio de direcciones superpuesto? (Si sí, detente y planifica NAT o renumeración.)
• ¿Se espera split tunneling, o todo el tráfico debe pasar por la VPN?

Lista C: confirma los tres planos de control

• Plano de control criptográfico: IKE establecido, SAs de IPsec instaladas, rekey estable.
• Plano de control de enrutamiento: rutas en ambos lados para las subredes remotas, next-hop correcto, ninguna ruta más específica que escape.
• Plano de control de políticas: reglas de firewall permiten el tráfico; existe exención de NAT (o NAT correcto); los security groups/NACLs están alineados.

Lista D: confirma el plano de datos de extremo a extremo

• El paquete llega a la pasarela por la interfaz interna (captura).
• El paquete incrementa los contadores IPsec (bytes SA).
• El paquete aparece en la interfaz interna del extremo lejano (captura).
• El paquete de retorno sigue la ruta inversa (enrutamiento + NAT + estado).

Lista E: no te mate el MTU

• Prueba con DF activado y tamaños de carga variables.
• Ajusta MSS en el ingreso del túnel si no puedes confiar en PMTUD.
• Busca patrones «funciona con ping, falla con HTTPS».

Tareas prácticas (comandos, salidas, decisiones)

A continuación hay tareas prácticas que puedes ejecutar durante un incidente. Cada una tiene: un comando, salida de ejemplo, qué significa y qué decisión tomar.
Los comandos asumen endpoints/pasarelas Linux y strongSwan donde procede, pero la lógica se traslada a firewalls y routers en la nube.

Tarea 1: verifica que el host local enruta hacia la pasarela VPN (no hacia Internet)

cr0x@server:~$ ip route get 10.40.5.10
10.40.5.10 via 10.20.0.1 dev eth0 src 10.20.1.50 uid 1000
    cache

Significado: el host enviará tráfico a 10.40.5.10 vía 10.20.0.1.
Si 10.20.0.1 no es tu pasarela VPN (o un router que conoce la VPN), nunca alcanzarás el túnel.

Decisión: si el next hop es incorrecto, arregla la ruta en el host o en el router ascendente (ruta estática o enrutamiento dinámico).

Tarea 2: comprueba que la pasarela VPN tiene una ruta para la subred remota

cr0x@server:~$ ip route show 10.40.0.0/16
10.40.0.0/16 dev vti0 proto static scope link

Significado: túnel basado en rutas: la subred remota sale por vti0.
Si no tienes esto, la pasarela puede enviar tráfico por la ruta por defecto (y luego te preguntas por qué nada funciona).

Decisión: añade/repara la ruta, o arregla la propagación de rutas (BGP, tablas de rutas en la nube).

Tarea 3: verifica que existan IKE/IPsec SAs (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
vpn-siteA-siteB: #12, ESTABLISHED, IKEv2, 3c2a9c1e0e3b1a2f_i* 6f1d2b7c8a9e0d1c_r
  local  'gw-siteA' @ 203.0.113.10[4500]
  remote 'gw-siteB' @ 198.51.100.20[4500]
  AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256
  established 214s ago
  vpn-siteA-siteB{27}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c1a2b3c4_i c4b3a2c1_o
  vpn-siteA-siteB{27}:   10.20.0.0/16 === 10.40.0.0/16
  vpn-siteA-siteB{27}:   bytes_i 0, packets_i 0, bytes_o 8420, packets_o 71

Significado: la SA está instalada; los selectores de tráfico son 10.20/16 a 10.40/16.
Los contadores salientes se incrementan, los entrantes están a cero: el Lado A está enviando tráfico encriptado pero no recibe respuestas (o no coinciden los selectores).

Decisión: céntrate en la ruta de retorno, enrutamiento remoto, selectores remotos o firewall remoto que esté descartando.

Tarea 4: comprueba si los paquetes llegan a la interfaz interna de la pasarela

cr0x@server:~$ sudo tcpdump -ni eth1 host 10.40.5.10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:02:11.102334 IP 10.20.1.50.51124 > 10.40.5.10.443: Flags [S], seq 245112233, win 64240, options [mss 1460,sackOK,TS val 902211 ecr 0,nop,wscale 7], length 0

Significado: el paquete interno alcanza la pasarela. Bien. Si no lo ves, tu problema está río arriba (ruta del host, VLAN, ACL, gateway equivocado).

Decisión: si está ausente, deja de tocar IPsec; arregla el enrutamiento/L2/L3 hacia la pasarela primero.

Tarea 5: comprueba si paquetes cifrados salen de la pasarela hacia el peer

cr0x@server:~$ sudo tcpdump -ni eth0 host 198.51.100.20 and udp port 4500
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:02:11.102901 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP, length 116
14:02:11.103122 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP, length 116

Significado: paquetes ESP encapsulados con NAT-T están saliendo. Si ves paquetes internos pero no UDP/4500, tu política IPsec no está coincidiendo o el firewall los bloquea.

Decisión: inspecciona selectores/políticas y el firewall local. Si los paquetes salen pero nada vuelve, ve al otro extremo y revisa ISP/ACLs.

Tarea 6: confirma que los paquetes se desencapsulan en el otro extremo (captura en interno)

cr0x@server:~$ sudo tcpdump -ni eth1 host 10.20.1.50
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:02:11.145009 IP 10.20.1.50.51124 > 10.40.5.10.443: Flags [S], seq 245112233, win 64240, options [mss 1360,sackOK,TS val 902211 ecr 0,nop,wscale 7], length 0

Significado: en el Lado B ves el origen/destino originales después de la desencapsulación. Eso demuestra que el túnel transporta el paquete.
Si no lo ves pero sí ves UDP/4500 en el exterior, puede que los selectores no coincidan o el dispositivo VPN esté descartando por política.

Decisión: arregla los traffic selectors/proxy IDs, o las reglas basadas en políticas que definen el «tráfico interesante».

Tarea 7: comprueba la política y estado IPsec del kernel Linux (xfrm)

cr0x@server:~$ sudo ip -s xfrm state
src 203.0.113.10 dst 198.51.100.20
    proto esp spi 0xc4b3a2c1 reqid 1 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha256) 0x0000000000000000000000000000000000000000000000000000000000000000 128
    enc cbc(aes) 0x0000000000000000000000000000000000000000000000000000000000000000
    anti-replay context: seq 0x0000002f, oseq 0x00000000, bitmap 0x00000000
    stats: replay-window 0 replay 0 failed 0 bytes 8452 packets 71
src 198.51.100.20 dst 203.0.113.10
    proto esp spi 0xc1a2b3c4 reqid 1 mode tunnel
    stats: replay-window 0 replay 0 failed 0 bytes 0 packets 0

Significado: ESP saliente funciona; el entrante no. Esto corrobora la historia de los contadores SA y te empuja hacia enrutamiento/firewall remoto o bloqueo ascendente.

Decisión: deja de debatir «¿está el túnel arriba?». Lo está. Ahora arregla por qué las respuestas nunca regresan.

Tarea 8: valida las reglas de firewall para tráfico reenviado (nftables en Linux)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iif "eth1" oif "vti0" ip saddr 10.20.0.0/16 ip daddr 10.40.0.0/16 accept
    iif "vti0" oif "eth1" ip saddr 10.40.0.0/16 ip daddr 10.20.0.0/16 accept
  }
}

Significado: la política forward es drop, pero existen permisos explícitos en ambas direcciones. Si solo permites una dirección, el seguimiento de estado puede no cubrir todos los flujos (especialmente si hay asimetría o UDP).

Decisión: asegura que las reglas forward permitan ambas subredes en ambos sentidos, y que las políticas se apliquen a las interfaces correctas.

Tarea 9: detecta NAT que rompe el dominio de encriptación

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

Significado: MASQUERADE hará NAT de todo el tráfico 10.20/16 saliente por eth0. Si tu tráfico VPN sale por eth0 antes de que la política IPsec lo capture,
puedes NATearlo y entonces no coincidirá con los selectores (o el otro lado verá un origen incorrecto y lo descartará).

Decisión: añade exención NAT para tráfico destinado a 10.40/16 (o asegura que la política haga match antes del NAT en tu plataforma).

Tarea 10: confirma que el lado remoto sabe cómo volver a la subred de origen

cr0x@server:~$ ip route get 10.20.1.50
10.20.1.50 via 10.40.0.1 dev eth0 src 10.40.5.10 uid 1000
    cache

Significado: este host (10.40.5.10) enviará tráfico de retorno a 10.40.0.1 (su gateway por defecto), no a la pasarela VPN.
Si 10.40.0.1 no enruta 10.20/16 hacia la VPN, las respuestas van a otro lado y se pierden.

Decisión: añade rutas en el router core de la red remota, o ajusta el enrutamiento para que la pasarela VPN esté en el camino para el tráfico de retorno.

Tarea 11: detecta enrutamiento asimétrico con traceroute (TCP para coincidir con tráfico real)

cr0x@server:~$ traceroute -T -p 443 10.40.5.10
traceroute to 10.40.5.10 (10.40.5.10), 30 hops max, 60 byte packets
 1  10.20.0.1 (10.20.0.1)  0.324 ms  0.291 ms  0.276 ms
 2  * * *
 3  * * *
 4  10.40.5.10 (10.40.5.10)  9.812 ms  9.775 ms  9.741 ms

Significado: el salto 1 es tu gateway interno, luego silencio (probablemente porque los saltos del túnel no envían TTL exceeded), luego el destino.
Si ves saltos públicos, no estás usando la VPN. Si nunca llegas al destino, necesitas capturas y contadores.

Decisión: usa traceroute como una comprobación rápida de cordura, no como un veredicto final. Pasa a capturas/contadores a continuación.

Tarea 12: prueba MTU/PMTUD con pings «no fragmentar»

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

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

Significado: la MTU de la interfaz local es 1400 (o el camino la reduce), y tu carga elegida no cabe con las cabeceras.
En el mundo VPN, incluso una LAN de 1500 a menudo necesita un MTU efectivo menor por la sobrecarga de encapsulación.

Decisión: reduce MTU de la interfaz/túnel o ajusta MSS TCP. Si los ICMP fragmentation-needed están bloqueados, debes compensar explícitamente.

Tarea 13: comprueba el clamp MSS TCP (si lo estás usando, confirma que es real)

cr0x@server:~$ sudo iptables -t mangle -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A FORWARD -o vti0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Significado: los SYN reenviados hacia vti0 obtienen MSS ajustado al PMTU. Esto reduce problemas de «transferencias grandes se quedan atascadas».

Decisión: si tienes síntomas de MTU, añade esto (o equivalente) en un cambio controlado; si ya lo tienes, verifica que PMTU funcione.

Tarea 14: valida que el reenvío esté habilitado (pasarela Linux clásica)

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Significado: la caja no enrutará paquetes entre interfaces. Tu túnel puede estar perfecto y aún así descartar todo.

Decisión: habilita el reenvío y persístelo, luego vuelve a probar. También asegúrate de que la cadena forward del firewall lo permita.

Tarea 15: confirma que el peer es alcanzable y que los puertos no están bloqueados (4500/500)

cr0x@server:~$ sudo nc -uvz 198.51.100.20 4500
Connection to 198.51.100.20 4500 port [udp/*] succeeded!

Significado: no es definitivo para UDP (porque «succeeded» es optimista), pero si esto falla por completo debido a enrutamiento o firewall local, es una pista.

Decisión: si ni siquiera puedes intentar UDP/4500, arregla ACLs ascendentes o filtrado de salida local antes de tocar ajustes de IKE.

Tarea 16: observa flaps de rekey/DPD en los logs (strongSwan)

cr0x@server:~$ sudo journalctl -u strongswan --since "10 minutes ago" | tail -n 12
Dec 27 14:01:22 gw strongswan[1123]: 15[IKE] peer supports MOBIKE
Dec 27 14:01:22 gw strongswan[1123]: 15[IKE] IKE_SA vpn-siteA-siteB[12] established between 203.0.113.10[gw-siteA]...198.51.100.20[gw-siteB]
Dec 27 14:01:22 gw strongswan[1123]: 15[CHD] CHILD_SA vpn-siteA-siteB{27} established with SPIs c1a2b3c4_i c4b3a2c1_o and TS 10.20.0.0/16 === 10.40.0.0/16
Dec 27 14:03:01 gw strongswan[1123]: 07[IKE] sending DPD request
Dec 27 14:03:31 gw strongswan[1123]: 07[IKE] DPD response received
Dec 27 14:05:22 gw strongswan[1123]: 15[CHD] CHILD_SA vpn-siteA-siteB{27} rekeyed

Significado: respuestas DPD estables y rekey exitoso. Si ves timeouts DPD repetidos o fallos de rekey, tendrás cortes intermitentes.

Decisión: si hay flapping, revisa tiempos de expiración de NAT, timeouts de mappings UDP, filtrado del ISP o tiempos/algoritmos desalineados.

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

1) «Túnel arriba, no puedo hacer ping a nada»

• Síntoma: IKE establecido, pero los contadores de bytes de la SA quedan en cero.
• Causa raíz: el enrutamiento no envía tráfico al túnel, o los selectores de política no coinciden con las subredes reales de origen/destino.
• Solución: verifica ip route get y los selectores VPN; añade rutas faltantes o actualiza proxy IDs/pares TS.

2) «Funciona de Sitio A a Sitio B, pero no al revés»

• Síntoma: bytes de SA salientes se incrementan en un lado; los entrantes permanecen planos. Se ven SYNs TCP en un sentido; no hay SYN-ACKs.
• Causa raíz: falta la ruta de retorno en el gateway por defecto de la subred remota; enrutamiento asimétrico; firewall stateful descartando respuestas fuera de estado.
• Solución: añade ruta remota para la subred origen vía la pasarela VPN; asegúrate de que el firewall permita ambos sentidos; evita diseños «one-arm» sin manejo de estado cuidadoso.

3) «Los pings funcionan, HTTPS se queda colgado o las transferencias fallan»

• Síntoma: paquetes pequeños tienen éxito; cargas más grandes fallan; sesiones TCP se establecen y luego se congelan.
• Causa raíz: MTU/PMTUD en blackhole por la sobrecarga IPsec y mensajes ICMP fragmentation-needed bloqueados.
• Solución: ajusta MSS TCP en el ingreso del túnel; reduce MTU de interfaz/túnel; permite tipos ICMP relevantes donde sea seguro.

4) «Solo una subred funciona; una subred nueva no llega»

• Síntoma: redes antiguas pasan tráfico; el CIDR nuevo está muerto.
• Causa raíz: selectors/proxy IDs no actualizados en ambos extremos; tablas de rutas en la nube no actualizadas; falta exención NAT para la nueva subred.
• Solución: actualiza selectores en ambos peers; propaga rutas (estáticas/BGP/nubes); replica exenciones NAT y reglas de firewall.

5) «Cortes intermitentes cada N minutos»

• Síntoma: el tráfico funciona, luego muere brevemente, luego vuelve; los logs muestran eventos de rekey.
• Causa raíz: temporizadores de rekey desajustados, timeouts de mappings NAT, DPD agresivo, o errores de interoperabilidad criptográfica.
• Solución: alinea los lifetimes; configura DPD sensato; mantén NAT-T vivo; actualiza firmware; considera IKEv2 cuando sea posible.

6) «Todo funcionaba hasta que activamos NAT»

• Síntoma: túnel arriba, pero el remoto ve tráfico desde una IP de origen inesperada; las políticas no coinciden.
• Causa raíz: NAT aplicado al tráfico destinado a la VPN antes de la encriptación (o NAT cambió el origen respecto al selector/proxy ID).
• Solución: configura exención NAT; o diseña deliberadamente «NAT dentro del túnel» y actualiza selectores y rutas remotas en consecuencia.

Broma #2: NAT es como un programa de protección de testigos para paquetes—genial hasta que la corte pide su verdadera identidad.

Tres micro-historias corporativas desde la trinchera

Micro-historia 1: el corte causado por una suposición errónea

Una empresa adquiere a un proveedor más pequeño y necesita una VPN sitio a sitio rápida para que finanzas pueda «solo acceder al ERP».
El equipo de red del adquirente configura un túnel basado en rutas con un VTI y añade rutas para la subred del proveedor.
La interfaz del firewall muestra verde. Todo el mundo se va a casa sintiéndose competente.

A la mañana siguiente: nada funciona. Ni SMB, ni HTTPS, ni siquiera ping. La VPN sigue «arriba».
El equipo de aplicaciones empieza a culpar al DNS, y sabes que va a ser un día largo.
El equipo de red revisa contadores: bytes salientes, cero bytes entrantes.

La suposición oculta: «Si nuestro lado enruta al túnel, el otro lado naturalmente hará la ruta de regreso».
En el lado del proveedor, el gateway por defecto es otro router, y ese router no tiene idea de que 10.20.0.0/16 existe detrás de la VPN.
Los paquetes de retorno salen hacia Internet, son descartados por anti-spoofing y desaparecen.

Arreglarlo fue aburrido: una ruta estática en el router core del proveedor apuntando 10.20.0.0/16 a su pasarela VPN, más reglas de firewall para permitir los flujos.
Una vez correcta la ruta de retorno, todo empezó a funcionar al instante. Nadie cambió configuración criptográfica.

La lección: «Túnel arriba» no es un contrato de enrutamiento. Haz explícita la ruta de retorno, por escrito, antes de programar el corte.

Micro-historia 2: la optimización que salió mal

Otra organización quiso «optimizar» el rendimiento VPN para trabajos de replicación nocturnos.
Alguien notó que el MTU de la interfaz del túnel estaba configurado bajo «por seguridad» y decidió aumentarlo a 1500 porque «la LAN es 1500 y los jumbo frames son modernos».
También desactivaron el clamp MSS porque «es procesamiento extra».

Durante unas horas pareció estar bien. Los pings funcionaban. Llamadas API pequeñas funcionaban. El trabajo de replicación empezó… y luego se estancó.
No fue una caída limpia. El peor tipo: medio funcionamiento y mucha confusión.
Las sesiones TCP se establecían y luego se quedaban atascadas bajo carga. Los retransmisos subían. Los gráficos de latencia parecían dientes de sierra.

El problema real fue un blackhole de PMTUD. El camino por Internet no podía realmente transportar 1500 bytes internos una vez añadida la encapsulación IPsec.
Los mensajes ICMP fragmentation-needed estaban filtrados en algún punto ascendente (nadie podía probar dónde, por supuesto).
Así que los paquetes grandes desaparecían, y TCP seguía intentándolo hasta rendirse.

La «optimización» produjo un sistema que fallaba exactamente en las condiciones que debía mejorar.
La solución fue revertir el MTU, reactivar el clamp MSS y añadir una comprobación de monitorización que alertara sobre retransmisos crecientes en los flujos de replicación.
El rendimiento se estabilizó, y todos fingieron que el experimento fue un éxito porque les enseñó algo.

La lección: los cambios de MTU son cambios de producción. Trátalos como migraciones de esquema de base de datos: planifica, prueba y revierte rápido.

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

Una gran empresa tenía docenas de VPNs sitio a sitio porque «hybrid» se convirtió en «espagueti» durante una década.
El equipo de red estaba cansado de tickets nocturnos, así que adoptaron una práctica que nadie encontró emocionante:
para cada túnel, mantener una «hoja de contrato de tráfico» de una página—subredes locales, subredes remotas, expectativas de NAT, método de enrutamiento y comandos de prueba.

Un viernes por la noche, una ventana de cambios introdujo una subred nueva en el Lado A.
Predeciblemente, la subred nueva no llegaba al Lado B. Las subredes antiguas seguían funcionando.
El ingeniero on-call no necesitó conocimiento tribal; abrió el contrato de tráfico y vio la lista de selectores y los patrones de exención NAT requeridos.

Ejecutaron las pruebas del documento: los contadores SA no se incrementaban para la subred nueva, pero sí para la antigua.
Eso apuntó directamente a selectores/proxy IDs. Actualizaron ambos extremos, empujaron la configuración y confirmaron que los contadores se movían.
Tiempo total: menos de una hora, sin conjeturas y sin «quizá sea DNS».

La lección: documentación operativa aburrida y comprobable vence a la sofisticación. Especialmente a las 2 a.m., cuando tu ingenio está dormido.

Preguntas frecuentes (FAQ)

1) Si IKE está establecido, ¿no prueba eso que la VPN funciona?

Prueba que los pares pueden autenticarse y negociar claves. No prueba que el plano de datos esté enrutado correctamente, permitido por política o dimensionado correctamente para el MTU.
Siempre revisa contadores de SA y capturas.

2) ¿Cuál es la forma más rápida de saber si mi tráfico coincide con los selectores?

Mira los contadores CHILD_SA/SA mientras generas tráfico desde el host real origen al destino real.
Si los contadores no se mueven, tu tráfico no se está encriptando (selectores incorrectos, rutas incorrectas o interferencia NAT).

3) Basado en políticas vs basado en rutas: ¿cuál debería preferir?

Prefiere basado en rutas (VTI) cuando puedas. Se alinea con el enrutamiento normal, escala mejor cuando cambian subredes y funciona bien con enrutamiento dinámico como BGP.
Basado en políticas está bien para entornos pequeños y estáticos, pero cada nueva subred se convierte en una negociación con tu yo futuro.

4) ¿Por qué el ping funciona pero mi aplicación no?

ICMP echo es pequeño y tolerante. Las aplicaciones suelen usar TCP con segmentos más grandes y son sensibles a fallos de PMTUD.
Esto es territorio clásico MTU/MSS: prueba con pings DF y ajusta MSS si es necesario.

5) ¿Necesito permitir ICMP a través de la VPN?

Necesitas suficiente ICMP para operaciones saludables, especialmente fragmentation-needed (para PMTUD) y para troubleshooting básico.
Si la política lo prohíbe, compensa con MTU y MSS conservadores, y acepta visibilidad reducida.

6) ¿Cómo rompen las subredes superpuestas una VPN sitio a sitio?

El enrutamiento se vuelve ambiguo: el mismo prefijo de destino existe local y remotamente, así que los paquetes pueden nunca entrar al túnel, o el tráfico de retorno va al lugar equivocado.
Arregla con renumeración (mejor), o con NAT dentro del túnel (común, pero añade complejidad y sorpresas).

7) ¿Qué es la «exención NAT» y por qué me importa?

Es una regla que dice «no hacer NAT al tráfico entre estas subredes privadas; mantener direcciones intactas para que selectores y rutas coincidan».
Sin ella, tu VPN puede encriptar lo equivocado o el otro lado puede descartar tráfico que no coincida con las direcciones de origen esperadas.

8) ¿Cuándo debería usar BGP sobre la VPN?

Úsalo cuando tengas múltiples subredes, cambios frecuentes o múltiples túneles/caminos.
Reduce la deriva de rutas estáticas. Pero monitorízalo: una sesión BGP arriba no significa que el plano de datos esté sano, y el afinado de temporizadores puede crear flaps.

9) ¿Qué significa «enrutamiento asimétrico» en este contexto?

La petición va A→B por la VPN, pero la respuesta va B→A por un camino distinto (a menudo Internet u otro túnel).
A los firewalls stateful no les gusta esto, e incluso el enrutamiento sin estado puede descartarlo por protecciones anti-spoofing.

10) ¿Qué debería estandarizar entre túneles para reducir incidentes?

Estandariza: inventario de dominios de encriptación/subredes, método de ruta (preferir VTI), política de clamp MSS, temporizadores DPD/rekey y una suite de pruebas operativas
(un puñado de pings/chequeos TCP + verificación de contadores SA + un punto de captura).

Conclusión: qué hacer la próxima vez antes de que falle

Cuando «no puedes alcanzar el otro lado», resiste la tentación de tocar primero la criptografía. La mayoría de fallos son enrutamiento, NAT, políticas de firewall o MTU.
Trata el túnel como un salto; depura la ruta del paquete.

Pasos prácticos que puedes hacer esta semana:

• Escribe un contrato de tráfico de una página para cada VPN sitio a sitio: subredes, método de enrutamiento, expectativas de NAT y comandos de prueba.
• Añade una comprobación de monitorización que alerte cuando los contadores SA no se muevan durante ventanas de tráfico conocidas (o ante picos de retransmisos en flujos clave).
• Estandariza el clamp MSS (o MTU validado) entre túneles para dejar de redescubrir el mismo blackhole.
• Durante cambios, prueba explícitamente en ambas direcciones. El éxito en una dirección es un pre-fallo, no una victoria.

Haz eso y tu próximo incidente de «la VPN está arriba pero nada funciona» será más corto, más tranquilo y menos probable que involucre a cinco equipos discutiendo de quién es el paquete.