VPN sitio a sitio: la lista de verificación de enrutamiento que evita el tráfico unidireccional

El modelo mental: por qué “túnel activo” no equivale a “flujo de tráfico”

Una VPN sitio a sitio tiene dos trabajos distintos:

1. Keying y cifrado: autenticar pares, negociar algoritmos y construir Security Associations (SAs).
2. Reenviar tráfico: decidir qué paquetes entran al túnel y adónde van los paquetes de respuesta.

La mayoría de los paneles de NOC se obsesionan con el trabajo n.º 1. El trabajo n.º 2 es donde están los problemas graves.

El tráfico unidireccional es una falla de integridad del enrutamiento

“Unidireccional” suele significar una de estas cosas:

• Enrutamiento asimétrico: el paquete entra por el túnel en una dirección y regresa por Internet (u otro camino) y se descarta.
• Dominio de cifrado / selectores incorrectos: origen/destino no coinciden con las políticas negociadas, por lo que el tráfico nunca entra al túnel (o solo lo hace en una dirección).
• NAT en el lugar equivocado: la ruta de ida está NATeada pero la ruta de vuelta espera direcciones originales (o al revés).
• Incompatibilidad con firewall stateful: los paquetes de retorno no se reconocen como establecidos porque llegan por otra interfaz/camino.
• PMTU / fragmentación: pequeños pings funcionan; TCP se estanca; solo fallan ciertas aplicaciones. Parece “unidireccional” en la capa de aplicación.
• Subredes superpuestas: ambos extremos creen que 10.0.0.0/8 es “local”. Spoiler: no puede ser local en ambos lados.

Aquí está la regla de producción más simple que conozco: por cada prefijo protegido por VPN en el Lado A, el Lado B debe tener una ruta de retorno inequívoca de regreso por el túnel, y viceversa. Si no puedes decir eso en voz alta con CIDR exactos, no has terminado.

Una cita para mantener la honestidad (idea parafraseada): Werner Vogels: todo falla; diseña asumiendo fallos y verifica el comportamiento en lugar de confiar en las luces de estado.

Chiste #1: Un túnel VPN “activo” sin rutas funcionales es como el vestíbulo de un hotel sin habitaciones: bonito, inútil y, de algún modo, todavía caro.

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

Si solo tienes 15 minutos y la gente te manda capturas de pantalla de “Phase 2: up”, haz esto. En orden. Sin desvíos.

Primero: demuestra el camino en ambas direcciones

• Elige un host origen en el Lado A y un host destino en el Lado B.
• Prueba ICMP y TCP (solo ICMP miente—amablemente).
• Ejecuta traceroute (o mejor: tracepath) en ambas direcciones y compara.

Decisión: si alguna dirección no entra por la interfaz/pasarela del túnel que esperas, deja de culpar a IPsec. Arregla el enrutamiento o la selección de políticas.

Segundo: verifica selectores / rutas y rutas de retorno

• IPsec basado en políticas: verifica que los selectores de tráfico (subredes locales/remotas) en ambos lados coincidan exactamente.
• IPsec basado en rutas (VTI): verifica que las rutas del kernel apunten los prefijos remotos al VTI, y que las rutas inversas hagan lo mismo.
• Revisa posibles solapamientos, discordancias de superred y rutas estáticas “temporales” que aún persisten.

Decisión: si las tablas de enrutamiento parecen correctas pero el tráfico de retorno aún no vuelve, probablemente estés ante NAT, estado de firewall o enrutamiento asimétrico mediante un segundo WAN.

Tercero: MTU/MSS y reglas de NAT

• Si el ping funciona pero las aplicaciones no: sospecha de MTU/MSS.
• Si solo fallan ciertas subredes: sospecha exenciones de NAT, orden incorrecto de ACL o discordancia de selectores.
• Si funciona solo en una dirección: sospecha de firewall stateful o ruta de retorno (sí, otra vez).

Decisión: aplica MSS clamping para TCP, verifica PMTU con tracepath y asegúrate de que las exenciones de NAT cubran exactamente los CIDR protegidos por la VPN.

Listas de verificación / plan paso a paso (hacer en este orden)

Lista de verificación 1: Define tu dominio de cifrado con intención

