IKEv2/IPsec: Cuando es una mejor opción que WireGuard u OpenVPN

El marco de decisión: qué estás realmente eligiendo

“VPN” no es una sola decisión. Es un conjunto de ellas:

• Superficie del cliente: ¿Quieres un cliente nativo del SO con elementos de política MDM, o una app de terceros que debes desplegar, actualizar y depurar?
• Modelo de identidad: ¿Quieres certificados, EAP (RADIUS/AD), identidad del dispositivo, políticas por usuario y revocación limpia? ¿O una clave compartida y una plegaria?
• Tolerancia a la hostilidad de la red: ¿Puedes sobrevivir a NAT, portales cautivos, carrier-grade NAT y roaming Wi‑Fi sin que los túneles flaqueen?
• Visibilidad operacional: ¿Puedes capturar, interpretar y auditar lo que pasó a las 3 a.m.?
• Ecosistema de proveedores: ¿Tu stack incluye firewalls, balanceadores y gear de identidad que ya “hablan IPsec” con fluidez?

WireGuard gana en simplicidad y rendimiento. OpenVPN gana en “funciona en todas partes y ya lo conocemos”. IKEv2/IPsec gana cuando te importan la integración empresarial, la estabilidad en roaming, la política y la previsibilidad operativa de grado de cumplimiento.

Aquí está la heurística directa que uso en producción:

• Si estás construyendo una superposición amigable para desarrolladores entre endpoints conocidos y puedes gestionar claves limpiamente, empieza con WireGuard.
• Si necesitas máxima compatibilidad con clientes antiguos y entornos de terceros raros, OpenVPN aún tiene sentido.
• Si necesitas clientes nativos, configuración impulsada por MDM, integración fuerte de identidad y túneles que sobreviven al roaming, elige IKEv2/IPsec y no te disculpes por ello.

Hechos e historia que realmente importan en producción

Algunos puntos de contexto que influyen en por qué IKEv2/IPsec se comporta como lo hace hoy y por qué a menudo es la “opción predeterminada empresarial”.

1. IKEv2 fue diseñado para reemplazar la complejidad y fragilidad de IKEv1 (menos intercambios de mensajes, máquina de estados más clara). Lo notas al depurar: menos “folclore fase 1/fase 2” y negociación más estructurada.
2. MOBIKE (Mobility and Multihoming) es una característica de primera clase en IKEv2. Está pensado para clientes que se mueven entre redes sin derribar el túnel.
3. El NAT traversal (NAT-T) estandarizó la encapsulación UDP para IPsec, haciéndolo viable a través de la mayoría de NATs de consumo. No es perfecto, pero no es un parche improvisado.
4. Muchos proveedores de SO incluyeron IKEv2 como la ruta “VPN nativa” mientras que OpenVPN/WireGuard se tratan como terceros. Eso lo cambia todo en la gestión de flotas: distribución de políticas, almacenes de certificados y aplicación de postura de seguridad.
5. IPsec está arraigado en los appliances de red (firewalls, routers, cajas SD‑WAN). Incluso cuando la interfaz es dolorosa, la historia de interoperabilidad es madura.
6. La agilidad criptográfica es un tema operacional real: las suites de IPsec han soportado durante mucho tiempo múltiples algoritmos y negociación, útil cuando el cumplimiento cambia más rápido que el despliegue en endpoints.
7. IKEv2 soporta métodos EAP (como EAP‑TLS, EAP‑MSCHAPv2) para autenticación de usuarios; por eso es un básico en empresas que usan RADIUS.
8. Perfect Forward Secrecy (PFS) es comportamiento normal en perfiles IPsec modernos, y a los auditores les gusta que sea explícito y estándar en lugar de “confía en nosotros”.

Una cita que mantengo en el tablero mental cuando alguien propone una “configuración inteligente” de VPN:

Idea parafraseada — Werner Vogels: debes diseñar para la falla porque todo falla eventualmente, y el sistema debe seguir funcionando de todos modos.

Dónde IKEv2/IPsec supera a WireGuard y OpenVPN

1) Clientes nativos y control por MDM (el superpoder subestimado)

En el mundo real, “despliegue de VPN” significa: portátiles gestionados por MDM, smartphones con acceso condicional y un equipo de seguridad que quiere comprobaciones de postura e identidad basada en certificados. Los clientes IKEv2 nativos están integrados en Windows, macOS, iOS y muchas compilaciones de Android. Eso importa porque:

• Puedes enviar perfiles vía MDM sin distribuir un cliente de terceros.
• Puedes aprovechar los almacenes de certificados del SO y claves respaldadas por keychain/TPM.
• Puedes usar funciones de plataforma como Always On VPN (Windows) con IKEv2.
• Reducirás la rotación de actualizaciones de cliente y los incidentes de “la app VPN dejó de funcionar tras actualizar el SO”.

WireGuard es pequeño y limpio, pero en endpoints gestionados aún despliegas software (o dependes de soporte incorporado que no es universal). OpenVPN casi siempre implica desplegar un cliente y un paquete de configuración, y luego lidiar con “¿qué versión usa este usuario?” durante los próximos cinco años.

2) Estabilidad en roaming con MOBIKE

