Enrutamiento de VPN sitio a sitio: por qué el túnel está arriba pero nada funciona (y cómo arreglarlo)

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

¿Te fue útil?

El túnel está “arriba”. Tu panel está en verde. La Fase 1 está establecida, la Fase 2 instalada, el par está “conectado”.
Y sin embargo: no hay ping, no hay SSH, no hay conexiones a bases de datos, no hay tráfico de aplicaciones. Has alcanzado el clásico
hito empresarial: la criptografía funciona, la red no.

Este modo de fallo es tan común que merece su propio manual de operaciones. Que el túnel esté arriba sólo significa que los dispositivos acordaron
cómo cifrar. No dice casi nada sobre si los paquetes pueden encontrar el túnel, sobrevivir dentro de él y emerger al otro lado de manera que
el destino acepte y responda.

Qué significa realmente “el túnel está arriba” (y qué no significa)

La mayoría de las VPN sitio a sitio tienen dos conceptos separados de “arriba”:

Plano de control arriba: IKE/handshake completado, claves negociadas, SA establecida. Esto es lo que les encantan a los paneles.
Plano de datos funcionando: los paquetes se enrutana hacia el túnel, coinciden con los selectores, pasan firewall/NAT, sobreviven al MTU y el tráfico de retorno sigue el mismo camino de vuelta.

Tu problema casi siempre está en el plano de datos. Específicamente:

Enrutamiento: los paquetes nunca entran al túnel (rutas equivocadas, rutas faltantes, policy routing incorrecto, VRF incorrecta).
Selectores / política: los paquetes llegan al equipo pero no coinciden con los selectores del VPN (IPsec basado en políticas) o con los AllowedIPs (WireGuard).
NAT / firewall: los paquetes coinciden con el túnel pero son NATeados a algo que el otro lado no espera, o son bloqueados por reglas stateful.
Ruta/MTU: los paquetes desaparecen por fragmentación, PMTUD bloqueado o MSS no limitado.
Asimetría: los paquetes salen por la VPN y vuelven por Internet (u otro WAN), activando firewalls, rp_filter o simplemente “sin ruta de vuelta”.

La única prueba fiable es simple: envía un paquete desde un host detrás del Sitio A a un host detrás del Sitio B y luego demuestra—usando
captures y contadores—dónde se detiene.

Datos interesantes y contexto histórico (que aún te afectan hoy)

Un poco de historia explica por qué el enrutamiento moderno de VPN se siente como arqueología: distintas eras de redes dejaron
supuestos diferentes, y tu configuración actual es un híbrido fósil.

IPsec precede a la “nube”: las especificaciones centrales se formaron cuando la mayoría de las redes eran estáticas y privadas. Hoy lo acoplamos a NAT, overlays y enrutamiento dinámico.
Las VPN basadas en políticas llegaron primero en muchos firewalls: en lugar de “enrutar tráfico a una interfaz”, los diseños iniciales comparaban paquetes contra selectores y los cifraban. Fácil para entornos pequeños, doloroso a escala.
NAT-Traversal (NAT-T) existe porque NAT rompió IPsec: ESP no sobrevivía a dispositivos NAT típicos, así que la encapsulación UDP en el puerto 4500 se convirtió en una salida estándar.
Los agujeros negros de PMTUD son más antiguos que la mayoría de los equipos: ICMP “Fragmentation Needed” ha sido bloqueado por equipos de “seguridad” desde siempre, y la encapsulación en VPN lo empeora.
“Split tunnel” solía ser un debate de VPN cliente: ahora el mismo concepto aparece en sitio a sitio como enrutamiento selectivo, túneles múltiples y políticas de steering.
BGP sobre IPsec se hizo popular porque los humanos son poco fiables: las rutas estáticas están bien hasta que aparece un tercer sitio; entonces estás a una hoja de cálculo de un incidente.
Reverse path filtering (rp_filter) es la respuesta de Linux al spoofing: es excelente… hasta que tu enrutamiento es asimétrico y empieza a descartar tráfico legítimo de VPN.
WireGuard es intencionalmente minimalista: te da un túnel y claves, no frameworks de política. Un AllowedIPs mal configurado es el equivalente moderno al desajuste de selectores.
Espacios RFC1918 superpuestos son una tradición corporativa: 10.0.0.0/8 estaba pensado para ser privado, no universal. Fusiones garantizan que se vuelva universal de todos modos.

