Troubleshooting del Establecimiento de Túneles FlexVPN: Implementación Hub-and-Spoke y Spoke-to-Spoke con IKEv2/IPsec (IPv4/IPv6 con PSK)

Guía técnica completa para validar, diagnosticar y resolver fallos en despliegues FlexVPN de Cisco con autenticación PSK en modo dual-stack IPv4 e IPv6, incluyendo Hub-and-Spoke y Spoke-to-Spoke.

FlexVPN es la evolución del framework de VPN basado en IKEv2 en Cisco IOS, y permite la construcción de topologías dinámicas Hub-and-Spoke y Spoke-to-Spoke utilizando IKEv2/IPsec, Virtual-Access, NHRP y túneles GRE.

Este artículo presenta un análisis profundo del establecimiento del túnel FlexVPN, explicando paso a paso cómo validar cada componente que interviene en la negociación, cómo interpretar los mensajes relevantes en debug crypto ikev2, y cómo verificar la correcta operación tanto del plano IPv4 como IPv6.

Incluimos ejemplos reales de configuraciones y outputs operacionales en producción:

• show crypto ikev2 sa detailed
• show crypto ipsec sa
• show ipv6 route y show ip route
• show ip nhrp brief

Para entender la secuencia real del establecimiento del túnel y del tráfico protegido entre Spokes.

Establecimiento IKEv2/Ipsec

IKE_SA_INIT — intercambio inicial (SA, KE, NONCE, NAT-D)

Qué ocurre:

• El iniciador (Spoke) envía IKE_SA_INIT con:
• Propuesta (SA): lista de algoritmos (p. ej. AES-256, SHA512, DH group 5, etc.)
• KE (Diffie-Hellman public value)
  • NONCE
  • NAT-DETECTION payloads (si procede)

• Spoke1 propone las transformaciones (está usando el default proposal del IOS).
• Se intentó NAT detection y el resultado fue “NAT not found” (porque la conexión WAN es IPv6 nativa).
• Si el Hub responde con IKE_SA_INIT RESPONSE (KE, SA aceptada), calculan SKEYSEED y continúan al siguiente paso.

IKE_AUTH — autenticación y negociación de CHILD_SA (AUTH, IDi/IDr, TSi/TSr, CFG)

• Intercambio de identidades (IDi = FQDN del Spoke, IDr = FQDN del Hub), y autenticación (PSK para este diseño).
• Se negocian los Traffic Selectors (TSi/TSr) para la fase 2.
• Se puede enviar Config-Mode (atributos que el Hub empuja: direcciones, subredes).

Lo que el Hub empujó (config-Mode).

• La autenticación PSK basada en FQDN se validó correctamente.
• El Hub usa config-mode para asignar la IP del spoke (192.168.15.3) y empujar rutas IPv4/IPv6 hacia el Spoke.

CREATE_CHILD_SA (fase IPsec / fase 2) — instalación de SAs Ipsec

• Tras IKE_AUTH, se crean los CHILD_SA (IPsec SAs) que protegerán el tráfico GRE (proto 47) entre extremos.
• Se instalan SPIs en ambos extremos, se inician los contadores de tráfico.

• IPsec está activado sobre Tunnel0 en modo Transport, protegiendo GRE (proto 47).
• Transform-set negociado: esp-aes esp-sha-hmac (default transform-set).
• Hay tráfico cifrado (packets encrypted / decrypted > 0).

Config-mode y rutas instaladas

• El Hub empuja rutas y direcciones (config-mode). IKE instala esas rutas en la tabla del Spoke apuntando al túnel.

• la tabla de rutas

• Las rutas pushadas por IKE aparecen en la RIB como rutas estáticas gestionadas por el SA (tag internas).
• Esto habilita el reachability inicial para EIGRP/OSPF en el interior.

NHRP registration / Virtual-Access y preparación para Spoke-to-Spoke