Si atiendes a usuarios móviles, tu VPN debe sobrevivir: Wi‑Fi de oficina a LTE, Wi‑Fi de hotel a tethering, cambios de dirección IP, NAT rebinding y redes que eliminan silenciosamente mapeos UDP inactivos. IKEv2 con MOBIKE fue diseñado precisamente para esto. Puede actualizar endpoints y mantener el SA vivo sin renegociar todo desde cero.

WireGuard también maneja bien el roaming (está básicamente diseñado para ello), pero IKEv2 te da ese comportamiento dentro de marcos de política empresarial y appliances de proveedores en los que los equipos de seguridad ya confían.

3) Modelos de autenticación empresariales: EAP + RADIUS + certificados

El modelo de identidad de WireGuard son claves públicas. Es una ventaja, no un fallo—hasta que necesitas identidad de usuario, pertenencia a grupos, hooks de MFA y desaprovisionamiento limpio ligado al offboarding de RRHH.

IKEv2 destaca cuando necesitas:

• EAP-TLS (lo más fuerte: certificados en ambos lados, sin contraseñas circulando)
• Autenticación respaldada por RADIUS con política y accounting centralizados
• Control de acceso por usuario/dispositivo mediante atributos, grupos y perfiles de certificados

OpenVPN también puede integrarse con esto, pero a menudo lo estás cosiendo con plugins, scripts y “por favor no actualicen OpenVPN hasta que volvamos a probar la pila de autenticación”. Las stacks IPsec suelen tener estas integraciones como ciudadanos de primera clase.

4) Postura de cumplimiento y auditoría

Algunas organizaciones deben responder preguntas como: “¿Qué suites de cifrado están permitidas?”, “¿Estamos aplicando PFS?”, “¿Podemos demostrar identidad de dispositivo?”, “¿Podemos registrar inicio/parada de conexión e identidad de usuario?”

IKEv2/IPsec tiende a encajar bien en narrativas de auditoría porque el vocabulario de políticas está estandarizado, las implementaciones son maduras y los ecosistemas de appliances/SO exponen registros y controles de configuración de formas que los auditores reconocen.

5) Interoperabilidad con sitio-a-sitio y gear de red existente

Si ya ejecutas IPsec sitio-a-sitio entre oficinas, añadir acceso remoto IKEv2 a menudo reutiliza:

• la misma PKI,
• los mismos proveedores de firewall,
• las mismas runbooks operacionales,
• la misma línea base de políticas criptográficas.

WireGuard puede hacer sitio-a-sitio de forma excelente, pero si tu perímetro está anclado en appliances y control de cambios, IPsec suele ser el camino de menor resistencia organizacional. Eso no es “política”. Es supervivencia.

6) Ingeniería de tráfico y QoS en redes que lo requieren

En redes mayores, eventualmente querrás marcar tráfico, darle forma y observarlo sin adivinanzas. Las implementaciones de IPsec comúnmente se integran con el manejo DSCP, ruteo basado en políticas y herramientas empresariales de QoS. WireGuard es directo, pero no trae el mismo ecosistema de “perillas y paneles” que ya tiene el equipo de red.

Broma corta #1: IPsec es como una navaja suiza—útil, respetada y de alguna manera siempre falta la herramienta que necesitas a las 2 a.m.

Cuándo no usar IKEv2/IPsec

IKEv2/IPsec no es “siempre mejor”. Es mejor cuando tus restricciones coinciden con sus fortalezas.

No elijas IKEv2/IPsec cuando necesites simplicidad extrema

Si el equipo es pequeño y quieres una VPN que puedas explicar en una pizarra en cinco minutos, WireGuard es tu amigo. IPsec tiene más piezas móviles: propuestas, transformaciones, SAs, tiempos de vida, EAP, certificados, NAT-T. Es manejable, pero no es mínimo.

No lo elijas cuando estés detrás de redes hostiles que bloquean UDP

Muchas implementaciones de IPsec corren sobre UDP 500/4500. Algunas redes los bloquean o los mutilan. OpenVPN sobre TCP/443 a veces puede atravesar donde IPsec no. Esto no es una recomendación de rendimiento. Es una recomendación de realidad.

No lo elijas cuando el soporte de plataforma sea desigual

Los clientes nativos son geniales—hasta que debes soportar plataformas con implementaciones IKEv2 extrañas o métodos EAP limitados. Si soportas dispositivos empotrados raros, OpenVPN o WireGuard pueden ser más fáciles de estandarizar.

No lo elijas si no puedes comprometerte con la higiene de PKI

IKEv2 con EAP-TLS y certificados es excelente. También requiere que administres PKI con seriedad: flujos de emisión, revocación, monitorización de expiraciones, planes de rotación. Si tu práctica de certificados actual es “ponremos un recordatorio en el calendario para el próximo año”, vas a tener un mal rato.

Opciones de arquitectura: road warrior, sitio-a-sitio y “siempre activo”

Acceso remoto (road warrior) IKEv2

Este es el modelo de “los usuarios se conectan desde cualquier lugar”. Elecciones típicas:

• VPN basada en rutas (preferida): asigna una IP virtual al cliente y enruta redes a través del túnel.
• Túnel dividido vs túnel completo: el dividido reduce ancho de banda y radio de impacto; el túnel completo simplifica controles de seguridad pero aumenta la dependencia de la disponibilidad de la VPN.

Con IKEv2, las configuraciones basadas en rutas suelen sentirse más limpias operativamente que las basadas en políticas. Depurarás menos misterios de “por qué solo falla esta subred”.