Guion de diagnóstico rápido (encuentra el cuello de botella rápido)

Cuando alguien dice “la VPN está arriba pero nada funciona”, no empieces cambiando ajustes cripto. Así conviertes un bug de enrutamiento en una noche larga.
Empieza con un bucle estrecho: demuestra el camino, demuestra la política, demuestra la respuesta.

Primero: demuestra que el paquete entra al gateway VPN

Desde un host detrás del Sitio A, haz ping/traceroute a un host específico detrás del Sitio B (no “la subred”). Elige una IP que controles.
En el gateway VPN del Sitio A, captura tráfico en la interfaz LAN para confirmar que el paquete llega.
Comprueba la decisión de enrutamiento del gateway: ¿envía ese destino a la interfaz de túnel/VTI o coincide con una política?

Segundo: demuestra que el paquete coincide con la política/selectores del VPN

En IPsec, verifica que las SAs instaladas incluyan las subredes exactas de origen/destino que estás probando.
En WireGuard, verifica que AllowedIPs incluya la subred remota y que el par remoto tenga una ruta de vuelta.
Mira los contadores de bytes de la SA. Si permanecen en cero mientras generas tráfico, tu paquete no está entrando en la política del túnel.

Tercero: demuestra la ruta de retorno y el estado

Captura en la interfaz LAN del sitio remoto: ¿el paquete aparece descifrado?
Si llega, captura la respuesta: ¿se enruta de vuelta hacia el túnel?
Comprueba el estado del firewall y rp_filter en ambos lados.

Cuarto: comprueba MTU/MSS sólo después de lo básico de enrutamiento/política

Los problemas de MTU pueden parecer “nada funciona”, pero normalmente se presentan como “ping funciona, TCP se atasca” o “peticiones pequeñas funcionan, las grandes cuelgan”.
No culpes prematuramente al MTU porque está de moda.

Broma #1: Un panel de VPN que dice “Arriba” es como la luz de una máquina de café que dice “Lista”. No garantiza que vayas a obtener café.

Un modelo mental: las cuatro puertas que debe pasar cada paquete

Aquí está el modelo que uso al depurar. Cada paquete que intenta cruzar una VPN sitio a sitio debe pasar por cuatro puertas:

Puerta 1: ¿Puede el host origen alcanzar su gateway, y es el gateway correcto?

Un número sorprendente de problemas “VPN” son en realidad “gateway por defecto incorrecto”, “firewall del host” o “VLAN equivocada”. Si tu host no
está enviando tráfico al gateway VPN (o al enrutador que conoce la VPN), estás depurando el dispositivo equivocado.

Puerta 2: ¿El gateway enruta el paquete hacia el túnel?

Las VPN basadas en rutas dependen de tablas de enrutamiento (estáticas, OSPF/BGP, policy routing). Las VPN basadas en políticas dependen de selectores:
“si el paquete coincide con este ACL, encríptalo.” Ambos pueden fallar de maneras aburridas.

El clásico “el túnel está arriba pero nada funciona” es la falta de una ruta a la subred remota en el lado LAN, de modo que los paquetes
van a Internet en su lugar, nunca alcanzando la política del VPN.

Puerta 3: ¿Acepta el túnel el paquete?

IPsec tiene selectores de tráfico (subredes local/remota). Si tu paquete no coincide, no será cifrado por la SA que crees que existe.
WireGuard tiene AllowedIPs, que es a la vez una política cripto y una política de enrutamiento: decide qué se cifra y qué se acepta de un par.

Puerta 4: ¿Puede el lado remoto entregar el paquete y devolverlo de forma simétrica?

Incluso si el lado remoto recibe el paquete, tiene que entregarlo al host de destino y conseguir una respuesta de vuelta por el mismo camino.
Las respuestas que salen por otra ruta son enemigas de los firewalls stateful, conntrack, expectativas de NAT y rp_filter.

Tareas prácticas con comandos: verificar, decidir, arreglar

Las siguientes tareas están pensadas para ejecutarse durante un incidente. Cada una incluye: un comando, lo que significa su salida y la decisión que tomas.
Los comandos se muestran en Linux porque es común para gateways VPN, jump hosts y máquinas de prueba—aun cuando tu dispositivo VPN sea un appliance firewall.

Task 1: Verify the host is sending traffic to the correct gateway

cr0x@server:~$ ip route show default
default via 10.20.0.1 dev eth0 proto dhcp src 10.20.0.55 metric 100

