VPN basada en rutas vs basada en políticas: cuál es mejor para oficinas y por qué

Qué son en realidad las VPN basadas en rutas y en políticas

VPN basada en políticas: “coincidir el tráfico y luego cifrarlo”

Una VPN basada en políticas suele ser un túnel IPsec donde el firewall utiliza selectores (a menudo llamados “proxy IDs” o “traffic selectors”)
para decidir qué se cifra: subred(es) de origen, subred(es) de destino, a veces puertos/protocolos.
Si el tráfico coincide con la política, entra en el túnel; si no, no entra.

El modelo mental es: la política de seguridad guía el reenvío. El enrutamiento sigue existiendo, pero no es el punto de decisión principal.
En muchos dispositivos, las VPN basadas en políticas se sienten como escribir ACLs que, de paso, cifran.

Por eso las VPN basadas en políticas son comunes en equipos antiguos y en firewalls “de nivel SMB”: son fáciles de explicar y rápidas de desplegar
para un subnet a otro. El precio se paga más tarde, con intereses.

VPN basada en rutas: “crea una interfaz y luego enruta hacia ella”

Las VPN basadas en rutas crean una interfaz de túnel lógica (a menudo VTI: Virtual Tunnel Interface) y dejan que tu tabla de enrutamiento decida qué debe
ir por el túnel. El cifrado ocurre para lo que se enruta a través de esa interfaz (además de lo que permita tu política IPsec, pero la idea es:
lo diseñas como una red, no como un montón de casos especiales).

El modelo mental es: el enrutamiento guía el reenvío; la política de seguridad controla el permiso. Esa separación es oro en operaciones.
Significa que puedes hacer cosas normales: enrutamiento dinámico (BGP/OSPF), conmutación por error en rutas, múltiples subredes sin explosión combinatoria,
y una solución de problemas sensata (“¿qué ruta escogimos?” es mejor pregunta que “¿cuál de los 37 selectores coincidió?”).

Qué quieren decir las personas (y dónde se confunden)

Los proveedores no son consistentes con la terminología. Algunas cajas dicen “basada en rutas” pero aun así requieren selectores; otras implementan
“basada en políticas” pero te permiten enlazarla a un objeto tipo túnel. No discutas etiquetas. Discute estas propiedades:

• ¿Hay una interfaz de túnel real con dirección IP? (A menudo sí para basada en rutas, no para puramente basada en políticas.)
• ¿Puedes instalar rutas (estáticas o dinámicas) apuntando al túnel?
• ¿Necesitas enumerar cada par de subred local/remota? (La basada en políticas tiende a hacerlo.)
• ¿Puedes ejecutar BGP sobre él? (La basada en rutas suele hacerlo más sencillo.)
• ¿Cómo se comporta la conmutación por error? (La basada en rutas puede ser limpia; la basada en políticas puede ser “sorprendente”.)

Una cita que vale la pena tener en la pared, porque resume el trabajo en una frase:
“La esperanza no es una estrategia.” — Gene Kranz

Las VPN basadas en políticas funcionan con esperanza más a menudo de lo que los equipos admiten. Funcionan hasta que llega una nueva subred, o hasta que alguien pide active/active,
o hasta que el equipo de la nube quiere BGP. Entonces los selectores se convierten en un montón frágil de suposiciones.

Realidad de la oficina: qué lo cambia todo

Las oficinas son desordenadas. Crecen lateralmente. Heredan VLANs de impresoras de 2014 y diseños de Wi‑Fi de invitados de 2017 y una subred “temporal”
añadida para un contratista que nunca se fue. El diseño de VPN que sobrevive en un entorno de oficina necesita manejar:

• Muchas subredes por sitio (usuarios, voz, cámaras, IoT, servidores, invitados, OT).
• Cambios frecuentes (nuevas salidas a SaaS, nuevo DNS, nuevas excepciones de split-tunnel).
• Adquisiciones (solapamiento de espacio RFC1918 no es un problema teórico; es un evento en el calendario).
• Múltiples upstreams (ISPs duales, respaldo LTE, underlays SD-WAN).
• Vendedores mixtos (porque, por supuesto, en un extremo hay un Forti y en el otro un Palo, con NAT “útil” en el medio).
• Presión de la política de seguridad (segmentación tipo zero trust, auditoría, MFA para acceso administrativo y “bloquear todo por defecto”).

La cuestión central no es “cuál VPN es más segura.” Ambas pueden ser seguras. La pregunta es: ¿qué modelo falla de forma predecible y diagnosticable cuando la oficina cambia?
Porque la oficina cambiará. Siempre cambia.

Cuál es mejor para oficinas (y las excepciones)

Recomendación por defecto: basada en rutas para casi todas las VPN oficina-a-oficina y oficina-a-datacenter

Para oficinas, gana la basada en rutas a largo plazo porque se alinea con cómo se operan realmente las redes:
añades rutas, monitorizas rutas, conmutas por error rutas, resumes prefijos, depuras rutas. No quieres que la alcanzabilidad VPN
dependa de una matriz de selectores que solo un ingeniero entiende y que nadie quiere tocar un viernes.