1. Escribe los prefijos protegidos del Lado A (CIDR exactos) y los prefijos protegidos del Lado B.
2. Confirma que no haya solapamientos. Si los hay, detente y renumera o usa NAT intencionalmente (no por accidente).
3. Decide entre basado en rutas (VTI) o basado en políticas. Si puedes elegir, elige basado en rutas por saneamiento operativo.
4. Documenta qué IPs deben ser accesibles a través del túnel y cuáles no.

Lista de verificación 2: Haz el enrutamiento simétrico por construcción

1. Para cada prefijo remoto, confirma que exista exactamente una ruta preferida: vía la VPN.
2. Si usas enrutamiento dinámico (BGP/OSPF), confirma:
   • las rutas se anuncian en ambos sentidos
   • los filtros permiten los prefijos previstos
   • las métricas/comunidades prefieren la ruta por VPN
3. Si usas rutas estáticas, asegúrate:
   • que estén en ambos lados
   • que no estén ocultas por una ruta más amplia (como una ruta por defecto)
4. Activa el filtrado de ruta inversa de forma pensada (rp_filter)—el modo estricto puede romper multi-homing válido.

Lista de verificación 3: Decide dónde se permite NAT, y luego aplícalo

1. Haz una declaración de política NAT: “El tráfico entre prefijos protegidos A y B no se NATea.” (Ese es el valor por defecto que quieres).
2. Implementa las exenciones de NAT antes de las reglas generales de mascarada hacia Internet.
3. Si debes NATear a través del túnel (solapamientos, limitación de un proveedor), haz NAT de forma consistente y documenta los rangos mapeados.

Lista de verificación 4: Haz la MTU aburrida

1. Mide la PMTU a través del túnel (no adivines).
2. Aplica clamp al MSS de TCP en la interfaz del túnel si ves estancamientos.
3. Permite ICMP “fragmentation needed”—o la PMTU falla y aparecerán agujeros misteriosos.

Lista de verificación 5: Firewalls y estado

1. Confirma que ambos lados permitan:
   • IKE (UDP 500)
   • NAT-T (UDP 4500) si hay NAT en el camino
   • ESP (IP proto 50) si no usas NAT-T
2. Confirma que la política para las subredes protegidas sea simétrica (en ambos sentidos).
3. En firewalls stateful, confirma que el tráfico de retorno vuelva a entrar por el mismo camino lógico; si no, diseña en torno a ello.

Lista de verificación 6: Observabilidad que detecta tráfico unidireccional temprano

1. Monitorea el estado del túnel y el plano de datos: bytes/paquetes, descartes y contadores por selector.
2. Ejecuta sondas sintéticas en ambas direcciones (ICMP + TCP).
3. Registra cambios clave de enrutamiento (sesiones BGP, diferencias en tablas de rutas) alrededor de ventanas de incidentes.

Tareas prácticas con comandos: salidas, significado y decisiones

A continuación hay tareas probadas en campo que puedes ejecutar en gateways VPN y routers Linux típicos. Cada tarea incluye: comando, qué significa la salida y la decisión que tomas.

Tarea 1: Confirma la ruta del kernel al subred remota (Linux)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 via 169.254.100.2 dev vti0 src 10.10.10.1 uid 0
    cache

Significado: El sistema enviará paquetes a 10.20.30.40 a través de vti0 (túnel basado en rutas) vía la IP del par VTI.

Decisión: Si esto no apunta a la interfaz del túnel (o apunta a la pasarela por defecto/Internet), arregla el enrutamiento antes de tocar configuraciones de IPsec.

Tarea 2: Muestra la tabla de rutas y detecta rutas ocultas

cr0x@server:~$ ip route show table main
default via 203.0.113.1 dev eth0
10.10.0.0/16 dev lan0 proto kernel scope link src 10.10.10.1
10.20.0.0/16 via 169.254.100.2 dev vti0 proto static metric 100

Significado: El remoto 10.20.0.0/16 está explícitamente enrutado al túnel; bien. Si solo vieras default via, tendrías una ruleta de rutas de retorno.

Decisión: Si falta el prefijo remoto, añádelo (o arregla el enrutamiento dinámico). Si está presente pero una ruta más amplia gana (métrica incorrecta), corrige métricas/policy routing.