Significado: El host usa 10.20.0.1 como gateway por defecto. Si tu gateway/enrutador VPN no es 10.20.0.1 (o no conoce rutas al sitio remoto),
tu paquete ni siquiera tiene oportunidad.

Decisión: Si el gateway por defecto es incorrecto, corrige la configuración DHCP/estática o añade una ruta específica a la subred remota vía el enrutador correcto.

Task 2: Confirm there is a route to the remote subnet (host perspective)

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

Significado: El tráfico a 172.31.40.10 va a 10.20.0.1. Ese router debe tener una ruta hacia la VPN; de lo contrario estás filtrando por la ruta equivocada.

Decisión: Si el siguiente salto no es el enrutador esperado con conocimiento de la VPN, añade una ruta más específica o arregla los anuncios de enrutamiento.

Task 3: Check routing on the VPN gateway (route-based VPN)

cr0x@server:~$ ip route get 172.31.40.10
172.31.40.10 dev vti0 src 10.20.0.1 uid 0
    cache

Significado: El gateway enviará este destino por vti0 (una interfaz de túnel virtual). Buen indicio: el enrutamiento apunta al túnel.

Decisión: Si enruta por la interfaz WAN en su lugar, necesitas rutas (estáticas/BGP) o policy routing para dirigirlo al túnel.

Task 4: Identify policy routing or multiple tables (Linux gateways)

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.20.0.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Significado: El tráfico originado desde 10.20.0.0/24 usa la tabla de enrutamiento 100. Si tu ruta VPN vive en main pero el tráfico usa la tabla 100,
no se usará el túnel.

Decisión: Pon la ruta VPN en la tabla correcta o ajusta la regla. Trata el policy routing como código de producción: revisa, prueba y documenta.

Task 5: Confirm IP forwarding is enabled on a Linux VPN gateway

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

Significado: El forwarding está activado. Si es 0, el gateway es un router decorativo.

Decisión: Si está apagado, enciéndelo y persiste el cambio en /etc/sysctl.conf o un drop-in. Luego vuelve a probar el tráfico.

Task 6: Check rp_filter (asymmetry killer)

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1

Significado: El filtrado de ruta inversa estricto está activado. Si el tráfico de retorno es asimétrico (común con dual-WAN o rutas múltiples),
Linux puede descartar paquetes como “suplantados”.

Decisión: Si esperas asimetría, pon en modo suelto (2) en las interfaces relevantes, o corrige la simetría de enrutamiento (preferible).

Task 7: Verify WireGuard peer and AllowedIPs (tunnel up, traffic not)

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: v4bq6nFh1lEoC4QyM2u0n9bZ1gYpP7oGQf+XvYdW2mU=
  listening port: 51820

peer: q0P3sZtVd8l0Rk2m1yG1CwVf1mQf0Qx4lQw2uXn8G3E=
  endpoint: 198.51.100.20:51820
  allowed ips: 172.31.40.0/24
  latest handshake: 18 seconds ago
  transfer: 12.34 KiB received, 9.87 KiB sent

Significado: El handshake es reciente y los contadores de transferencia incrementan. allowed ips incluye 172.31.40.0/24, por lo que el cifrado saliente para esa subred debería ocurrir.

Decisión: Si los contadores no cambian mientras pruebas, tu tráfico no está coincidiendo con AllowedIPs, o el host está enrutando fuera de wg0.

Task 8: Confirm routes created for WireGuard (Linux)

cr0x@server:~$ ip route show dev wg0
172.31.40.0/24 proto kernel scope link src 10.99.0.1

Significado: El kernel tiene una ruta a la subred remota vía wg0. Si falta, podrías estar usando Table = off o un diseño de enrutamiento personalizado.

Decisión: Añade la ruta explícitamente o ajusta la configuración de WireGuard para que programe las rutas como corresponde.