Las VPN basadas en rutas también encajan mejor con necesidades del mundo real:

• Enrutamiento dinámico (especialmente BGP) para muchos sitios, interconexiones a la nube y lógica de conmutación por error.
• Múltiples subredes sin explosión de selectores (un túnel, muchas rutas).
• HA más limpia (rastrear interfaz de túnel, sesión BGP, retirar rutas).
• Gestión de cambios menos frágil (añadir una subred se convierte en “añadir ruta + regla de firewall”, no en “añadir N selectores”).

Cuándo la basada en políticas sigue siendo aceptable

La basada en políticas es aceptable cuando:

• Es realmente pequeña: una subred a otra (o pocas), y no va a crecer.
• El dispositivo no soporta VTI/basada en rutas correctamente (común en hardware antiguo/de gama baja).
• Necesitas decisiones de cifrado por aplicación/puerto y la plataforma lo hace de forma limpia (raro, pero posible).
• Estás integrando con un socio que insiste en selectores estrictos y no ejecutará enrutamiento dinámico.

Pero entiende en qué te estás metiendo: cada nueva subred es un cambio de política. Cada cambio de política es una oportunidad para romper cosas de
una forma que no aparece en las comprobaciones de “túnel activo”.

Dónde los equipos se queman: “túnel activo” no es “el tráfico funciona”

A las VPN basadas en políticas les encanta mostrar luces verdes: IKE está arriba, IPsec está arriba, bytes se mueven. Mientras tanto, la nueva VLAN no puede
alcanzar nada porque sus selectores nunca se añadieron, o porque NAT se coló y cambió la IP de origen, o porque el extremo remoto es estricto y descarta silenciosamente
tráfico que no coincide.

Los diseños basados en rutas también pueden fallar, pero fallan como fallan las redes: ruta equivocada, ruta ausente, enrutamiento asimétrico, problemas de MTU,
regla de firewall. Esos se resuelven a las 2 a. m. con un terminal y un pulso.

Broma #1: Una VPN basada en políticas es como una lista VIP. Funciona de maravilla hasta que tu empresa sigue contratando gente.

Qué significa “mejor” operacionalmente

En entornos de oficina, “mejor” no es elegancia. Es tiempo medio para restaurar, radio de impacto y cuántas cosas pueden cambiar con seguridad.
La basada en rutas tiende a ganar en:

• Observabilidad: tablas de rutas, estadísticas de interfaz, estado BGP, herramientas estándar.
• Seguridad en cambios: diffs más pequeños, menos condiciones acopladas.
• Escalabilidad: añadir sitios/subredes no multiplica objetos de configuración en ambos extremos.
• Interoperabilidad: las nubes y los firewalls modernos asumen cada vez más patrones basados en rutas.

Matriz de decisión: elige en 5 minutos

Elige basada en rutas si cualquiera de estas es cierta

• Tienes más de dos subredes en cualquiera de los sitios, o esperas tenerlo dentro de un año.
• Necesitas conmutación por error que no sea una cara o cruz (ISP dual, hubs duales, active/active).
• Quieres BGP (o podrías quererlo más adelante).
• Tienes VPNs en la nube en la mezcla (la mayoría de puertas de enlace de nube son centradas en rutas).
• Necesitas resumir rutas o tratar con subredes solapadas mediante NAT.
• Quieres solucionar problemas con herramientas normales: rutas, ping, tcpdump, contadores.

Elige basada en políticas si todas estas son ciertas

• Es un enlace pequeño, estable y estático de subred a subred.
• No hay enrutamiento dinámico. No hay complejidad HA. No hay expectativas de crecimiento.
• La implementación basada en rutas de la plataforma es débil o no está disponible.
• Puedes documentar selectores y mantenerlos sincronizados en ambos extremos.

Elige “basada en rutas, pero con guardarraíles” para la mayoría de oficinas

Las mejores VPN de oficina son basadas en rutas más disciplina:
prefijos permitidos explícitos, filtros de rutas, valores sensatos en MTU/MSS y monitorización que trate el túnel como un enlace WAN.
Estás construyendo una red, no un portal mágico.

Datos interesantes y contexto para repetir en reuniones