Tarea 3: Verifica que existan SAs de IPsec y que lleven tráfico (strongSwan)

cr0x@server:~$ sudo swanctl --list-sas
vpn-siteA-siteB: #12, ESTABLISHED, IKEv2, rekeying in 2 hours
  local  'gw-siteA' @ 198.51.100.10[4500]
  remote 'gw-siteB' @ 203.0.113.20[4500]
  AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
  CHILD_SA vpn-child{34}:  INSTALLED, TUNNEL, reqid 1
    10.10.0.0/16 === 10.20.0.0/16
    bytes_i 1289021, bytes_o 1401122, packets_i 9801, packets_o 10210

Significado: Las SAs están arriba, y los contadores muestran paquetes entrantes/salientes. Si bytes_i crece pero bytes_o no (o viceversa), tienes un plano de datos unidireccional.

Decisión: Si los contadores SA no se mueven mientras generas tráfico, tus selectores no coinciden o el enrutamiento no envía paquetes a IPsec/VTI.

Tarea 4: Confirma selectores basados en políticas en el kernel (política XFRM)

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

Significado: El kernel cifrará tráfico de 10.10/16 a 10.20/16 saliente, y aceptará tráfico entrante a la inversa.

Decisión: Si falta una dirección o usa CIDR distintos, corrige la política/conexión IPsec. Los selectores desajustados son una clásica causa de “funciona de A a B pero no al revés”.

Tarea 5: Comprueba enrutamiento asimétrico mediante reglas de policy routing

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

Significado: El tráfico originado desde 10.10/16 usa la tabla de enrutamiento 100. Esto puede ser correcto (multi-WAN, VRFs), o una trampa escondida.

Decisión: Si existe policy routing, confirma que los prefijos remotos están en la misma tabla. Si no, el tráfico de retorno podría salir por la interfaz equivocada.

Tarea 6: Inspecciona la tabla 100 para verificar que las rutas remotas también existan allí

cr0x@server:~$ ip route show table 100
default via 198.51.100.1 dev eth1
10.20.0.0/16 via 169.254.100.2 dev vti0 metric 50

Significado: Incluso bajo policy routing, 10.20/16 sigue yendo a vti0. Bien.

Decisión: Si 10.20/16 falta aquí, añádela; de lo contrario algunos flujos irán a Internet y morirán en un firewall stateful o en una ACL del par.

Tarea 7: Revisa rp_filter que descarta tráfico de retorno asimétrico

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

Significado: La validación de origen de tipo estricto está habilitada. Esto puede descartar paquetes legítimos si el enrutamiento es asimétrico o si las rutas de origen aparecen por interfaces distintas.

Decisión: Si tienes multi-homing o policy routing, considera establecer rp_filter=2 (loose) en las interfaces relevantes, pero solo después de entender por qué existe la asimetría.

Tarea 8: Confirma la exención de NAT (iptables) para que el tráfico VPN no se masque

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

Significado: El tráfico de 10.10/16 a 10.20/16 evita NAT; todo lo demás hacia eth0 se masquea.

Decisión: Si falta la regla RETURN o está por debajo de MASQUERADE (el orden importa), arréglalo. NATear tráfico VPN es una forma fácil de crear un “hace ping pero nada más funciona”.

Tarea 9: Confirma el orden NAT en nftables (si usas nft)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.10.0.0/16 ip daddr 10.20.0.0/16 return
    oifname "eth0" ip saddr 10.10.0.0/16 masquerade
  }
}

Significado: La misma idea que iptables: eximir el tráfico VPN primero.

Decisión: Si tu exención falta o es demasiado amplia (devuelve más de lo previsto), aflójala. Las exenciones NAT descuidadas son la forma en que accidentalmente se elude un límite de seguridad.

Tarea 10: Verifica que las reglas de filtrado del firewall permitan las subredes protegidas en ambos sentidos

cr0x@server:~$ sudo iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -i vti0 -o lan0 -s 10.20.0.0/16 -d 10.10.0.0/16 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i lan0 -o vti0 -s 10.10.0.0/16 -d 10.20.0.0/16 -j ACCEPT
-A FORWARD -i vti0 -o lan0 -s 10.20.0.0/16 -d 10.10.0.0/16 -j ACCEPT