Sitio-a-sitio IKEv2

Este es el territorio clásico de IPsec. Si tu organización ya tiene túneles sitio-a-sitio, estandarizar en IKEv2 aporta consistencia y a veces mejor comportamiento de failover.

En entornos de múltiple proveedor, dedica tiempo a la compatibilidad de propuestas. La mayoría de los tickets “IPsec está roto” son en realidad “desajuste de propuesta” con una fina capa de negación encima.

Casos de uso “siempre activo” / túnel de dispositivo

IKEv2 es a menudo el protocolo detrás de estrategias empresariales “siempre activo” porque se integra con la red en el arranque del SO y la identidad del dispositivo. Esto importa para:

• dispositivos unidos al dominio que deben alcanzar controladores antes del inicio de sesión,
• herramientas de gestión que necesitan conectividad incluso sin usuario conectado,
• políticas de acceso condicional basadas en cumplimiento del dispositivo.

Autenticación e identidad: EAP, certificados, PSK y las trampas

PSK: rápido, familiar y normalmente el valor por defecto equivocado

Las claves precompartidas son tentadoras porque son fáciles. También son una responsabilidad de escalabilidad y seguridad en acceso remoto:

• La revocación es complicada: rotas la PSK y rompes a todos a la vez.
• La distribución se convierte en un problema de compartir secretos.
• Auditar “quién usó la clave” es débil a menos que lo combines con otras comprobaciones de identidad.

Las PSK son aceptables para túneles sitio-a-sitio muy controlados con disciplina operativa fuerte. Para usuarios, usa certificados y/o EAP.

EAP-MS-CHAPv2: funciona, pero trátalo como un puente legado

EAP-MS-CHAPv2 es común en entornos corporativos porque se integra con sistemas de identidad existentes. Pero desde el punto de vista de seguridad, no es el estándar de oro. Si puedes usar EAP-TLS, úsalo.

EAP-TLS: la opción de “sí, queríamos seguridad”

EAP-TLS te brinda autenticación mutua fuerte con certificados. La ventaja operativa es el desaprovisionamiento limpio: revoca el certificado y el dispositivo/usuario queda fuera. El riesgo operativo es la gestión del ciclo de vida de certificados. Debes monitorizar expiraciones y automatizar renovaciones cuando sea posible.

Propuestas criptográficas: estandariza o sufre

Elige un pequeño conjunto de algoritmos y tiempos de vida aprobados. Publícalos. Aplícalos. Si cada entorno tiene una suite diferente, eventualmente depurarás “funciona en mi portátil” a nivel criptográfico, que es la clase de miseria más nerd.

Broma corta #2: La manera más rápida de aprender IPsec es configurar mal una propuesta; la segunda más rápida es hacerlo en producción.

Realidad operativa: monitorización, depuración y gestión de cambios

IKEv2/IPsec tiene fama de “difícil de resolver”. Eso es parcialmente merecido. También porque muchos equipos intentan operarlo sin observabilidad. No lo hagas.

Qué monitorizar

• Recuento de túneles arriba/abajo y tasa de fluctuación por ASN de cliente / tipo de red (patrones Wi‑Fi vs celular revelan problemas de MTU y NAT rápidamente).
• Fallos de autenticación desglosados por motivo (certificado inválido, fallo EAP, desajuste de propuesta).
• Paquetes descartados en UDP 500/4500 y ESP, especialmente en firewalls/dispositivos NAT.
• Baselines de latencia y rendimiento a un endpoint interno conocido.

Gestión de cambios: IPsec castiga ediciones casuales

WireGuard perdona: cambias un peer, recargas y listo. Los cambios en IPsec pueden propagarse:

• Los cambios de propuesta requieren que ambas partes acuerden.
• Los cambios en la cadena de certificados pueden romper clientes que cachearon una CA antigua.
• Los cambios en el comportamiento NAT-T pueden exponer problemas de filtrado de ruta.

Usa despliegues por etapas. Conserva perfiles conocidos buenos. Registra todo. Trata la VPN como un servicio de producción, no como una misión secundaria de red.

Tareas prácticas con comandos: qué ejecutar, qué significa, qué decidir

A continuación hay tareas concretas que puedes ejecutar en una puerta de enlace IKEv2/IPsec basada en Linux (se asume strongSwan) e infraestructura circundante. Cada tarea incluye: comando, salida de ejemplo, cómo leerlo y la decisión que tomas.

Task 1: Confirmar que el demonio IKE está saludable