1. IPsec empezó como capa de seguridad para IPv6 en los años 90, luego se desplegó ampliamente para IPv4 porque la realidad siempre gana.
2. “Proxy IDs” vienen de ideas tempranas de selectores IPsec: definir exactamente qué tráfico debe protegerse, lo que encaja con la era subnet-a-subnet.
3. Las Virtual Tunnel Interfaces (VTI) se popularizaron cuando los proveedores se dieron cuenta de que los operadores querían que IPsec se comportara como GRE: una interfaz sobre la que enrutar.
4. IKEv2 (estandarizado en 2005) limpió muchas de las aristas de IKEv1, especialmente en negociación y resiliencia.
5. NAT-Traversal existe porque internet es desordenado: la encapsulación UDP (típicamente 4500) fue una solución pragmática para dispositivos NAT que rompían IPsec.
6. Los productos VPN en la nube impulsaron la adopción basada en rutas porque las nubes quieren tablas de rutas y enrutamiento dinámico, no hojas de cálculo de selectores.
7. SD-WAN aceleró la mentalidad de “túnel como interfaz”: los underlays cambian, los overlays enrutan; los selectores basados en políticas no se adaptan bien.
8. Basada en rutas no significa automáticamente “any-to-any”: todavía necesitas política de firewall y filtros de rutas. La diferencia es que puedes gestionarlos por separado.

Tres microhistorias corporativas desde el terreno

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

Una empresa mediana tenía una VPN sitio-a-sitio basada en políticas entre la sede y una sucursal. Había sido estable durante años: un /24 en la sucursal,
un par de /24 en la sede. Luces verdes por todas partes. Nadie la tocaba.

Entonces la sucursal añadió una segunda VLAN para teléfonos VoIP. El ingeniero de red añadió la VLAN en el firewall de la sucursal, añadió DHCP
y supuso “la VPN la llevará porque es el mismo túnel”. Esa suposición es cómo nacen las interrupciones.

¿Los teléfonos se registraron en la PBX local? Bien. ¿Los teléfonos alcanzando el gestor de llamadas centralizado en la sede? Muertos. Mientras tanto, la VPN seguía mostrando “arriba”
porque las subredes existentes seguían coincidiendo con los selectores y mantenían el tráfico fluyendo. La monitorización no lo detectó porque las comprobaciones eran un ping desde
la subred antigua.

La solución fue añadir nuevos selectores (proxy IDs) en ambos extremos, además de reglas de firewall. La lección no fue “basada en políticas es mala”.
La lección fue: las VPN basadas en políticas hacen que la alcanzabilidad sea opt-in por par de subred, por lo que el modo de fallo por defecto es una interrupción parcial silenciosa.

Después de eso, la empresa migró a túneles basados en rutas para sucursales. El mismo cambio hoy es: añadir VLAN, anunciar ruta, añadir regla de firewall. Monitorización con pings
desde múltiples VLANs, no una “subred heredada buena”.

Microhistoria #2: la optimización que se volvió en contra

Otra organización quiso “optimizar” su VPN estrechando selectores para reducir “encriptación innecesaria”.
Tenían un túnel basado en políticas con muchos pares de subred y alguien decidió eliminar selectores amplios y conservar solo los “activos”.
En papel redujo el desorden de configuración.

Dos meses después, un equipo de aplicaciones reinició un servicio en una subred DR que no se había usado recientemente. El tráfico partió desde un prefijo fuente diferente,
aún válido y esperado. Ya no coincidía con ningún selector, así que el firewall lo envió en claro por la ruta con salida a internet, donde las ACL upstream lo bloquearon.
El túnel siguió arriba. Los logs estaban ruidosos pero no eran obvios.

La interrupción duró más de lo que debería porque la gente persiguió la capa equivocada: logs de aplicación, DNS, luego reglas de firewall, luego ISP.
Solo más tarde alguien comparó capturas de paquetes y notó que el tráfico no entraba en IPsec en absoluto.

La solución fue restaurar selectores, y más tarde rediseñar a basada en rutas con filtros de rutas y segmentación adecuada. La “optimización”
fue en realidad una codificación rígida de suposiciones. El cifrado debería ser una propiedad del camino, no una lista frágil de excepciones.

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

Una empresa con más de 40 oficinas ejecutaba IPsec basado en rutas con BGP hacia dos hubs regionales. Nada fancy. La parte “aburrida” era su disciplina de cambios:
cada oficina tenía un plan de prefijos estándar, filtros de rutas y una lista de pruebas previas al cambio que incluía comprobaciones de MTU y alcanzabilidad por VLAN.

Un día una actualización del firewall del hub introdujo un comportamiento diferente en el clamp por defecto del TCP MSS. De repente, las transferencias de archivos desde algunas oficinas se ralentizaron.
La latencia parecía bien; los pings funcionaban; las solicitudes HTTP pequeñas funcionaban. Las copias SMB grandes eran terribles.

Su runbook requería una rápida comprobación de PMTU y una revisión de contadores de la interfaz IPsec. En minutos vieron fragmentación y retransmisiones.
Ajustaron el clamp MSS en las interfaces de túnel del hub y confirmaron la mejora. No hubo escalada al proveedor. No hubo señalar con el dedo al ISP.

La práctica que los salvó no fue un truco ingenioso. Fue estandarización + pruebas repetibles + visibilidad de enrutamiento.
Cuando tu VPN se comporta como una interfaz con rutas, es más fácil localizar dónde se puso raro.

Broma #2: La forma más rápida de aprender a depurar VPN es programar un cambio «rápido» en el firewall justo antes de un fin de semana largo.

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