Significado: Forwarding es drop por defecto; existen allows explícitos. Observa la regla established/related que ayuda al tráfico de retorno, pero aún necesitas allows simétricos según la política.

Decisión: Si solo se permite una dirección, verás TCP unidireccional (SYN sale, SYN/ACK muere). Corrige la dirección faltante y confirma que el seguimiento de estado vea las interfaces correctas.

Tarea 11: Captura tráfico en LAN y en interfaces de túnel para demostrar dónde muere

cr0x@server:~$ sudo tcpdump -ni lan0 host 10.20.30.40 and '(icmp or tcp)'
14:22:01.112233 IP 10.10.10.50.51522 > 10.20.30.40.443: Flags [S], seq 1234567890, win 64240, options [mss 1460,sackOK,TS val 1 ecr 0], length 0
14:22:02.113344 IP 10.10.10.50.51522 > 10.20.30.40.443: Flags [S], seq 1234567890, win 64240, options [mss 1460,sackOK,TS val 2 ecr 0], length 0

Significado: Los SYNs salen del lado LAN; no hay SYN/ACKs de regreso. Ahora captura en vti0 para ver si entran al túnel.

Decisión: Si los paquetes aparecen en LAN pero no en el túnel, la selección de política/enrutamiento es incorrecta. Si aparecen en el túnel pero no vuelven a LAN, la ruta de retorno/firewall del lado remoto está mal.

Tarea 12: Captura en VTI para confirmar que los paquetes atraviesan el túnel

cr0x@server:~$ sudo tcpdump -ni vti0 host 10.20.30.40 and tcp port 443
14:22:01.112999 IP 10.10.10.50.51522 > 10.20.30.40.443: Flags [S], seq 1234567890, win 64240, options [mss 1360,sackOK,TS val 1 ecr 0], length 0

Significado: El SYN está en el túnel. Observa que el MSS cambió a 1360—alguien está aplicando clamping, lo cual puede ser bueno.

Decisión: Si el paquete está en el túnel, el lado local probablemente está bien; enfócate en la ruta de retorno del gateway remoto, firewall, NAT o mismatch de selectores.

Tarea 13: Revisa PMTU a través del túnel con tracepath

cr0x@server:~$ tracepath -n 10.20.30.40
 1?: [LOCALHOST]                                         pmtu 1500
 1:  169.254.100.2                                        1.023ms
 2:  10.20.30.40                                          2.108ms reached
     Resume: pmtu 1436 hops 2 back 2

Significado: La PMTU descubierta es 1436. Si envías tramas de 1500 bytes sin manejo de fragmentación, algo se convertirá en agujero negro.

Decisión: Si la PMTU es menor a 1500, aplica clamp MSS (Tarea 14) y asegúrate de que ICMP “frag needed” no esté bloqueado.

Tarea 14: Aplica TCP MSS clamping en la interfaz del túnel (Linux, iptables)

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

Significado: Nuevas conexiones TCP que atraviesen vti0 tendrán el MSS ajustado para coincidir con la PMTU, reduciendo problemas de fragmentación.

Decisión: Si los estancamientos TCP desaparecen tras el clamping, has confirmado un problema de MTU/PMTU. Déjalo, y luego corrige el MTU subyacente o el filtrado de ICMP si es posible.

Tarea 15: Verifica accesibilidad IKE/ESP/NAT-T (desde el gateway)

cr0x@server:~$ sudo ss -uapn | egrep ':(500|4500)\b'
UNCONN 0      0           0.0.0.0:500        0.0.0.0:*    users:(("charon",pid=1234,fd=12))
UNCONN 0      0           0.0.0.0:4500       0.0.0.0:*    users:(("charon",pid=1234,fd=13))

Significado: El demonio está escuchando IKE y NAT-T. Si falta 4500 pero hay NAT, puede que negocies mal o falles tras paquetes iniciales.

Decisión: Si los listeners no están presentes, arregla la configuración del servicio. Si están presentes pero no llega tráfico, enfócate en ACLs/upstream o grupos de seguridad.

Tarea 16: Revisa descartes en la interfaz VTI