Task 9: Inspect IPsec SAs and traffic selectors (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
siteA-siteB: #3, ESTABLISHED, IKEv2, 4c2b1b3c3e5b2a6f_i* 6a8d9c0b2a1f4e3d_r
  local  '203.0.113.10' @ siteA
  remote '198.51.100.20' @ siteB
  AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256
  established 241s ago, rekeying in 53m
  siteA-siteB-child: #5, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
    local 10.20.0.0/24
    remote 172.31.40.0/24
    bytes_i 18240, bytes_o 16512, rekeying in 49m

Significado: La SA hija está instalada con selectores 10.20.0.0/24 ↔ 172.31.40.0/24. Los contadores de bytes no son cero, así que el tráfico fluye por la SA.

Decisión: Si los selectores no coinciden con lo que pruebas, corrige los selectores locales/remotos de tráfico. Si los bytes se mantienen en 0, los paquetes no están coincidiendo o no llegan al gateway.

Task 10: Check if firewall/NAT rules are interfering (nftables)

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
    iifname "eth0" oifname "vti0" ip saddr 10.20.0.0/24 ip daddr 172.31.40.0/24 accept
    iifname "vti0" oifname "eth0" ip saddr 172.31.40.0/24 ip daddr 10.20.0.0/24 accept
  }
}
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "eth1" masquerade
  }
}

Significado: La política forward es drop; sólo reglas explícitas permiten LAN↔VPN. La masquerade de NAT se aplica a eth1 (WAN), no al túnel.

Decisión: Si NAT se aplica accidentalmente al tráfico del túnel (masquerade en todas las interfaces), arréglalo. Si faltan reglas de forward, añade reglas explícitas que permitan las subredes VPN.

Task 11: Look for NAT on the VPN path (iptables legacy setups)

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o eth1 -j MASQUERADE

Significado: NAT está sólo en la interfaz WAN eth1. Bien. Si ves MASQUERADE sin -o eth1, podrías estar NATeando tráfico VPN sin querer.

Decisión: Ajusta las reglas de NAT para que las subredes VPN estén exentas, o limita la masquerade a la WAN solamente.

Task 12: Prove where packets die using tcpdump (on both sides)

cr0x@server:~$ sudo tcpdump -ni eth0 host 172.31.40.10
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.102938 IP 10.20.0.55 > 172.31.40.10: ICMP echo request, id 3812, seq 1, length 64

Significado: La solicitud llega a la interfaz LAN del gateway. Luego captura en la interfaz del túnel para ver si se está reenviando/cifrando.

Decisión: Si aparece en LAN pero no en el túnel, es enrutamiento/política/firewall en el gateway. Si aparece en el túnel pero no en la LAN remota, es política de túnel/MTU/firewall remoto.

Task 13: Check tunnel interface counters (route-based VPN)

cr0x@server:~$ ip -s link show dev vti0
7: vti0:  mtu 1436 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    RX:  bytes packets errors dropped  missed   mcast
       82912     612      0      0       0       0
    TX:  bytes packets errors dropped carrier collsns
       74488     581      0      0       0       0

Significado: Los contadores que incrementan indican que el tráfico se envía/recibe en la VTI. Si TX incrementa pero RX permanece plano, falta tráfico de retorno o está bloqueado.

Decisión: Si sólo se mueve una dirección, céntrate en la ruta de retorno, firewall remoto, selectores remotos o NAT.

Task 14: Diagnose MTU/PMTUD with ping and DF bit

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

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

Significado: El MTU de tu interfaz local (1436) no puede enviar paquetes de 1428 bytes con DF. Eso es esperable si el MTU del túnel es menor por la sobrecarga de encapsulación.

Decisión: Limita MSS para TCP, reduce el MTU en la interfaz del túnel o asegúrate de que ICMP “frag needed” no esté bloqueado. Si pings pequeños funcionan pero TCP se atasca, el MTU probablemente sea el culpable.

Task 15: Check MSS clamping status (nftables example)

cr0x@server:~$ sudo nft list chain inet mangle forward
table inet mangle {
  chain forward {
    type filter hook forward priority mangle; policy accept;
    oifname "vti0" tcp flags syn tcp option maxseg size set 1360
  }
}

Significado: Los paquetes SYN que salen por el túnel tienen MSS ajustada a 1360. Esto evita que TCP envíe segmentos demasiado grandes para el MTU del túnel.

Decisión: Si ves problemas de PMTUD, implementa MSS clamping en el borde. No es elegante; es efectivo.

Task 16: Trace path and identify “wrong exit” routing

cr0x@server:~$ traceroute -n 172.31.40.10
traceroute to 172.31.40.10 (172.31.40.10), 30 hops max, 60 byte packets
 1  10.20.0.1  0.431 ms  0.382 ms  0.369 ms
 2  203.0.113.1  2.171 ms  2.133 ms  2.114 ms
 3  198.18.0.5  6.990 ms  6.945 ms  6.903 ms

Significado: Este tráfico está saliendo a la WAN (203.0.113.1) en lugar de entrar al túnel. Ese es el olor a “ruta faltante”.