Estas son comprobaciones de nivel operador que puedes ejecutar desde hosts Linux, firewalls que exponen shells o jump boxes cerca de los endpoints.
El punto no es el comando; es lo que decides según la salida.

1) Confirma que existe la ruta que esperas (sanidad basada en rutas)

cr0x@server:~$ ip route get 10.40.12.20
10.40.12.20 via 169.254.21.2 dev vti0 src 169.254.21.1 uid 1000
    cache

Significado: El tráfico hacia 10.40.12.20 saldrá por vti0 vía el siguiente salto del túnel. Bien.
Decisión: Si muestra tu gateway por defecto en su lugar, arregla el enrutamiento (ruta estática, BGP, route-map) antes de tocar IPsec.

2) Comprueba si existen SAs de IPsec y si se re-negocian (ejemplo strongSwan)

cr0x@server:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.8.0, x86_64):
  uptime: 2 hours, since Dec 28 09:11:02 2025
Connections:
 office-hub:  169.254.21.1...203.0.113.10  IKEv2
Security Associations (1 up, 0 connecting):
 office-hub[12]: ESTABLISHED 37 minutes ago, 198.51.100.20[198.51.100.20]...203.0.113.10[203.0.113.10]
 office-hub{7}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c2f4a1d2_i c8a19f10_o
 office-hub{7}:   169.254.21.1/32 === 169.254.21.2/32

Significado: IKEv2 está establecido; ESP está instalado; los selectores son host/32 en los endpoints VTI (patrón típico basado en rutas).
Decisión: Si no hay SAs, céntrate en negociación IKE, PSK/certs, NAT-T y la alcanzabilidad UDP.

3) Verifica que el tráfico realmente se está cifrando (mira las estadísticas XFRM)

cr0x@server:~$ ip -s xfrm state
src 198.51.100.20 dst 203.0.113.10
    proto esp spi 0xc8a19f10 reqid 1 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha256) 0x... 128
    enc cbc(aes) 0x...
    anti-replay context: seq 0x0000007b, oseq 0x0000007b, bitmap 0xffffffff
    stats: replay-window 0 replay 0 failed 0 bytes 981234 packets 812 add 2025-12-28 09:15:01 use 2025-12-28 10:02:31

Significado: Los contadores de paquetes/bytes incrementándose significan que el tráfico pasa por IPsec.
Decisión: Si los contadores se mantienen planos mientras las aplicaciones fallan, tu enrutamiento/política no está dirigiendo tráfico al túnel (o los selectores no coinciden en basada en políticas).

4) Detecta agujeros MTU/PMTU (dolor clásico de VPN de oficina)

cr0x@server:~$ ping -M do -s 1372 10.40.12.20 -c 3
PING 10.40.12.20 (10.40.12.20) 1372(1400) bytes of data.
1380 bytes from 10.40.12.20: icmp_seq=1 ttl=61 time=21.3 ms
1380 bytes from 10.40.12.20: icmp_seq=2 ttl=61 time=21.1 ms
1380 bytes from 10.40.12.20: icmp_seq=3 ttl=61 time=21.2 ms

--- 10.40.12.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Significado: PMTU es al menos ~1400 bytes extremo a extremo. Bien para muchos caminos IPsec.
Decisión: Si ves “Frag needed”, aplica clamp TCP MSS en la interfaz de túnel o reduce MTU. Si ves timeouts solo para paquetes grandes, sospecha de filtrado PMTU.

5) Observa el MTU de ruta con tracepath (encuentra dónde cae)

cr0x@server:~$ tracepath 10.40.12.20
 1?: [LOCALHOST]                      pmtu 1500
 1:  169.254.21.2                                           2.123ms
 2:  10.40.12.20                                           21.004ms reached
     Resume: pmtu 1400 hops 2 back 2

Significado: El PMTU descubierto es 1400. Eso es normal con overhead de ESP.
Decisión: Si reporta pmtu 1500 pero las conexiones TCP grandes se estancan, sospecha que ICMP está bloqueado en algún punto y aplica clamp MSS de todos modos.

6) Confirma que DNS no sea el “fallo de VPN”

cr0x@server:~$ resolvectl query fileserver.corp.example
fileserver.corp.example: 10.40.12.20                         -- link: vti0

-- Information acquired via protocol DNS in 19.9ms.
-- Data is authenticated: no

Significado: El nombre resuelve a la IP remota y el resolvedor lo asocia con el enlace del túnel.
Decisión: Si el DNS apunta a IPs públicas o rangos internos equivocados, arregla split-DNS o reenvío condicional antes de culpar a IPsec.

7) Demuestra que el handshake TCP funciona (o no)

cr0x@server:~$ nc -vz 10.40.12.20 445
Connection to 10.40.12.20 445 port [tcp/microsoft-ds] succeeded!

Significado: VPN y política de firewall permiten SMB a ese host.
Decisión: Si hace time out, decide si es enrutamiento (sin ruta de respuesta), política de firewall (bloqueado) o selectores IPsec (incompatibilidad en basada en políticas).