cr0x@server:~$ ip -s link show dev vti0
10: vti0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
       8821991  82310      0     212       0       0
    TX:  bytes packets errors dropped carrier collsns
       9011122  84100      0       0       0       0

Significado: Existen descartes en RX. Los descartes pueden ser por MTU, firewall, colas o políticas, pero es una señal clara de que los paquetes no atraviesan de forma limpia.

Decisión: Si los descartes aumentan durante las pruebas, correlaciónalos con tcpdump y logs; considera MTU, rate limiting o paquetes mal enroutados que tocan la interfaz equivocada.

Tarea 17: Valida que el reenvío esté habilitado (clásico aún)

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

Significado: La máquina está autorizada a enrutar paquetes. Si es 0, puedes tener un túnel perfecto y un gateway que se comporta como un pisapapeles muy seguro.

Decisión: Si es 0, actívalo y persiste la configuración; luego vuelve a probar los flujos.

Tarea 18: Revisa intercambio de rutas BGP sobre el túnel (FRR)

cr0x@server:~$ sudo vtysh -c "show ip bgp summary"
BGP router identifier 10.10.10.1, local AS number 65010
Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
169.254.100.2   4      65020     10422     10398       77    0    0 2d03h          12

Significado: El vecino BGP sobre el VTI está arriba y recibe prefijos (12). Si está idle/active, aún no tienes simetría de enrutamiento.

Decisión: Si los prefijos recibidos son 0 o inesperados, revisa filtros/route-maps. Si BGP está caído, verifica alcanzabilidad de la interfaz del túnel y firewall en TCP/179.

Tarea 19: Confirma que el prefijo específico está instalado y es preferido (BGP)

cr0x@server:~$ sudo vtysh -c "show ip route 10.20.0.0/16"
Routing entry for 10.20.0.0/16
  Known via "bgp", distance 20, metric 0, best
  * 169.254.100.2, via vti0, weight 1, 2d03h

Significado: El prefijo remoto es el mejor vía el túnel. Si la mejor ruta es vía un next-hop de Internet, has construido una máquina unidireccional.

Decisión: Arregla local preference/métricas, o añade una ruta estática de mayor prioridad hacia el VTI mientras estabilizas la política BGP.

Tarea 20: Verifica que conntrack vea el flujo (problemas en path con firewall stateful)

cr0x@server:~$ sudo conntrack -L | grep "10.10.10.50.*10.20.30.40.*dport=443" | head -n 2
tcp      6 118 SYN_SENT src=10.10.10.50 dst=10.20.30.40 sport=51522 dport=443 [UNREPLIED] src=10.20.30.40 dst=10.10.10.50 sport=443 dport=51522

Significado: La conexión está en SYN_SENT con UNREPLIED. Eso es consistente con respuestas que no regresan (enrutamiento/firewall/selector).

Decisión: Si ves respuestas pero la aplicación sigue fallando, sube en la pila (TLS, ACLs de aplicación). Si no las ves, enfócate en la ruta de retorno y la política del lado remoto.

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

1) Síntoma: “Ping funciona A→B, pero B→A falla”

• Causa raíz: la ruta de retorno en el Lado B apunta a una pasarela distinta (a menudo una ruta por defecto o un segundo WAN), por lo que las respuestas evitan el túnel.
• Solución: instala rutas explícitas para los prefijos protegidos del Lado A vía el túnel/VTI en el Lado B; asegura que las tablas de policy routing también las incluyan. Verifica con ip route get en ambos lados.

2) Síntoma: “El túnel está activo, pero nada pasa; los contadores no se mueven”

• Causa raíz: mismatch de selectores (basado en políticas) o enrutamiento que no envía tráfico al túnel (basado en rutas).
• Solución: alinea los CIDR locales/remotos exactamente en ambos pares; verifica la política XFRM o las rutas VTI existen y coinciden con el tráfico previsto.

3) Síntoma: “Pings pequeños funcionan; HTTPS se cuelga o carga media página”

• Causa raíz: agujero negro MTU/PMTU; ICMP frag-needed bloqueado; segmentos TCP demasiado grandes tras la sobrecarga de encapsulación.
• Solución: mide la PMTU con tracepath; aplica clamp MSS en el túnel; permite ICMP tipo 3 código 4 donde corresponda.