• Luego del establecimiento, el Spoke registra su dirección pushada (ej. 192.168.15.3 / 2001:DB8:BEEF:1::1) y su NBMA (2001:DB8:ABCD:2::2) en el Hub vía NHRP
• El Hub y otros Spokes aprenden mapping NBMA ←→ NextHop.
• Cuando un Spoke necesita contactar a otro, puede resolver el NBMA y establecer negociación IPsec directa (shortcut).

• Spoke1 ha aprendido mappings dinámicos apuntando al NBMA de Spoke2 (2001:DB8:ABCD:3::3).
• Se creó Virtual-Access1 (interfaz dinámica) asociada a esos mappings.

DPD y mantenimiento del SA

• DPD fue activado; cuando el peer no respondió se hicieron retransmisiones, se alcanzó el límite y el SA fue eliminado.
• Posteriormente el Spoke reintentó IKE_SA_INIT y se estableció de nuevo la SA (se ve el flujo completo y la sesión pasa a READY).

Recomendación:

• dpd 30 5 está bien en laboratorio; en producción ajusta según latencia/escenario.

Verificación del túnel

Ver estado IKE (Fase1), algoritmos negociados, SPIs y tiempo de vida del SA.

show crypto ikev2 sa

• Hub tiene sesiones IKEv2 READY con ambos Spokes.
• Algoritmos negociados concuerdan con default proposal.

show crypto ikev2 sa detailed

Ver identidad (IDi/IDr), pushed addresses, config attributes, DPD config, NAT detection, SPIs.

• Autenticación y config-mode OK.
• Rutas y direcciones correctamente instaladas.

show crypto ipsec sa

Confirmar CHILD_SA (fase2), SPIs de IPsec, transform-set y contadores.

Spoke1 Tunnel0

• IPsec activo y procesando tráfico.
• Modo Transport (correcto para GRE-over-IP).
• MTU ajustado (plaintext mtu 1462) — recuerda MSS/MTU tuning en túnel.

Campo práctico: el código H en la RIB (ejemplo show ip route)

• H indica rutas aprendidas por NHRP (Next Hop Resolution Protocol).
• Ejemplo: H 192.168.15.2 is directly connected, Virtual-Access1 → mapping NHRP existe para la dirección pushada del peer y la interfaz virtual está creada.
• Deberías ver la ruta H hacia la IP pushada y, tras negociación, el tráfico irá vía Virtual-Access.

Validación del flujo Spoke-to-Spoke

Cuando quieras verificar que un shortcut spoke-to-spoke se haya establecido

1. show ip nhrp / show ipv6 nhrp

• Deben existir mappings dinámicos apuntando al NBMA del peer (2001:DB8:ABCD:3::3).
• En este logs: Vi1 → 192.168.15.2 → 2001:DB8:ABCD:3::3 (ok).

2. show interface virtual-accessX

• Comprueba que la interfaz virtual está UP y tiene counters (y es la que aparece en la ruta H).
• ping desde la IP pushada del Spoke origen hacia la IP pushada del peer (usar source = IP pushada).

• El primer ping forzará el IKE CHILD_SA si no existe y negociará IPsec entre Spokes.

show crypto ipsec sa

• Debe aparecer una entrada en Virtual-AccessX con SAs (in/out packets > 0).

Pequeña nota de hardening y buenas prácticas

• Evita depender indefinidamente de defaults en producción — define crypto ikev2 proposal y crypto ipsec transform-set explícitos.
• Considera set pfs group21 para CHILD SA si requieres PFS.
• Revisa DPD/Timers según SLAs de la red.
• Ajusta MTU/MSS para evitar fragmentación (he usado ip mtu 1400 e ip tcp adjust-mss 1358 esto es correcto).
• Cambia esp-sha-hmac (SHA1) por esp-sha256 o AES-GCM si tu imagen IOS lo soporta.

Jovanny de Jesus…