cr0x@server:~$ systemctl status strongswan-starter
● strongswan-starter.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
     Loaded: loaded (/lib/systemd/system/strongswan-starter.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-12-27 08:11:02 UTC; 2h 14min ago
   Main PID: 1187 (starter)
      Tasks: 18 (limit: 9381)
     Memory: 21.4M
     CGroup: /system.slice/strongswan-starter.service
             ├─1187 /usr/lib/ipsec/starter
             └─1214 /usr/lib/ipsec/charon

Significado: Si no está active (running), deja de depurar la red y empieza a depurar el servicio.

Decisión: Si está inactivo/crashing, recoge registros (Task 2) y revierte el último cambio de configuración antes de tocar reglas de firewall.

Task 2: Inspeccionar errores recientes de negociación IKE

cr0x@server:~$ journalctl -u strongswan-starter -n 80 --no-pager
Dec 27 10:02:41 vpn-gw charon[1214]: 12[IKE] received AUTHENTICATION_FAILED notify error
Dec 27 10:02:41 vpn-gw charon[1214]: 12[IKE] EAP method EAP_MSCHAPV2 failed
Dec 27 10:02:41 vpn-gw charon[1214]: 12[IKE] IKE_SA vpn-ra[12] state change: AUTHENTICATING => DESTROYING
Dec 27 10:03:18 vpn-gw charon[1214]: 15[IKE] no proposal chosen
Dec 27 10:03:18 vpn-gw charon[1214]: 15[IKE] peer supports: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048
Dec 27 10:03:18 vpn-gw charon[1214]: 15[IKE] configured: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

Significado: Dos modos de fallo distintos: un fallo de autenticación EAP y un desajuste en la propuesta criptográfica (no proposal chosen).

Decisión: Soluciona los problemas de identidad (RADIUS/EAP) por separado de la política criptográfica. No “abra todos los cifrados” por pánico; alinea las propuestas explícitamente.

Task 3: Listar SAs establecidas y contadores de tráfico

cr0x@server:~$ sudo swanctl --list-sas
vpn-ra: #14, ESTABLISHED, IKEv2, 8f3a1b9c1b2e3a2d_i* 21a9de88c0d3b1aa_r
  local  'vpn.example' @ 203.0.113.10[4500]
  remote 'user@corp' @ 198.51.100.77[51234]
  AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
  established 612s ago, rekeying in 41m
  vpn-ra{27}:  INSTALLED, TUNNEL, reqid 7, ESP in UDP SPIs: c1b2a3d4_i c9d8e7f6_o
  vpn-ra{27}:   10.10.50.21/32 === 10.0.0.0/16
  vpn-ra{27}:   in  1483920 bytes, 1240 packets
  vpn-ra{27}:   out 932481 bytes, 1102 packets

Significado: El túnel está arriba y los paquetes fluyen en ambas direcciones. Si los usuarios informan “conectado pero nada funciona”, compara estos contadores con los síntomas a nivel de aplicación.

Decisión: Si las SAs están establecidas pero los contadores no aumentan, sospecha de ruteo/firewall/NAT en la puerta o en el cliente o de ajustes de túnel dividido.

Task 4: Verificar que UDP 500/4500 está escuchando

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

Significado: Si no ves estos sockets, tu demonio no está ligado o está bloqueado por política local.

Decisión: Sin listener → arregla la configuración/bind del demonio antes de cambiar firewalls aguas arriba.

Task 5: Revisar reglas de firewall para puertos IPsec

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    udp dport { 500, 4500 } accept
    ip protocol icmp accept
    tcp dport 22 accept
    counter drop
  }
}

Significado: UDP 500/4500 está permitido. Si la política es drop y estos faltan, tu VPN parecerá “muerta” desde fuera.

Decisión: Si faltan, añade reglas explícitas. No cambies temporalmente la política a accept; lo olvidarás revertir.

Task 6: Confirmar reenvío IP del kernel y rp_filter

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

Significado: El reenvío está activado (bien). Pero el filtrado de ruta inversa estricto (rp_filter=1) puede descartar tráfico tunelizado en configuraciones de ruteo asimétrico.

Decisión: Si tienes múltiples uplinks, ruteo por políticas o complejidad NAT-T, considera rp_filter=2 (loose) en interfaces relevantes y valida con captura de paquetes.

Task 7: Revisar rutas para los pools de clientes VPN

cr0x@server:~$ ip route show
default via 203.0.113.1 dev eth0
10.0.0.0/16 via 10.0.1.1 dev eth1
10.10.50.0/24 dev vti0 proto kernel scope link src 10.10.50.1

Significado: El pool de clientes está en vti0. Si las redes internas no saben cómo devolver tráfico a 10.10.50.0/24, los clientes se conectarán pero no recibirán respuestas.

Decisión: Asegura rutas de retorno en tus routers internos o realiza NAT (con conciencia de las implicaciones de auditoría/seguridad).

Task 8: Validar reglas NAT al usar túnel dividido/completo

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

Significado: El tráfico de clientes VPN dirigido a la interfaz interna eth1 se NATea. Eso puede “arreglar” el ruteo pero oculta la identidad del cliente en los logs internos.

Decisión: Usa NAT solo si no puedes añadir rutas de retorno. Si te importa la trazabilidad por usuario en sistemas internos, enruta correctamente y evita NAT.

Task 9: Confirmar que llegan paquetes ESP-en-UDP (NAT-T)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 4500 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:21:11.205931 IP 198.51.100.77.51234 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1b2a3d4,seq=0x0000048a), length 148
10:21:11.306102 IP 203.0.113.10.4500 > 198.51.100.77.51234: UDP-encap: ESP(spi=0xc9d8e7f6,seq=0x000003f2), length 132
10:21:11.406245 IP 198.51.100.77.51234 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1b2a3d4,seq=0x0000048b), length 148
10:21:11.506311 IP 203.0.113.10.4500 > 198.51.100.77.51234: UDP-encap: ESP(spi=0xc9d8e7f6,seq=0x000003f3), length 132
10:21:11.606478 IP 198.51.100.77.51234 > 203.0.113.10.4500: UDP-encap: ESP(spi=0xc1b2a3d4,seq=0x0000048c), length 148