4) Síntoma: “Solo algunas subredes funcionan sobre la VPN”

• Causa raíz: selectores incompletos, rutas estáticas faltantes o filtrado de rutas en BGP/OSPF.
• Solución: audita prefijos de extremo a extremo: anunciados, aceptados, instalados y permitidos por firewall/exenciones NAT. No confíes en “añadimos el /16”. Pruébalo con búsquedas de ruta.

5) Síntoma: “Funciona un tiempo, luego unidireccional tras un failover”

• Causa raíz: el failover del HA cambia la IP de origen, rompe selectores o desplaza el tráfico de retorno a otra interfaz. Conntrack se pierde o queda desincronizado.
• Solución: asegura endpoints de túnel estables (VIPs), reglas de enrutamiento y NAT consistentes entre nodos HA, y prueba failover con sondas bidireccionales.

6) Síntoma: “BGP dice que se reciben prefijos, pero el tráfico sigue unidireccional”

• Causa raíz: las rutas están instaladas, pero hay asimetría por otra ruta preferida de retorno, o rp_filter descarta paquetes que llegan por una interfaz inesperada.
• Solución: compara decisiones de enrutamiento con ip route get en ambos lados; ajusta local preference/métricas; configura rp_filter según el diseño.

7) Síntoma: “Solo UDP funciona; TCP es inestable”

• Causa raíz: MTU/MSS y sensibilidad a retransmisiones; o firewall stateful con ruta de retorno asimétrica.
• Solución: clamp MSS, confirma enrutamiento simétrico y valida que conntrack vea ambos sentidos consistentemente.

8) Síntoma: “El tráfico entra al túnel pero el host remoto nunca lo ve”

• Causa raíz: el lado remoto enruta tráfico al túnel pero carece de enrutamiento interno hacia el host destino, o el firewall remoto bloquea tras la desencapsulación.
• Solución: haz traceroute desde el gateway remoto hasta el host interno; asegura que los routers internos conozcan la ruta de retorno hacia los prefijos protegidos por la VPN; corrige políticas de segmentación.

Tres microhistorias corporativas (cómo falla esto en la vida real)

Microhistoria #1: El incidente causado por una suposición incorrecta

Dos unidades de negocio fusionaron redes sin fusionar opiniones. Un equipo gestionaba el firewall/VPN on-prem; el otro controlaba una VPC en la nube. Acordaron un túnel IPsec sitio a sitio y declararon victoria cuando la UI dijo “Connected”.

La suposición equivocada fue sutil: el equipo de la nube asumió “las rutas se propagan automáticamente porque el túnel está activo”. El equipo on-prem asumió “la nube siempre tiene una ruta de retorno porque es la nube”. Ninguna de las dos suposiciones fue probada con un flujo bidireccional.

El tráfico de ida desde on-prem hacia la nube funcionó porque on-prem tenía rutas estáticas explícitas a los CIDR de la nube. El tráfico de retorno falló porque el lado cloud tenía la conexión VPN pero la tabla de rutas asociada a la subred de workloads no incluía los CIDR on-prem. Algunas subredes usaban otra tabla de rutas completamente distinta, así que una app funcionó y otra no. Ese “éxito parcial” les costó un día completo de confusión.

Arreglarlo fue aburrido: asociar la tabla de rutas correcta a las subredes correctas, añadir las rutas faltantes y luego ejecutar las mismas dos pruebas cada vez: ICMP y TCP desde ambas direcciones. La mejora duradera fue cultural: añadieron “probar ruta de retorno” como casilla en el control de cambios, no como memoria tribal.

Microhistoria #2: La optimización que salió mal

Un equipo de red quería convergencia más rápida y menos elementos móviles. Reemplazaron un par de rutas estáticas por BGP sobre el túnel IPsec. Inteligente. También ajustaron BGP para preferir un circuito secundario de Internet como “respaldo”, usando local preference y un route-map que se veía elegante en la revisión.

Entonces un mantenimiento no relacionado volteó cuál circuito era “primario”. BGP reconvergió exactamente como estaba configurado, lo cual es el peor tipo de correcto: prefirió el circuito secundario para algunos prefijos, pero el endpoint IPsec seguía ligado a la IP pública del circuito primario. El plano de datos se volvió asimétrico: el tráfico saliente entró al túnel; el tráfico de retorno fue atraído hacia la otra salida porque el route-map lo indicaba.