8) Inspecciona contadores de interfaz por drops en la interfaz de túnel

cr0x@server:~$ ip -s link show dev vti0
6: vti0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> 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
      18922310   152233       0       12       0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
      20100291   160112       0        0       0       0

Significado: Drops en RX sugieren problemas de cola/MTU/política, o manejo kernel/xfrm con problemas.
Decisión: Si los drops suben durante transferencias, céntrate en MTU/MSS y CPU; si los drops son cero pero la app falla, mira la política de firewall o el host remoto.

9) Valida la vecindad BGP sobre el túnel (jugada potente de basada en rutas)

cr0x@server:~$ sudo vtysh -c "show ip bgp summary"
BGP router identifier 169.254.21.1, local AS number 65010
Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
169.254.21.2    4      65000    8123    7991      144    0    0 03:12:44        37

Significado: BGP está arriba desde hace horas y recibe 37 prefijos. Así es como “se ve” una VPN guiada por enrutamiento.
Decisión: Si BGP flapea, trata el túnel como un enlace WAN: comprueba pérdida en underlay, MTU, timers DPD y CPU antes de tocar filtros de rutas.

10) Detecta fugas de rutas o rutas faltantes (lo que anuncias importa)

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

Significado: El prefijo existe y es alcanzable vía el túnel.
Decisión: Si la ruta falta, detente. No depures IPsec. Arregla primero la publicidad/importación de rutas.

11) Confirma que los selectores basados en políticas coinciden (depuración genérica vía captura)

cr0x@server:~$ sudo tcpdump -ni eth0 host 203.0.113.10 and udp port 4500 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:04:11.201122 IP 198.51.100.20.4500 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc8a19f10,seq=0x0000007c), length 148
10:04:11.221009 IP 203.0.113.10.4500 > 198.51.100.20.4500: UDP-encap: ESP(spi=0xc2f4a1d2,seq=0x00000080), length 148

Significado: Estás viendo ESP-in-UDP. Si generas tráfico de prueba y no ves paquetes ESP, no está entrando en IPsec.
Decisión: En configuraciones basadas en políticas, eso suele significar incompatibilidad de selectores o que NAT cambió las direcciones internas.

12) Revisa conntrack por síntomas de enrutamiento asimétrico

cr0x@server:~$ sudo conntrack -L -p tcp --dport 445 | head
tcp      6 431999 ESTABLISHED src=10.20.5.44 dst=10.40.12.20 sport=51234 dport=445 src=10.40.12.20 dst=10.20.5.44 sport=445 dport=51234 [ASSURED] mark=0 use=1

Significado: El flujo está establecido en ambas direcciones; se observa tráfico de retorno.
Decisión: Si ves muchos SYN_SENT sin respuesta, sospecha ruta de retorno faltante en el lado remoto o regla de firewall que bloquee.

13) Verifica que NAT no esté saboteando tus selectores

cr0x@server:~$ sudo iptables -t nat -S | sed -n '1,20p'
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -o eth0 -j MASQUERADE

Significado: Una regla MASQUERADE amplia puede reescribir IPs de origen, rompiendo selectores basados en políticas y confundiendo la depuración basada en rutas.
Decisión: Añade exenciones de NAT para destinos VPN o estrecha el alcance del NAT a “internet solamente”.

14) Observa CPU y softirqs durante quejas de rendimiento (el cifrado cuesta ciclos)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (vpn-gw1) 	12/28/2025 	_x86_64_	(8 CPU)

10:06:31 AM  CPU   %usr   %nice %sys %iowait  %irq %soft  %steal  %idle
10:06:32 AM  all   12.10   0.00  9.88   0.00  0.00  21.44    0.00  56.58
10:06:33 AM  all   10.34   0.00  8.91   0.00  0.00  24.10    0.00  56.65
10:06:34 AM  all   11.02   0.00  9.33   0.00  0.00  25.89    0.00  53.76

Significado: Un %soft alto puede indicar presión de procesamiento de paquetes (a menudo VPN + NAT + firewalling).
Decisión: Si la CPU está al máximo durante horas laborales, necesitas aceleración criptográfica por hardware, mejor dimensionamiento o ingeniería de tráfico.

15) Mide el rendimiento con iperf3 (deja de adivinar)

cr0x@server:~$ iperf3 -c 10.40.12.20 -t 10 -P 4
Connecting to host 10.40.12.20, port 5201
[SUM]   0.00-10.00  sec   842 MBytes   707 Mbits/sec  sender
[SUM]   0.00-10.00  sec   839 MBytes   704 Mbits/sec  receiver

Significado: Tienes ~700 Mbps de rendimiento real a través del túnel en condiciones de prueba.
Decisión: Si el rendimiento es bajo pero la latencia es buena, céntrate en MTU/MSS, CPU de crypto o políticas de shaping/policing en el underlay.