Decisión: Arregla el enrutamiento para dirigir 172.31.40.0/24 al túnel. Si confías en BGP, verifica que el prefijo se anuncie y acepte.

Task 17: Verify BGP-learned routes and next-hop (FRR)

cr0x@server:~$ sudo vtysh -c "show ip route 172.31.40.0/24"
Routing entry for 172.31.40.0/24
  Known via "bgp", distance 20, metric 0, best
  Last update 00:03:12 ago
  * 10.255.255.2, via vti0

Significado: BGP está proporcionando la ruta, next hop sobre vti0. Eso es lo que quieres para una VPN basada en rutas con enrutamiento dinámico.

Decisión: Si la ruta falta o apunta a otro sitio, investiga el estado de la sesión BGP, los filtros de rutas y la alcanzabilidad del next-hop.

Task 18: Check conntrack for stateful firewall weirdness

cr0x@server:~$ sudo conntrack -L -p icmp | head
icmp     1 29 src=10.20.0.55 dst=172.31.40.10 type=8 code=0 id=3812 [UNREPLIED] src=172.31.40.10 dst=10.20.0.55 type=0 code=0 id=3812

Significado: El gateway ve solicitudes echo salientes pero ninguna respuesta. Si esperas respuestas, no están regresando o se están descartando antes de que conntrack las vea.

Decisión: Captura en el lado remoto, comprueba la ruta de retorno y revisa el firewall remoto. Si las respuestas vuelven por otra interfaz, eso es asimetría.

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

1) El túnel muestra “arriba”, pero los contadores de bytes de la SA quedan en cero

Síntomas: IKE establecido; pings/timeout; contadores no se mueven.

Causa raíz: El tráfico nunca coincide con selectores/AllowedIPs, o nunca llega al gateway por enrutamiento.

Solución: Verifica rutas hacia la subred remota en el host origen y en el gateway. Para IPsec basado en políticas, asegura que las subredes de origen/destino exactas coincidan con la child SA. Para WireGuard, asegúrate de que AllowedIPs incluya el destino y que las rutas del kernel apunten a wg0.

2) Tráfico unidireccional: A alcanza a B, B no alcanza a A (o las respuestas nunca llegan)

Síntomas: SYN TCP visto en remoto, SYN-ACK nunca vuelve; ICMP request visto, reply faltante; VTI TX aumenta pero RX plano.

Causa raíz: Falta de ruta de retorno en LAN/router remoto; enrutamiento asimétrico por uplinks múltiples; NAT en un lado cambia la IP de origen inesperadamente.

Solución: Añade/anuncia la ruta de retorno para la subred origen vía la VPN. Asegura exención de NAT para subredes VPN. Si hay múltiples salidas, aplica simetría con policy routing o diseño.

3) El ping funciona, pero HTTPS/SSH cuelga o transferencias grandes se atascan

Síntomas: Paquetes pequeños tienen éxito; conexiones TCP se establecen pero se atascan en datos; aplicaciones fallan misteriosamente.

Causa raíz: MTU/PMTUD por la sobrecarga de encapsulación; ICMP bloqueado; MSS demasiado alto.

Solución: Limita MSS TCP para el tráfico que entra al túnel. Ajusta el MTU de la interfaz del túnel apropiadamente. Permite ICMP “Fragmentation Needed” en las rutas relevantes si tu postura de seguridad lo permite.

4) Funciona para una subred, falla para otra

Síntomas: Algunos hosts alcanzan al remoto; otros no; una VLAN funciona, otra no.

Causa raíz: Selectores/AllowedIPs sólo incluyen una subred; faltan rutas para subredes adicionales; reglas de firewall demasiado restrictivas.

Solución: Expande selectores/AllowedIPs de forma simétrica en ambos extremos. Añade rutas y reglas de firewall para cada subred. Para IPsec, recuerda que ambos lados deben acordar los selectores de tráfico.

5) El tráfico funciona hasta un rekey, luego muere

Síntomas: Estable por minutos/horas, luego agujero negro tras rekey; “túnel arriba” aún mostrado.

Causa raíz: Desajuste de rekey, rebind de NAT, timeouts de firewalls stateful o diferencias en DPD que desincronizan child SAs.

Solución: Alinea lifetimes/márgenes de rekey; asegura NAT-T estable; confirma ajustes de DPD. Monitorea eventos de instalación/remoción de SA, no sólo el estado de IKE.