Los usuarios lo reportaron como “timeouts aleatorios”. El monitoreo mostraba el túnel activo y BGP establecido. Las capturas de paquetes dijeron la verdad: los SYN salían, los SYN/ACKs volvían por la interfaz equivocada y eran descartados por reglas stateful y rp_filter. La “optimización” no fue BGP; fue asumir que la preferencia del plano de control siempre implica simetría en el plano de datos.

La solución fue hacer el diseño explícito: ligar los next-hops BGP a la interfaz del túnel (VTI), no a un camino dependiente del WAN; usar policy routing consistente; y probar failover como escenario de primera clase. Mantuvieron BGP, pero dejaron de tratarlo como magia.

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

Una empresa con múltiples sedes tenía una regla: cada cambio en VPN incluye una captura antes/después de tres cosas—rutas, reglas NAT y resultado de una sonda bidireccional. Sin excepciones. Los ingenieros rodaron los ojos, porque los ingenieros ganan parte de su sueldo en rodar los ojos.

Durante una actualización rutinaria del firewall, una nueva regla NAT por defecto se introdujo más arriba en el orden. El túnel se mantuvo activo y los pings básicos desde el firewall funcionaron. Pero el tráfico de aplicaciones desde la LAN empezó a fallar de una forma que parecía una caída remota.

El ticket de cambio contenía las capturas. Comparar las tablas NAT hizo evidente el problema: el tráfico VPN ahora se estaba mascarando, rompiendo selectores en el extremo contrario y confundiendo el enrutamiento de retorno. Revirtieron el orden de reglas en minutos y luego reintrodujeron la regla con una exención NAT colocada correctamente. El incidente nunca se convirtió en una caída mayor porque los artefactos de diagnóstico ya estaban allí.

Práctica aburrida, gran recompensa. El secreto no es genialidad; es repetibilidad. Tu yo futuro no recordará esa regla NAT especial que “definitivamente” no vas a olvidar.

Chiste #2: Si quieres encontrar tu regla NAT oculta, programa una ventana de mantenimiento—las reglas NAT adoran la atención y aparecerán de inmediato.

Hechos interesantes y breve historia (contexto que previene errores)

• Hecho 1: Los estándares centrales de IPsec se originaron en los años 90, y el diseño lo refleja: es potente, flexible y alérgico a una resolución de problemas simple.
• Hecho 2: ESP (Encapsulating Security Payload) es el protocolo IP 50, no un puerto TCP/UDP—así que “abrir puertos” es insuficiente si no usas NAT-T.
• Hecho 3: NAT-T (UDP 4500) se volvió común porque NAT rompe las suposiciones clásicas de IPsec; encapsular ESP en UDP hizo que IPsec sobreviva en el Internet moderno.
• Hecho 4: Las VPN basadas en políticas (selectores/ACLs definen qué se cifra) fueron comunes históricamente en firewalls; las VPN basadas en rutas (VTI) se popularizaron a medida que las redes exigieron enrutamiento dinámico y operaciones más claras.
• Hecho 5: El descubrimiento de Path MTU depende de ICMP. Bloquear ICMP completamente es el equivalente operacional de quitar las señales de tráfico y sorprenderse por atascos.
• Hecho 6: Las comprobaciones de “túnel activo” a menudo validan solo la negociación IKE, no que los selectores coincidan o que existan rutas; por eso las sondas sintéticas importan.
• Hecho 7: El enrutamiento asimétrico no es inherentemente incorrecto. Se vuelve problemático cuando introduces firewalls stateful, conntrack, rp_filter o supuestos estrictos anti-spoofing.
• Hecho 8: Las redes RFC1918 superpuestas (10/8, 172.16/12, 192.168/16) son una causa principal de “NAT temporal” a través de VPNs—que luego se vuelve arquitectura permanente por inercia.
• Hecho 9: Las VPNs en la nube frecuentemente tienen conceptos separados para “attachment del túnel” y “asociación de tabla de rutas”. La gente configura uno y olvida el otro, luego se pregunta por qué el tráfico de retorno desaparece.

Preguntas frecuentes