Significado: Flujo bidireccional de ESP-en-UDP. Si ves inbound pero no outbound, sospecha filtrado de salida o ruteo en la puerta.

Decisión: Usa esto para separar “el cliente llega a la puerta” de “la puerta puede responder”. Evita horas de adivinanzas.

Task 10: Detectar problemas de MTU/fragmentación temprano

cr0x@server:~$ ping -M do -s 1372 10.0.0.10 -c 3
PING 10.0.0.10 (10.0.0.10) 1372(1400) bytes of data.
1372 bytes from 10.0.0.10: icmp_seq=1 ttl=63 time=18.1 ms
1372 bytes from 10.0.0.10: icmp_seq=2 ttl=63 time=18.5 ms
1372 bytes from 10.0.0.10: icmp_seq=3 ttl=63 time=17.9 ms

--- 10.0.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Significado: Esto prueba un tamaño de carga que aproxima las limitaciones comunes de MTU una vez aplicado el overhead de IPsec. Si esto falla mientras pings más pequeños funcionan, tienes un problema de MTU/PMTUD.

Decisión: Si falla, aplica clamp MSS (Task 11) o ajusta el MTU de interfaces en endpoints de túnel. No culpes al DNS todavía.

Task 11: Limitar MSS TCP para evitar PMTUD enterrado

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 1
-A FORWARD -o vti0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Significado: El clamp MSS a menudo mitiga filtros ICMP rotos y fallos de PMTUD que se manifiestan como “los sitios cuelgan, pero el ping funciona”.

Decisión: Si las apps de usuarios se bloquean en transferencias grandes, aplica el clamp MSS y vuelve a probar. Luego programa una solución adecuada (permitir ICMP fragmentation-needed, fijar MTU correcto).

Task 12: Validar estado XFRM y políticas en el kernel

cr0x@server:~$ sudo ip xfrm state
src 203.0.113.10 dst 198.51.100.77
  proto esp spi 0xc9d8e7f6 reqid 7 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha256) 0x3b... 128
  enc cbc(aes) 0x9f...
src 198.51.100.77 dst 203.0.113.10
  proto esp spi 0xc1b2a3d4 reqid 7 mode tunnel
  replay-window 32 flag af-unspec
  auth-trunc hmac(sha256) 0xa1... 128
  enc cbc(aes) 0x11...

Significado: El kernel tiene SAs ESP activas. Si charon dice “established” pero falta estado XFRM, tienes un desajuste control-plane/data-plane.

Decisión: Si faltan, sospecha módulos de kernel, fallos al instalar política o herramientas IPsec en conflicto (ej., múltiples demonios).

Task 13: Comprobar desajuste de propuesta desde el lado cliente (capturado en gateway)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 500 -vv -c 3
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 198.51.100.77.500 > 203.0.113.10.500: isakmp 2.0 msgid 00000000: phase 1 IKE_SA_INIT (sa payload)
IP 203.0.113.10.500 > 198.51.100.77.500: isakmp 2.0 msgid 00000000: phase 1 IKE_SA_INIT (sa payload) notify(NO_PROPOSAL_CHOSEN)
IP 198.51.100.77.500 > 203.0.113.10.500: isakmp 2.0 msgid 00000000: phase 1 IKE_SA_INIT (sa payload)

Significado: El gateway rechazó la propuesta (NO_PROPOSAL_CHOSEN). Eso no es “red”. Es desacuerdo de configuración.

Decisión: Alinea transformaciones IKE/ESP. Evita respuestas amplias de “habilitar todo”; define una línea base compatible y aplícala.

Task 14: Confirmar comportamiento DNS para clientes VPN (frecuente impostor de “VPN rota”)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 5 (vti0)
      Current Scopes: DNS
           Protocols: +DefaultRoute
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.example

Significado: La interfaz de túnel tiene servidores DNS y un dominio de búsqueda. Si los clientes alcanzan IPs pero no nombres, la asignación DNS o la política de DNS dividido está mal.

Decisión: Arregla la distribución DNS primero. A los usuarios no les importa que el túnel esté “arriba” si su navegador no resuelve nombres internos.

Task 15: Confirmar accesibilidad RADIUS y códigos de respuesta (al usar EAP)

cr0x@server:~$ sudo radtest alice 'CorrectHorseBatteryStaple' 10.0.0.20 0 testing123
Sent Access-Request Id 164 from 0.0.0.0:51682 to 10.0.0.20:1812 length 76
		User-Name = "alice"
		User-Password = "CorrectHorseBatteryStaple"
		NAS-IP-Address = 10.0.0.1
		NAS-Port = 0
		Message-Authenticator = 0x00
Received Access-Accept Id 164 from 10.0.0.20:1812 to 10.0.0.1:51682 length 44

Significado: RADIUS acepta credenciales y es accesible. Si la autenticación VPN falla pero esto tiene éxito, el problema puede ser el método EAP/cadena de confianza de certificados.

Decisión: Separa la salud del backend de identidad de la negociación EAP de la VPN. Si RADIUS está bien, enfócate en la configuración EAP, la cadena de certificados y ajustes del cliente.

Guion rápido de diagnóstico

Cuando alguien dice “la VPN está lenta” o “la VPN está caída”, no empiezas con debates filosóficos sobre protocolos. Empiezas con un ciclo corto que encuentre el cuello de botella rápido.