6) Caídas aleatorias bajo carga, especialmente UDP o VoIP

Síntomas: Jitter, pérdidas, ráfagas de pérdida; ping estable pero tráfico en tiempo real malo.

Causa raíz: QoS no aplicada dentro del túnel; cuello de botella CPU en cifrado; cola y bufferbloat; fragmentación de payloads UDP.

Solución: Perfila CPU y colas de interfaz. Aplica shaping/marking antes del cifrado si es posible. Reduce MTU para aplicaciones UDP intensivas. Considera offload por hardware o instancias más potentes.

7) Todo falla sólo desde una dirección tras un “endurecimiento de seguridad”

Síntomas: Tras un cambio de hardening, el tráfico VPN muere; el tráfico local está bien.

Causa raíz: rp_filter puesto a estricto, política por defecto del firewall cambiada o ICMP bloqueado globalmente.

Solución: Reevalúa rp_filter y reglas de forwarding con el diseño VPN. Pon reglas explícitas allow para subredes VPN. Permite el ICMP necesario para PMTUD, o compénsalo con clamp MSS.

8) Redes superpuestas: ambos lados usan 10.0.0.0/8

Síntomas: El tráfico va a recursos locales en lugar del túnel; las rutas compiten; resultados intermitentes basados en la longitud de prefijo y la política local.

Causa raíz: Superposición de espacios de direcciones. El enrutamiento VPN no puede distinguir “su 10.20.0.0/24” de “nuestro 10.20.0.0/24”.

Solución: Usa NAT (con cuidado) o renumérelas. Si debes usar NAT, hazlo de forma consistente y documenta los rangos traducidos; actualiza selectores y reglas de firewall en consecuencia.

Tres microhistorias corporativas desde el terreno

Mini-historia 1: El incidente causado por una suposición equivocada

Una compañía mediana ejecutaba una VPN IPsec “simple” sitio a sitio entre la HQ y un almacén. El túnel subió. La UI del firewall sonrió.
El equipo del almacén intentó alcanzar una API de inventario en HQ. Nada. Escalaron. Naturalmente, el primer movimiento fue rotar claves y
volver a ejecutar debugging de IKE, porque eso es lo que hace la gente cuando está ansiosa.

La suposición equivocada fue: “Si el túnel está arriba, el firewall enruta el tráfico a través de él.” La configuración real era IPsec basada en políticas.
Sólo el tráfico que coincidía con un par específico de subredes se cifraba. Mientras tanto, la nueva API de inventario se había desplegado en una
VLAN distinta en HQ, con una subred no incluida en los selectores de fase 2.

Los hosts del almacén podían alcanzar la subred antigua sin problema. Nadie lo notó porque la checklist de pruebas era “hacer ping a cualquier host de HQ.”
¿La nueva subred de la API? No estaba en los selectores, así que se enroutó por la ruta por defecto a Internet y se perdió aguas arriba. Los contadores de SA
permanecieron cerca de cero, pero nadie miró porque la UI no los mostraba en primer plano.

La solución fue aburrida: añadir la subred faltante al dominio de cifrado local en un lado y al dominio de cifrado remoto en el otro,
luego reflejar las reglas de firewall. Después de eso, los contadores se movieron, la API fue accesible y todos fingieron que fue un “problema del ISP”
por razones de moral.

Mini-historia 2: La optimización que se volvió en su contra

Una empresa global tenía múltiples túneles sitio a sitio hacia un hub central. La latencia importaba. Alguien propuso una optimización:
aumentar el MTU y dejar que PMTUD “se encargue”. El cambio se desplegó en varios gateways y parecía bien en pings sintéticos. Todos se fueron a casa temprano.

Dos días después, una aplicación financiera empezó a fallar sólo en descargas grandes de informes. La autenticación funcionaba. Las páginas pequeñas cargaban.
Las descargas colgaban. El túnel VPN estaba arriba; los contadores se movían; la CPU estaba bien. Olía al peor tipo de problema: “intermitente”.

El contragolpe fue clásico: PMTUD dependía de mensajes ICMP que estaban bloqueados por una política de seguridad en algún punto entre sitios.
Con los nuevos ajustes MTU, los paquetes encapsulados excedían el MTU real del camino. La red no pudo señalar “necesita fragmentación”, así que los paquetes desaparecían.
TCP reintentó hasta que los timeouts hicieron el resto.