1) ¿Por qué ocurre tráfico unidireccional si la Fase 2 está establecida?

Porque Fase 2 establecida significa que existen SAs, no que los paquetes coincidan con los selectores, no que las rutas envíen paquetes al túnel y no que existan rutas de retorno.

2) ¿Debo preferir VPN basada en rutas (VTI) o basada en políticas?

Prefiere basada en rutas (VTI) cuando puedas. Se alinea con cómo funciona realmente el enrutamiento, soporta enrutamiento dinámico limpiamente y es más sencilla de observar y razonar.

3) ¿Cómo pruebo rápidamente que es enrutamiento y no “la VPN”?

Ejecuta ip route get para el host remoto en ambos gateways y captura paquetes en interfaces LAN y de túnel con tcpdump. Si los paquetes no entran al túnel, es selección de política/enrutamiento. Si entran pero no regresan, es ruta de retorno o firewall/NAT remoto.

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

Los problemas MTU/PMTU y el bloqueo de mensajes ICMP frag-needed son comunes. Además, algunos entornos priorizan o limitan ICMP de forma distinta a TCP. Mide PMTU con tracepath y aplica clamp MSS si es necesario.

5) ¿Necesito permitir ICMP a través de los firewalls para las VPNs?

Deberías permitir los tipos de ICMP necesarios para PMTU discovery a lo largo del camino, especialmente “fragmentation needed”. Bloquear ICMP a lo bruto es como crear agujeros silenciosos y llamadas de incidente largas.

6) ¿Cuál es la forma más rápida de detectar enrutamiento asimétrico?

Compara traceroutes y búsquedas de ruta desde ambos lados. También revisa estados de conntrack: un montón de SYN_SENT [UNREPLIED] es una pista fuerte de que las respuestas no regresan por la misma vía.

7) ¿Cómo provocan tráfico unidireccional las subredes superpuestas?

Si ambos lados usan el mismo rango RFC1918, cada lado puede considerar el destino “local” y hacer ARP en vez de enrutar al túnel. O gana la ruta equivocada. Si renumerar no es posible, usa NAT explícito a través del túnel y documéntalo agresivamente.

8) ¿NAT-T siempre indica que hay NAT en el camino?

No siempre. Algunas implementaciones usan encapsulación UDP por política para compatibilidad. Pero si hay NAT y no usas NAT-T, espera problemas: ESP no se lleva bien con traducción de direcciones.

9) ¿Puede rp_filter romper tráfico VPN?

Sí. Si los paquetes llegan por una interfaz que el kernel no considera la mejor ruta inversa para la fuente, rp_filter puede descartarlos. En diseños multi-WAN o con policy-routing, rp_filter estricto es una frecuente auto-saboteo.

10) ¿Qué debo monitorizar para detectar temprano problemas unidireccionales?

Monitorea contadores de bytes/paquetes por CHILD SA, descartes de interfaces y sondas sintéticas bidireccionales (ICMP + TCP). “Túnel activo” por sí solo es una métrica reconfortante, no una métrica de disponibilidad.

Conclusión: siguientes pasos que realmente evitan recurrencias

Si quieres evitar que el tráfico unidireccional vuelva como una alergia estacional, haz estos siguientes pasos:

1. Escribe el dominio de cifrado (CIDR exactos, ambos lados). Trátalo como un contrato API. Los contratos no “más o menos coinciden”.
2. Demuestra enrutamiento simétrico con ip route get en ambos gateways para algunos hosts representativos. Guarda las salidas en el registro de cambios.
3. Haz el NAT explícito: añade exenciones VPN por encima de las reglas de mascarada y revísalas cada vez que alguien toque el egress de Internet.
4. Haz la MTU aburrida: mide PMTU, aplica clamp MSS si es necesario y deja de bloquear el ICMP del que dependes.
5. Automatiza sondas bidireccionales para detectar “túnel activo, tráfico muerto” en minutos, no por un ticket días después.
6. Prueba failover como si fuera parte del sistema, porque lo es. La mayoría de incidentes unidireccionales son historias de “funciona hasta que algo cambia”.

Haz la lista de verificación de enrutamiento primero. No es glamorosa, pero es cómo obtienes una VPN que se comporta como una red, no como una casa encantada.