16) Confirma comportamiento DPD/keepalive en logs (estabilidad del túnel)

cr0x@server:~$ sudo journalctl -u strongswan --since "10 minutes ago" | tail -n 8
Dec 28 10:00:01 vpn-gw1 charon[1123]: 12[IKE] sending DPD request
Dec 28 10:00:01 vpn-gw1 charon[1123]: 12[IKE] received DPD response, peer alive
Dec 28 10:05:01 vpn-gw1 charon[1123]: 12[IKE] sending DPD request
Dec 28 10:05:01 vpn-gw1 charon[1123]: 12[IKE] received DPD response, peer alive

Significado: El peer responde. El camino underlay no está muerto y el estado se mantiene.
Decisión: Si DPD falla de forma intermitente, sospecha pérdida del ISP, timeouts de mapeo NAT o timeouts UDP agresivos en firewalls aguas arriba.

Guion de diagnóstico rápido

La forma más rápida de perder horas es empezar por el medio. Empieza en los bordes y sigue el paquete.
Cuando alguien dice “la VPN va lenta” o “el sitio está caído”, ejecuta esto en orden.

Primero: ¿es el problema enrutamiento, cifrado o política?

1. Comprueba la ruta desde un host cerca del origen:
   ip route get <remote_ip>.
   Si no apunta al túnel/VTI, para y arregla el enrutamiento.
2. Comprueba estado de SA y contadores:
   ¿IKE establecido? ¿ESP instalado? ¿Aumentan bytes/paquetes cuando generas tráfico?
   Si las SAs están abajo, arregla IKE/underlay. Si las SAs están arriba pero contadores planos, es steering/selectores.
3. Comprueba la política de firewall en el camino de datos:
   ¿puedes hacer nc -vz al puerto? Si no, verifica reglas y rutas de retorno.

Segundo: aisla “funciona con ping” de “funciona con tráfico real”

1. Prueba PMTU con ping -M do y tracepath. Si los paquetes grandes fallan, aplica clamp MSS o baja MTU.
2. Prueba de rendimiento con iperf3. Si está muy por debajo de la capacidad del circuito, revisa CPU, softirqs y shaping.
3. Captura de paquetes en la interfaz pública: ¿ves ESP/UDP 4500 cuando generas tráfico?

Tercero: verifica simetría y ruta de retorno

1. Conntrack o tabla de estado: ¿los flujos llegan a ESTABLISHED o quedan en SYN_SENT?
2. Tabla de rutas del lado remoto: ¿sabe cómo alcanzar tu prefijo de origen vía el túnel?
3. Filtros de rutas (si hay enrutamiento dinámico): ¿bloqueaste accidentalmente el prefijo nuevo?

Identificación rápida del cuello de botella

• Alta latencia + pérdida: ISP del underlay, dispositivo NAT, conmutación LTE, o congestión del proveedor.
• Bajo rendimiento, latencia buena: MTU/MSS, límite CPU de crypto, QoS policing, o limitación por flujo único.
• Una subred funciona, otra no: incompatibilidad de selectores basados en políticas o ruta/anuncio faltante.
• Funciona solo en una dirección: ruta de retorno faltante, enrutamiento asimétrico o caída por firewall stateful.

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

1) “El túnel está arriba, pero la VLAN nueva no llega a la sede”

Síntomas: Subredes existentes funcionan; nueva subred falla; la página de estado VPN está en verde.
Causa raíz: Selectores basados en políticas no actualizados en ambos extremos, o anuncios de rutas no actualizados en basada en rutas.
Corrección: Para basada en políticas: añade selectores locales/remotos que coincidan (proxy IDs) en ambas direcciones y asegura exención de NAT. Para basada en rutas: anuncia o añade rutas estáticas y luego permite en la política de firewall.

2) “Peticiones web pequeñas funcionan, copias de archivos se quedan colgadas”

Síntomas: Ping funciona; RDP funciona; SMB/HTTPS grandes se estancan; retransmisiones en capturas.
Causa raíz: Agujero MTU/PMTU debido al overhead de ESP + ICMP de fragmentación necesario bloqueado.
Corrección: Aplica clamp TCP MSS en las interfaces de túnel; reduce MTU; permite los tipos ICMP necesarios para PMTU en el underlay donde corresponda.

3) “El tráfico funciona horas y luego muere aleatoriamente hasta que rekeye/reinicias”

Síntomas: Cortes intermitentes; logs muestran fallos DPD; a menudo detrás de NAT.
Causa raíz: Timeout de mapeo NAT para UDP 4500/500, o lifetimes desajustados que provocan rekey incómodo.
Corrección: Habilita keepalives NAT-T; alinea lifetimes IKE/ESP; ajusta DPD; asegura que firewalls upstream mantengan mapeos UDP lo suficiente.

4) “Habilitamos active/active y ahora algunas sesiones fallan”