La solución fue limitar MSS en la salida del túnel y reducir el MTU del túnel a un valor seguro que funcionara en todos los caminos.
También ajustaron la política de firewall para permitir los tipos ICMP específicos necesarios para PMTUD—cuando fue posible.
La “optimización” se revirtió, y la lección quedó: el MTU es una verdad compartida, no una preferencia personal.

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

Una empresa SaaS ejecutaba VPNs basadas en rutas desde su datacenter primario hacia varios socios. Tenían la costumbre que parecía tediosa:
cada túnel tenía un “contrato” de una página describiendo prefijos locales/remotos, política de NAT, MTU del túnel y el next-hop de enrutamiento esperado.
También mantenían una receta básica de capture “conocida buena” y la verificaban trimestralmente.

Una tarde, un socio informó que no podía alcanzar una subred específica. El túnel estaba arriba. El equipo del socio insistió “nada cambió”.
El on-call del SaaS abrió el documento de contrato y luego hizo una búsqueda rápida de rutas: el prefijo anunciado por el socio se había reducido sigilosamente de un /16 a un /24.
BGP seguía arriba, pero el conjunto de rutas no era lo que sus reglas de firewall esperaban.

Debido a que la práctica era consistentemente aburrida, el on-call tuvo una línea base para comparar. Pudo decir, con evidencia, “el túnel está bien,
pero su lado ya no anuncia el agregado; sólo estamos aprendiendo este prefijo más específico.” Esa afirmación terminó rápidamente el juego de culpas.

Implementaron una ruta estática temporal para el rango faltante (acotada, con tiempo limitado), mientras el socio arreglaba sus anuncios de rutas.
Sin heroísmos. Sin conjeturas. Sólo expectativas documentadas y verificación rápida.

Broma #2: BGP es como la política de oficina—todos afirman que están compartiendo información, pero aún necesitas comprobar lo que realmente dijeron.

Listas de verificación / plan paso a paso

A. Checklist de incidente (15–30 minutos para aislar)

Elige un par de prueba: un host origen y un host destino específicos, con IPs a las que tengas acceso.
Confirma enrutamiento local del host: ip route get <dest> debe apuntar al gateway/enrutador con conocimiento de la VPN.
Confirma que el gateway ve el tráfico en LAN: captura en la interfaz LAN.
Confirma que el gateway enruta al túnel o coincide con la política: ip route get (basado en rutas) o contadores/selectores de SA (basado en políticas).
Confirma que los contadores del túnel incrementan: contadores VTI, contadores de bytes de SA, contadores de transferencia de WireGuard.
Confirma que el lado remoto recibe tráfico descifrado: captura en el lado LAN remoto.
Confirma la ruta de retorno: captura la respuesta saliendo del lado remoto y asegúrate de que se enruta de regreso al túnel.
Revisa reglas de firewall en ambas direcciones: forward/ACL y exención NAT.
Sólo entonces comprueba MTU/MSS: si TCP cuelga o paquetes grandes fallan.
Documenta el punto de fallo: “muere antes del túnel”, “muere en política de túnel”, “muere tras descifrar” o “ruta de retorno rota”.

B. Checklist para construir bien (antes de poner en producción)

Elige basado en rutas salvo que tengas una razón en contra: escala mejor y facilita el troubleshooting.
Decide enrutamiento dinámico o estático: si habrá más de un par de prefijos, prefiere BGP con filtros claros.
Documenta contratos de prefijos: prefijos locales y remotos, incluyendo expectativas de crecimiento futuro.
Define política NAT explícitamente: exención de NAT para tráfico VPN y rangos traducidos si hay solapamientos.
Configura MTU/MSS intencionalmente: no “lo dejes al azar”. Mide y luego limita.
Planifica para la asimetría: una salida única es la más simple; si no es posible, aplica políticas de enrutamiento y valida rp_filter.
Monitorea señales del plano de datos: bytes de SA, contadores de interfaz VTI, frecuencia de rekey, drops de paquetes—los paneles deben mostrar tráfico, no sólo “conectado”.
Crea un conjunto de pruebas: ping, conexión TCP, petición HTTP, transferencia grande y DNS—ejecútalo después de cada cambio.

C. Checklist de cambios (para no autoboicotear producción)

Antes del cambio: captura baseline de selectores de SA, rutas y valores MTU.
Haz un cambio a la vez: enrutamiento, luego política, luego firewall, luego MTU.
Después del cambio: verifica con el mismo par de prueba y compara contadores antes/después.
Tener rollback: guarda configuraciones previas listas y sabe cómo revertir rutas y reglas de firewall.