Primero: ¿es plano de control o plano de datos?

• Chequeo de plano de control: ¿Están establecidas las SAs IKE? Usa swanctl --list-sas. Si no hay SAs, estás en territorio de autenticación/propuesta/firewall.
• Chequeo de plano de datos: Si existen SAs, ¿aumentan los contadores? Si no, estás en ruteo/NAT/firewall/XFRM.

Segundo: prueba que los paquetes atraviesan el perímetro

• Ejecuta ss -lunp para confirmar listeners UDP 500/4500.
• Ejecuta tcpdump en la interfaz WAN para UDP 500/4500.
• Si el inbound aparece pero el outbound no, revisa firewall y ruteo local; si ninguno aparece, revisa firewall/NAT aguas arriba.

Tercero: busca los asesinos silenciosos (MTU, DNS, asimetría)

• MTU: síntomas incluyen “SSH funciona pero sitios cuelgan”, “descargas grandes se estancan”. Usa pings DF y aplica clamp MSS como mitigación.
• DNS: “conectado pero nada funciona” a menudo es “conectado pero no resuelve”. Confirma servidores DNS y comportamiento de DNS dividido.
• Ruteo asimétrico: el tráfico del túnel sale por una interfaz y vuelve por otra, luego es descartado por rp_filter o firewalls aguas arriba.

Cuarto: valida que el rendimiento no sea un problema de CPU/cripto

• Revisa saturación de CPU en la puerta bajo carga.
• Verifica que AES-NI / aceleración criptográfica esté habilitada si aplica.
• Confirma que no estés haciendo encapsulaciones innecesarias (double NAT, doble túnel).

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

1) “Conectado” pero sin acceso a subredes internas

Síntoma: El cliente muestra conectado; servicios internos agotan tiempo; la puerta muestra SAs establecidas.

Causa raíz: Rutas de retorno faltantes al pool de clientes VPN, o reglas de firewall que no permiten tráfico reenviado.

Solución: Añade rutas en los routers internos para el pool de clientes vía la puerta VPN; valida con ip route y contadores en swanctl --list-sas. Usa NAT solo como último recurso.

2) Reconexiones frecuentes cuando los usuarios hacen roaming (Wi‑Fi ↔ LTE)

Síntoma: El túnel se cae cuando cambia la IP; los usuarios se quejan en redes móviles.

Causa raíz: MOBIKE deshabilitado o no soportado en el perfil; problemas de NAT rebinding; ajustes agresivos de DPD.

Solución: Habilita MOBIKE, ajusta DPD/keepalives para mantener vivos los mapeos NAT, verifica en los logs que las direcciones se actualizan en lugar de reautenticarse completamente.

3) “No proposal chosen” tras una actualización de política de seguridad

Síntoma: Fallo inmediato en IKE_SA_INIT; logs muestran no proposal chosen.

Causa raíz: Las suites del gateway y del cliente divergieron—a menudo tras deshabilitar SHA1/grupos DH antiguos sin actualizar clientes.

Solución: Define una matriz de compatibilidad por versión de SO. Despliega cambios de perfil de cliente antes de endurecer la política del servidor. Mantén una suite transitoria temporal con fecha de retirada.

4) Funciona en algunas redes, falla en Wi‑Fi de hotel/guest

Síntoma: Usuarios se conectan desde casa/celular pero no desde ciertas redes Wi‑Fi.

Causa raíz: UDP 500/4500 bloqueado o mutilado; interferencia de portal cautivo; casos límite de NAT simétrico.

Solución: Confirma con tcpdump si llegan paquetes. Si están bloqueados, considera ofrecer una ruta de escape (a veces OpenVPN/TCP es la opción pragmática) o usa una gateway VPN en una ruta de salida más permisiva.

5) Bajo rendimiento después de “endurecer la seguridad”

Síntoma: Los túneles conectan bien; el rendimiento se reduce a la mitad; la CPU del gateway sube.

Causa raíz: Elegir algoritmos costosos en CPU o deshabilitar rutas de aceleración; rekeying excesivo.

Solución: Prefiere suites AEAD modernas como AES-GCM cuando se soporten; asegura que la aceleración criptográfica esté activada; aumenta intervalos de rekey con sentido.

6) Colgados aleatorios en cargas grandes

Síntoma: Paquetes pequeños bien; transferencias grandes se estancan; algunas apps funcionan y otras no.

Causa raíz: PMTUD/MTU en agujero negro—ICMP “fragmentation needed” bloqueado en algún punto.

Solución: Aplica clamp MSS como mitigación; luego arregla PMTUD permitiendo ICMP y fijando MTU correcto en interfaces de túnel.

7) Usuarios se autentican pero obtienen acceso incorrecto

Síntoma: Algunos usuarios alcanzan redes restringidas; otros no alcanzan lo que deberían.

Causa raíz: Atributos/grupos RADIUS mapeados incorrectamente; política por usuario inconsistente en la puerta.

Solución: Normaliza el mapeo de políticas. Registra grupos/ACL aplicadas por sesión. Trata la autorización VPN como autorización de aplicación: explícita, versionada y revisada.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición errónea