Síntomas: La mitad de los usuarios bien; otros ven resets; tablas de estado inconsistentes.
Causa raíz: Enrutamiento asimétrico entre dos túneles sin sincronización de estado, o ECMP sin consistencia por flujo.
Corrección: Usa hashing por flujo con ruta de retorno consistente, o usa active/passive para servicios stateful; prefiere BGP con atributos y chequeos de salud adecuados.

5) “El VPN del socio solo funciona para una subred; se niegan a añadir más”

Síntomas: Solo un prefijo interno llega al socio; expandir es lento y político.
Causa raíz: El socio usa selectores estrictos basados en políticas y el control de cambios es doloroso.
Corrección: Negocia basada en rutas con VTI si es posible; si no, usa NAT (con cuidado) para mapear múltiples prefijos internos a un selector permitido y documenta como material peligroso.

6) “Después de endurecer NAT, la VPN se rompió”

Síntomas: IKE arriba pero el tráfico no fluye; los selectores parecen correctos.
Causa raíz: Se eliminó exención NAT; la IP de origen cambió; la coincidencia basada en políticas falla o el remoto descarta direcciones internas inesperadas.
Corrección: Añade reglas de bypass NAT explícitas para prefijos remotos; valida con captura que las direcciones internas de origen coincidan con lo que el peer espera.

7) “VPN nube-oficina flapea, on-prem a on-prem es estable”

Síntomas: Rekeys periódicos; resets BGP; el underlay parece bien.
Causa raíz: Expectativas de timers y timeouts de gateway en la nube; a veces DPD agresivo; a veces caminos múltiples con NAT inconsistente.
Corrección: Ajusta timers según recomendaciones de la nube; keepalives; evita doble NAT; verifica estabilidad UDP 4500; considera túneles duales con enrutamiento salud-checado.

8) “VPN va lenta solo en horas punta”

Síntomas: Quejas a 9–11am; picos de CPU; aumentan drops; jitter en VoIP.
Causa raíz: Gateway CPU saturado en crypto o procesamiento de paquetes, o congestión del underlay sin QoS.
Corrección: Dimensiona gateways correctamente, habilita offload por hardware si está disponible, aplica QoS en el underlay y considera dividir tráfico entre túneles/regiones.

Listas de verificación / plan paso a paso

Paso a paso: diseñar una nueva VPN de oficina (camino recomendado)

1. Elige basada en rutas (VTI) a menos que tengas una razón concreta para no hacerlo.
2. Define propiedad de prefijos: bloques resumidos por oficina si puedes (hace el enrutamiento y filtros más sensatos).
3. Decide el enrutamiento:
   • Entorno pequeño: las rutas estáticas están bien, pero mantenlas documentadas y simétricas.
   • Multi-oficina o con mucho uso de nube: ejecuta BGP sobre el túnel. Basada en rutas hace esto limpio.
4. Configura MTU/MSS intencionalmente: no esperes a que SMB te enseñe sobre PMTU en producción.
5. Reglas de firewall: mínimo privilegio, pero sin spaghetti de selectores: permite puertos requeridos entre zonas, registra denegaciones a un ritmo útil.
6. Monitorización: revisa estado IKE/IPsec, presencia de rutas y alcanzabilidad de aplicaciones reales desde más de una VLAN.
7. Diseño de conmutación por error:
   • Preferir túneles duales con salud de enrutamiento (BGP o rutas estáticas con tracking).
   • Haz el fallo explícito: retira rutas cuando el túnel esté poco saludable.
8. Gestión de cambios: define cómo una nueva VLAN se conecta: “añadir prefijo + anunciar + política”. Hazlo un ítem de la lista, no una historia de héroes.

Paso a paso: migrar de basada en políticas a basada en rutas sin drama

1. Inventaría los selectores: lista todos los pares de subred local/remota en uso hoy.
2. Mapea a la intención de enrutamiento: ¿qué prefijos deberían ser realmente alcanzables? ¿Cuáles son legacy y deberían morir?
3. Levanta un túnel paralelo basado en rutas (IP peer diferente o ID de túnel diferente) manteniendo el antiguo.
4. Mueve un prefijo a la vez mediante enrutamiento: instala la ruta vía VTI y elimina el selector para ese prefijo del túnel antiguo solo cuando esté validado.
5. Valida MTU/MSS temprano; las migraciones a basada en rutas suelen exponer pecados antiguos de PMTU.
6. Bloquea filtros de rutas: no crees accidentalmente any-to-any entre oficinas porque “ahora enruta”.
7. Corte el monitoreo al nuevo túnel y luego retira las políticas antiguas.

Checklist operativo: qué verificar después de cualquier cambio en VPN

• IKE establecido y estable (sin rekeys constantes ni fallos DPD).
• Contadores ESP incrementan cuando generas tráfico de prueba.
• Rutas instaladas para todos los prefijos requeridos (y solo esos prefijos).
• Política de firewall permite los puertos necesarios; las denegaciones se registran de forma útil.
• Prueba PMTU en hosts representativos; clamp MSS en su lugar si es necesario.
• Al menos una prueba por VLAN crítica: usuarios, voz y el IoT “raro”.
• Conmutación por error probada: corta el enlace ISP o deshabilita un túnel; confirma que las rutas se retiran y las sesiones se recuperan según diseño.
• Monitorización/alertas actualizadas: no métricas de vanidad “túnel arriba” sin comprobaciones de tráfico.