Preguntas frecuentes

1) ¿Por qué la VPN dice “arriba” si no pasa tráfico?

Porque “arriba” suele significar que el plano de control IKE está establecido. El plano de datos depende de enrutamiento, selectores/AllowedIPs, firewall/NAT y rutas de retorno.

2) ¿Cuál es la prueba más rápida de que el enrutamiento es el problema?

Ejecuta ip route get <remote-host> en el gateway. Si apunta a la interfaz WAN en lugar del túnel/VTI, encontraste el problema.
Además, un traceroute que muestre saltos por Internet en vez del camino del túnel es revelador.

3) ¿Qué son los “traffic selectors” en IPsec y cómo rompen cosas?

Los traffic selectors definen qué subredes origen/destino cifrará la child SA. Si tu tráfico real usa una subred no incluida en los selectores,
no coincidirá y no se cifrará. Resultado: túnel arriba, tráfico falla.

4) WireGuard hace handshake pero no puedo alcanzar la subred remota. ¿Cuál es la causa habitual?

AllowedIPs mal configurado o rutas del kernel faltantes. WireGuard puede hacer handshake sin tener enrutamiento útil. También verifica que el lado remoto tenga una ruta de vuelta a tu subred.

5) ¿Cómo detectar que el NAT está rompiendo mi VPN sitio a sitio?

Si el lado remoto ve tráfico procedente de una IP traducida (no tu subred real), puede que no coincida con selectores o reglas de firewall.
En gateways Linux, inspecciona reglas NAT y confirma que las subredes VPN estén exentas de masquerade.

6) ¿Por qué el ping funciona pero TCP falla?

Normalmente MTU/MSS. ICMP echo usa paquetes pequeños por defecto; TCP puede negociar segmentos grandes que se descartan por la sobrecarga de encapsulación y PMTUD bloqueado.
Limita MSS y configura MTU conservadoramente en el túnel.

7) ¿Necesito BGP sobre la VPN?

Si tienes múltiples prefijos, múltiples sitios, enlaces de failover o esperas crecimiento, sí—BGP reduce el error humano. Si realmente es una subred por cada lado y no cambiará, rutas estáticas pueden bastar.

8) ¿Cuál es la diferencia entre VPN basada en políticas y basada en rutas para troubleshooting?

Basada en políticas: depuras selectores/ACL y contadores de SA. Basada en rutas: depuras rutas hacia una interfaz de túnel. La basada en rutas tiende a ser más fácil de razonar y escalar.

9) ¿Cómo puede suceder enrutamiento asimétrico si solo hay un túnel VPN?

Porque el resto de la red puede tener múltiples salidas. El paquete saliente podría tomar el túnel, mientras la respuesta toma otro WAN o un enrutador con una vista distinta de rutas.
A los firewalls stateful y a rp_filter no les gusta eso. Soluciona con diseño de enrutamiento, no con esperanza.

10) ¿Qué debo monitorizar para que esto no sea una sorpresa mensual?

Monitoriza contadores de bytes de SA, contadores de interfaz VTI, frecuencia de rekey, drops de paquetes y síntomas relacionados con MTU (retransmisiones TCP).
“Túnel arriba” no es una métrica; es un estado de ánimo.

Conclusión: siguientes pasos que puedes hacer hoy

Si recuerdas una cosa: que un túnel VPN esté arriba prueba que los dos endpoints pueden ponerse de acuerdo sobre cifrado. No prueba que tus paquetes estén siendo enrutados, seleccionados, reenviados y devueltos.
Trata la VPN como un camino de red con plano de control y plano de datos, y depúrala como harías con cualquier otro camino.

Pasos prácticos siguientes:

Crea un único par de prueba (host origen y destino) y escríbelo en tu runbook.
Añade monitorización del plano de datos: bytes de SA y contadores de interfaz del túnel con alertas por “arriba pero inactivo en horas laborales”.
Estandariza en diseños basados en rutas donde sea posible y documenta contratos de prefijos y reglas NAT.
Configura MTU/MSS intencionalmente, luego prueba con transferencias grandes, no sólo pings.
Ejecuta el guion de diagnóstico rápido la próxima vez que alguien diga “la VPN está arriba pero nada funciona” y rehúsa tocar cripto hasta que el enrutamiento esté probado.

“Everything fails, all the time.” — Werner Vogels