Migraron el acceso remoto de un appliance antiguo a una nueva puerta Linux ejecutando IKEv2. Los usuarios piloto estaban contentos. El rendimiento era excelente. La ventana de cambio cerró con felicitaciones y un nuevo tile en el dashboard.

Dos días después, el helpdesk recibió una ola: “La VPN conecta, pero nada carga”. No todos—solo usuarios en una oficina concreta y algunos en ISPs específicos. El estado del túnel parecía bien. Las SAs estaban establecidas. Los bytes se movían. El equipo asumió “debe ser DNS” porque siempre es DNS hasta que no lo es.

La suposición errónea fue sutil: creían que el ruteo interno ya tenía una ruta de regreso al nuevo pool de clientes VPN porque “es solo otra subred interna”. No lo era. El appliance antiguo NATeaba el tráfico de clientes a una gama de origen familiar, así que el ruteo de retorno nunca importó. La nueva configuración era más limpia—ruteada, sin NAT—así que dependía de rutas de retorno. Esas rutas no existían en todas partes.

Una vez que alguien trazó un único flujo extremo a extremo, el patrón se hizo claro: los SYN entraban, los SYN‑ACKs iban al gateway por defecto y morían en otro sitio. Añadieron rutas en el core, lo confirmaron en routers de borde y el incidente se evaporó.

La lección no fue “rutar es difícil”. La lección fue: sabe si tu predecesor resolvió un problema con NAT, y no quites ese comportamiento sin reemplazar la dependencia.

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

Otra empresa tenía un despliegue IKEv2 limpio con EAP‑TLS y certificados gestionados. El rendimiento era aceptable, pero querían más. Alguien notó picos de CPU en la puerta VPN y decidió “optimizar” ajustando configuraciones criptográficas y temporizadores de rekey.

El cambio se hizo con buenas intenciones: tiempos de vida más cortos para “mejor seguridad” y cambiar a una propuesta que parecía más fuerte en papel. Nadie midió el costo en CPU. Nadie verificó qué algoritmos aprovechaban aceleración de hardware. Lo desplegaron un viernes porque “es solo configuración”.

El lunes por la mañana la puerta estaba en thrash. Empezaron tormentas de rekey en horas punta y los clientes móviles—ya sensibles a pérdida de paquetes—comenzaron a flaquear. Los usuarios lo describían como “la VPN parece embrujada”, que no es una métrica, pero es una vibra que debes respetar.

El rollback lo solucionó de inmediato. Una prueba posterior mostró que la suite “más fuerte” consumía más CPU por paquete y el intervalo de rekey multiplicó el trabajo en el plano de control. La postura de seguridad no mejoró significativamente porque la suite original ya estaba conforme, pero la disponibilidad empeoró, que es un problema de seguridad por sí mismo.

La lección: las perillas criptográficas son perillas de rendimiento. Cámbialas como cambias índices de base de datos: con benchmarks, despliegue por etapas y plan de reversión.

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

Una organización ejecutaba IKEv2 para acceso remoto y sitio-a-sitio, con certificados emitidos por una CA interna. Nada sofisticado. La magia estaba en las partes aburridas: rastreaban expiraciones de certificados, tenían alertas y forzaban renovación automática en dispositivos gestionados.

Seis meses después, tuvieron que rotar la jerarquía de la CA por un cambio de política de seguridad. Ese tipo de cambio suele causar caos: clientes no confían en la nueva cadena, gateways presentan el intermedio equivocado y todos juegan a “adivina el almacén de confianza” durante una semana.

No lo hicieron. Tenían un plan documentado de despliegue de cadena de confianza: empujar la nueva raíz/intermedio a endpoints primero, verificar la confianza vía cumplimiento MDM y luego actualizar gateways para presentar la nueva cadena. Solo después de que la telemetría mostró que la mayoría de dispositivos confiaban en la nueva CA revocaron el intermedio antiguo.

La rotación se completó con ruido mínimo. Sin interrupciones. Sin re‑inscripción masiva. El mejor cumplido fue el silencio del helpdesk.

La lección: la gestión del ciclo de vida de certificados no es papeleo; es ingeniería de disponibilidad.

Listas de verificación / plan paso a paso

Elegir IKEv2/IPsec (lista de decisión)

1. ¿Necesitas clientes nativos y configuración impulsada por MDM? Si sí, inclínate por IKEv2.
2. ¿Necesitas identidad por usuario con política centralizada (RADIUS/AD) y buenas trazas de auditoría? Si sí, inclínate por IKEv2.
3. ¿Tienes una fuerza laboral con mucho roaming y quieres túneles estables ante cambios de red? Si sí, exige MOBIKE y pruébalo.
4. ¿Tu entorno es hostil a UDP 500/4500? Si sí, planea una estrategia de fallback (o reconsidera el protocolo).
5. ¿Puedes operar PKI con disciplina (emisión, renovación, revocación, alertas de expiración)? Si no, arregla eso primero o elige un modelo que coincida con tu realidad.

Plan de despliegue en producción (paso a paso)