Preguntas frecuentes

1) ¿Es la VPN basada en rutas más segura que la basada en políticas?

No inherentemente. La seguridad viene de la configuración criptográfica, la gestión de claves y la política de firewall. Basada en rutas suele ser operacionalmente más segura
porque es menos probable que cree conectividad parcial accidental o bypass silencioso durante cambios.

2) ¿Por qué las VPN basadas en políticas causan cortes “funciona para algunas subredes”?

Porque la alcanzabilidad está definida por selectores. Si no incluyes explícitamente un par de subred, el tráfico no se cifrará y puede ser descartado
o filtrado por otra ruta. El túnel puede seguir “arriba” mientras tu red nueva es efectivamente invisible.

3) ¿Pueden las VPN basadas en rutas usar aún selectores de tráfico?

Sí, muchas implementaciones aún negocian selectores, pero en diseños basados en rutas suelen ser estrechos (host-to-host para endpoints VTI) y
el enrutamiento decide qué prefijos internos atraviesan el túnel. El comportamiento operacional es la distinción clave.

4) ¿Necesito BGP para justificar basada en rutas?

No. Las rutas estáticas sobre una VTI siguen siendo más fáciles de razonar que una matriz de selectores, especialmente cuando las oficinas tienen múltiples VLANs.
BGP solo hace que escale y conmute por error con más gracia.

5) ¿Qué pasa con el solapamiento de espacio RFC1918 entre oficinas?

Los solapamientos ocurren durante fusiones y mala planificación. Basada en rutas facilita introducir NAT en el borde de forma controlada y mantener la lógica de enrutamiento explícita.
Basada en políticas también puede hacer NAT, pero depurar se convierte en un rompecabezas lógico que involucra selectores y traducciones.

6) ¿Qué modelo es mejor para conmutación por error con ISP dual?

Basada en rutas, casi siempre. Puedes rastrear el estado de la interfaz de túnel, usar enrutamiento dinámico y retirar rutas de forma limpia. La conmutación por error basada en políticas
suele acabar con políticas duplicadas con pequeños desajustes y sorpresas de “por qué este flujo escogió ese túnel”.

7) ¿Por qué la monitorización “túnel arriba” falla en detectar cortes reales?

Porque la salud del plano de control IKE/IPsec no garantiza la corrección del plano de datos. Puedes tener SAs arriba con rutas equivocadas, selectores incorrectos,
puertos bloqueados, agujeros PMTU o rutas de retorno faltantes. Monitoriza tanto el plano de control como sondas de aplicaciones representativas.

8) ¿Basada en rutas significa que creé accidentalmente acceso full-mesh entre oficinas?

Solo si lo permites. Basada en rutas facilita enrutar muchos prefijos, pero aún aplicas segmentación con filtros de rutas y políticas de firewall.
“Rutea” no significa permiso.

9) ¿Cuál es el killer de rendimiento más común en VPN de oficina?

Problemas de MTU/MSS y límites de CPU. Los problemas de MTU generan retransmisiones y estancamientos que parecen “internet lento”. Los límites de CPU aparecen en horas punta
cuando cifrado y filtrado compiten por ciclos.

10) Si mi firewall solo soporta basada en políticas, qué debo hacer?

Mantén el conjunto de selectores mínimo y documentado, evita NAT amplio que reescriba direcciones internas y construye monitorización que pruebe cada subred crítica.
Si la oficina crece, planifica una renovación de hardware; basada en políticas a escala se convierte en un impuesto a largo plazo.

Siguientes pasos que realmente puedes hacer

Si gestionas oficinas y quieres menos sorpresas con VPN, haz esto:

1. Estandariza en VPN basada en rutas para enlaces de oficina salvo que estés limitado por equipo de socios o plataformas legacy.
2. Haz el enrutamiento explícito: rutas estáticas para despliegues pequeños; BGP para muchos sitios o integración con nube.
3. Diseña MTU/MSS desde el día uno. No esperes a que SMB arruine tu tarde.
4. Monitoriza el plano de datos: sondas por VLAN, no solo “IKE está arriba”.
5. Documenta los modos de fallo que realmente ves: incompatibilidades de selectores, exenciones NAT, enrutamiento asimétrico, agujeros PMTU.
6. Practica la conmutación por error rompiéndola a propósito en ventanas amigables para el negocio. Un diseño que no has conmutado es un rumor.

Las VPN basadas en rutas no harán tu red perfecta. Solo la hacen diagnosticable, escalable y menos dependiente del conocimiento tribal.
Para oficinas, esa es la diferencia entre “una WAN segura” y “un tema recurrente de incidentes”.