1. Define una matriz de compatibilidad: versiones SO soportadas, métodos EAP, suites de cifrado y tiempos de vida.
2. Elige identidad: EAP‑TLS si es posible; de lo contrario EAP con RADIUS e integración MFA. Evita PSK para VPN de usuarios.
3. Construye una gateway de referencia: con logging activado, métricas exportadas y acceso controlado a capturas de paquetes.
4. Implementa ruteo deliberadamente: decide tráfico enrutado vs NATeado y documenta rutas de retorno.
5. Plan MTU: fija MTU de túnel, permite ICMP fragmentation-needed y añade clamp MSS solo como mitigación.
6. Despliegue de clientes por etapas: piloto interno, luego un departamento, luego despliegue amplio. Mantén la VPN antigua hasta que la tasa de churn sea estable.
7. Pruebas de caos (ligeras): haz roaming entre Wi‑Fi y LTE, suspende/reanuda portátiles, prueba redes con portal cautivo.
8. Runbooks: documenta tu guion rápido de diagnóstico y quién posee cada capa (red/seguridad/endpoint).
9. Simulacros de rotación: practica la renovación de certificados y la reversión de configuración de gateway.

Lista de operaciones Day‑2

1. Monitorea la fluctuación de túneles, fallos de autenticación y tasas de éxito de conexión por usuario.
2. Alerta sobre expiraciones de certificados (gateway y CAs emisoras de clientes).
3. Revisa trimestralmente la política criptográfica vs capacidad de clientes (evita sorpresas de “no proposal chosen”).
4. Prueba desde al menos dos redes hostiles (guest Wi‑Fi, hotspot móvil) para detectar filtrados de egress.
5. Mantén un perfil de cliente conocido en escrow (para recuperación).

Preguntas frecuentes

¿Es IKEv2/IPsec “más seguro” que WireGuard?

No automáticamente. WireGuard tiene una superficie de ataque menor y elecciones criptográficas modernas. IKEv2/IPsec puede ser extremadamente seguro si se configura bien. El diferenciador real suele ser la integración de identidad y políticas, no la criptografía pura.

¿Por qué IKEv2 se siente más fiable para portátiles corporativos?

Porque el SO gestiona la pila cliente: se integra con almacenes de certificados, transiciones de red y políticas de gestión del dispositivo. Menos piezas de terceros significa menos fallos raros tras actualizaciones del SO.

¿Cuál es la única mejor razón para elegir IKEv2 sobre OpenVPN?

Soporte de cliente nativo más modelos de autenticación empresariales (EAP/RADIUS/certificados) con control de políticas predecible. OpenVPN puede hacer mucho, pero pagas una “tasa de gestión de clientes”.

¿Cuál es la única mejor razón para elegir IKEv2 sobre WireGuard?

Cuando necesitas identidad de usuario/dispositivo y políticas centralizadas que se integren en flujos corporativos de IAM, además de la comodidad de interoperabilidad IPsec estándar con gear de red existente.

¿Debería usar PSK para acceso remoto IKEv2?

Generalmente no. PSK es difícil de rotar a escala y pobre para auditoría por usuario. Usa EAP‑TLS o EAP respaldado por RADIUS, idealmente con MFA.

¿Necesito permitir ESP (protocolo IP 50) en mi firewall?

No necesariamente. Muchas implementaciones dependen de NAT-T (UDP 4500) que encapsula ESP dentro de UDP. Si controlas ambos extremos y evitas NAT, puede usarse ESP nativo, pero UDP 4500 es la ruta práctica común.

¿Por qué veo “no proposal chosen” y cómo lo evito?

Significa que cliente y servidor no pueden ponerse de acuerdo sobre algoritmos y parámetros IKE/ESP. Soluciona estandarizando suites y desplegando perfiles de cliente antes de endurecer la política del servidor.

Mi túnel está arriba pero las apps web cuelgan—¿cuál es la causa probable?

Agujeros negros MTU/PMTUD. Paquetes grandes se descartan silenciosamente. Valida con pings DF y mitiga con clamp MSS mientras corriges ICMP/MTU.

¿IKEv2 es bueno para sitio-a-sitio y acceso remoto juntos?

Sí, y esta es una de sus ventajas operativas. Puedes unificar política criptográfica, monitorización y modelos de soporte de proveedores en ambos casos de uso.

¿Qué debo registrar para cumplimiento sin ahogarme en ruido?

Registra eventos de autenticación (éxito/fallo con razones), IPs virtuales asignadas, identificadores de políticas/ACL aplicadas y inicio/parada de sesión. Evita logs de paquetes completos excepto durante ventanas de incidentes.

Próximos pasos prácticos

Si estás eligiendo entre IKEv2/IPsec, WireGuard y OpenVPN, deja de discutir en abstracto. Toma la decisión con las restricciones que realmente producen interrupciones:

1. Inventaría tus clientes (versiones SO, estado de gestión, patrones de roaming). Si necesitas nativo + MDM, IKEv2 sube al frente.
2. Elige un modelo de identidad que puedas operar durante años. Si puedes ejecutar EAP‑TLS con buena higiene PKI, hazlo.
3. Define y publica suites criptográficas y mantenlas intencionalmente aburridas. Luego prueba en todas las plataformas cliente que soportas.
4. Decide tráfico enrutado vs NATeado de acceso remoto desde el inicio, documenta rutas de retorno y no cambies accidentalmente la historia de seguridad/auditoría.
5. Adopta el guion rápido de diagnóstico como memoria muscular on-call: plano de control vs plano de datos, prueba del perímetro, luego MTU/DNS/asimetría.

Elige el protocolo que puedas operar con limpieza. La mejor VPN es la que no convierte a tu equipo de red en detectives a tiempo parcial.