Dos routers de sucursal Huawei AR (Spoke1, Spoke2) y un router Cisco en la sede (Hub), formando una red DSVPN Over IPSec — túneles mGRE dinámicos, registro NHRP y perfiles IPSec por túnel que permiten a las sucursales comunicarse directamente entre sí sin pasar por la sede.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Los túneles IPSec normales se multiplican uno por par. DSVPN permite que cada sitio llegue a todos los demás a través de una única malla dinámica.
Un túnel IPSec de sucursal a sede como los de nuestras otras notas funciona bien para dos sitios. Añada una tercera sucursal que también necesita llegar a las dos primeras, y un diseño estático punto a punto significa configurar y mantener un túnel separado para cada par — con la sede retransmitiendo cada paquete entre sucursales incluso cuando ambas podrían comunicarse directamente. DSVPN (Dynamic Smart VPN) resuelve esto con un modelo Hub-Spoke basado en GRE multipunto (mGRE) y NHRP: cada spoke se registra con el hub, y en cuanto dos spokes necesitan hablar entre sí, pueden construir un túnel directo — sin que la sede reenvíe el tráfico.
Esta nota recorre una construcción completa de DSVPN Over IPSec con un router Cisco como hub y dos routers Huawei AR como spokes: las interfaces de túnel mGRE, el registro y autenticación NHRP, los parámetros IKE/IPSec envueltos alrededor del túnel con un perfil IPSec, y la verificación que confirma que los spokes realmente se encuentran directamente en lugar de pasar por el hub.
Un hub, dos spokes — y una vez que NHRP resuelve, un túnel directo entre los propios spokes.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Direccionamiento
| Elemento | Spoke1 — Huawei AR | Spoke2 — Huawei AR | Hub — Cisco |
|---|---|---|---|
| Dirección pública (WAN) | 1.1.2.10 | 1.1.3.10 | 1.1.1.10 |
| Dirección de la interfaz de túnel | 10.2.1.2 | 10.2.1.3 | 10.2.1.1 |
| Subred privada | 10.1.1.0/24 | 10.1.2.0/24 | 10.1.0.0/24 |
Parámetros NHRP
| Parámetro | Valor (este ejemplo) |
|---|---|
| NHRP network-id (dominio) | 1000 |
| Clave de autenticación NHRP | huawei12 |
| Intervalo de registro del spoke | 1800 seconds |
| Holdtime NHRP del hub | 3600 seconds |
Fase 1 — Parámetros de negociación IKE
| Parámetro | Valor (este ejemplo) |
|---|---|
| Versión IKE | IKEv1 |
| Modo de negociación | Modo principal |
| Método de autenticación | Clave precompartida |
| Clave precompartida (este ejemplo) | huawei@123 — la clave del ejemplo de origen; configure siempre su propia clave única. |
| Algoritmo de cifrado | aes-cbc-128 |
| Algoritmo de autenticación | sha1 |
| Grupo DH | group5 |
| Duración de la SA | 28800 seconds |
| DPD | Habilitado (periódico) |
Fase 2 — Parámetros de negociación IPSec
| Parámetro | Valor (este ejemplo) |
|---|---|
| Protocolo de seguridad | ESP |
| Modo de encapsulación | Transporte — mGRE ya proporciona el túnel externo |
| Algoritmo de cifrado | aes-128 |
| Algoritmo de autenticación | sha1 |
| Duración de la SA | 3600 segundos (por defecto) |
| PFS | Deshabilitado |
El túnel mGRE, el registro NHRP y un perfil IPSec vinculado directamente a la interfaz de túnel — sin crypto map, sin ACL.
<Huawei> system-view
[Huawei] sysname Spoke1
[Spoke1] interface gigabitethernet 1/0/0
[Spoke1-GigabitEthernet1/0/0] ip address 1.1.2.10 255.255.255.0
[Spoke1-GigabitEthernet1/0/0] quit
[Spoke1] ip route-static 0.0.0.0 0.0.0.0 1.1.2.1
[Spoke1] interface Tunnel0/0/0
[Spoke1-Tunnel0/0/0] ip address 10.2.1.2 255.255.255.0
[Spoke1-Tunnel0/0/0] tunnel-protocol gre p2mp
[Spoke1-Tunnel0/0/0] source gigabitethernet 1/0/0
[Spoke1-Tunnel0/0/0] nhrp entry 10.2.1.1 1.1.1.10 register
[Spoke1-Tunnel0/0/0] nhrp network-id 1000
[Spoke1-Tunnel0/0/0] nhrp authentication simple huawei12
[Spoke1-Tunnel0/0/0] nhrp registration interval 1800
[Spoke1-Tunnel0/0/0] quit
[Spoke1] ip route-static 10.1.0.0 255.255.255.0 10.2.1.1
[Spoke1] ip route-static 10.1.2.0 255.255.255.0 10.2.1.3
[Spoke1] ike proposal 5
[Spoke1-ike-proposal-5] encryption-algorithm aes-cbc-128
[Spoke1-ike-proposal-5] authentication-algorithm sha1
[Spoke1-ike-proposal-5] dh group5
[Spoke1-ike-proposal-5] sa duration 28800
[Spoke1-ike-proposal-5] authentication-method pre-share
[Spoke1-ike-proposal-5] quit
[Spoke1] ike peer spoke1 v1
[Spoke1-ike-peer-spoke1] ike-proposal 5
[Spoke1-ike-peer-spoke1] pre-shared-key cipher huawei@123
[Spoke1-ike-peer-spoke1] exchange-mode main
[Spoke1-ike-peer-spoke1] dpd type periodic
[Spoke1-ike-peer-spoke1] quit
[Spoke1] ipsec proposal spoke1
[Spoke1-ipsec-proposal-spoke1] transform esp
[Spoke1-ipsec-proposal-spoke1] esp authentication-algorithm sha1
[Spoke1-ipsec-proposal-spoke1] esp encryption-algorithm aes-128
[Spoke1-ipsec-proposal-spoke1] encapsulation-mode transport
[Spoke1] ipsec profile profile1
[Spoke1-ipsec-profile-profile1] ike-peer spoke1
[Spoke1-ipsec-profile-profile1] proposal spoke1
[Spoke1-ipsec-profile-profile1] quit
[Spoke1] interface tunnel 0/0/0
[Spoke1-Tunnel0/0/0] ipsec profile profile1Los mismos seis pasos, direccionamiento espejado — las rutas estáticas de Spoke2 apuntan al hub y a Spoke1.
<Huawei> system-view
[Huawei] sysname Spoke2
[Spoke2] interface gigabitethernet 1/0/0
[Spoke2-GigabitEthernet1/0/0] ip address 1.1.3.10 255.255.255.0
[Spoke2-GigabitEthernet1/0/0] quit
[Spoke2] ip route-static 0.0.0.0 0.0.0.0 1.1.3.1
[Spoke2] interface Tunnel0/0/0
[Spoke2-Tunnel0/0/0] ip address 10.2.1.3 255.255.255.0
[Spoke2-Tunnel0/0/0] tunnel-protocol gre p2mp
[Spoke2-Tunnel0/0/0] source gigabitethernet 1/0/0
[Spoke2-Tunnel0/0/0] nhrp entry 10.2.1.1 1.1.1.10 register
[Spoke2-Tunnel0/0/0] nhrp network-id 1000
[Spoke2-Tunnel0/0/0] nhrp authentication simple huawei12
[Spoke2-Tunnel0/0/0] nhrp registration interval 1800
[Spoke2-Tunnel0/0/0] quit
[Spoke2] ip route-static 10.1.0.0 255.255.255.0 10.2.1.1
[Spoke2] ip route-static 10.1.1.0 255.255.255.0 10.2.1.2
[Spoke2] ike proposal 5
[Spoke2-ike-proposal-5] encryption-algorithm aes-cbc-128
[Spoke2-ike-proposal-5] authentication-algorithm sha1
[Spoke2-ike-proposal-5] dh group5
[Spoke2-ike-proposal-5] sa duration 28800
[Spoke2-ike-proposal-5] authentication-method pre-share
[Spoke2-ike-proposal-5] quit
[Spoke2] ike peer spoke2 v1
[Spoke2-ike-peer-spoke2] ike-proposal 5
[Spoke2-ike-peer-spoke2] pre-shared-key cipher huawei@123
[Spoke2-ike-peer-spoke2] exchange-mode main
[Spoke2-ike-peer-spoke2] dpd type periodic
[Spoke2-ike-peer-spoke2] quit
[Spoke2] ipsec proposal spoke2
[Spoke2-ipsec-proposal-spoke2] transform esp
[Spoke2-ipsec-proposal-spoke2] esp authentication-algorithm sha1
[Spoke2-ipsec-proposal-spoke2] esp encryption-algorithm aes-128
[Spoke2-ipsec-proposal-spoke2] encapsulation-mode transport
[Spoke2] ipsec profile profile1
[Spoke2-ipsec-profile-profile1] ike-peer spoke2
[Spoke2-ipsec-profile-profile1] proposal spoke2
[Spoke2-ipsec-profile-profile1] quit
[Spoke2] interface tunnel 0/0/0
[Spoke2-Tunnel0/0/0] ipsec profile profile1La interfaz mGRE del hub es el punto de encuentro multicast contra el que cada spoke se registra — el mapeo NHRP dinámico reemplaza una lista de peers estática.
Router#configure
Router(config)#interface gigabitethernet 0/1
Router(config-if)#ip address 1.1.1.10 255.255.255.0
Router(config-if)#exit
Router(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.1
Router(config)#interface tunnel 0
Router(config-if)#ip address 10.2.1.1 255.255.255.0
Router(config-if)#tunnel mode gre multipoint
Router(config-if)#tunnel source gigabitethernet0/1
Router(config-if)#ip nhrp holdtime 3600
Router(config-if)#ip nhrp network-id 1000
Router(config-if)#ip nhrp authentication huawei12
Router(config-if)#ip nhrp map multicast dynamic
Router(config-if)#exit
Router(config)#ip route 10.1.2.0 255.255.255.0 10.2.1.3
Router(config)#ip route 10.1.1.0 255.255.255.0 10.2.1.2
Router(config)#crypto isakmp policy 10
Router(config-isakmp)#hash sha
Router(config-isakmp)#encryption aes 128
Router(config-isakmp)#group 5
Router(config-isakmp)#authentication pre-share
Router(config-isakmp)#lifetime 28800
Router(config-isakmp)#exit
Router(config)#crypto isakmp key huawei@123 address 0.0.0.0 no-xauth
Router(config)#crypto ipsec transform-set tran1 esp-sha-hmac esp-aes 128
Router(cfg-crypto-trans)#mode transport require
Router(cfg-crypto-trans)#exit
Router(config)#crypto ipsec profile profile1
Router(ipsec-profile)#set transform-set tran1
Router(ipsec-profile)#exit
Router(config)#interface tunnel 0
Router(config-if)#tunnel protection ipsec profile profile1
Router(config-if)#exitLa sintaxis del lado Cisco de esta nota se verificó en Cisco IOS Software, C3900e-UNIVERSALK9-M, versión 15.2(4)M1 — IOS-XE y ASA usan una sintaxis parecida pero no idéntica.
Los túneles dinámicos Hub-Spoke traen sus propios modos de fallo además de los del IPSec ordinario.
SÍNTOMAUn diseño DSVPN que funciona bien entre dispositivos Huawei en el laboratorio se topa con una cuestión de cumplimiento o licencia justo cuando está a punto de entrar en producción con un hub que no es Huawei.
CAUSALa guía de configuración original es explícita en que DSVPN es una implementación propietaria de Huawei, y que interconectarla con el equipo de otro fabricante puede conllevar riesgo legal — la guía indica a los ingenieros que consulten con la oficina local de Huawei y el departamento legal antes de hacer exactamente esto. Algunos dispositivos también bloquean la función DSVPN detrás de una licencia restringida por defecto.
SOLUCIÓNConfirme que la licencia DSVPN está activa en cada spoke Huawei, y obtenga la aprobación formal de la combinación entre fabricantes antes de pasar a producción — trate esto como un punto de la lista de verificación del primer día, no algo que se descubre durante el despliegue.
SÍNTOMADos spokes detrás de NAT se registran bien con el hub, pero el túnel directo spoke a spoke entre ellos nunca se levanta, o se levanta de forma poco confiable.
CAUSADSVPN no admite túneles spoke a spoke cuando ambos spokes están detrás del mismo dispositivo NAT que los traduce a la misma dirección, y no admite el traspaso de NAT cuando los spokes están detrás de dispositivos NAT distintos con PAT habilitado. El dispositivo NAT frente a cualquier participante de DSVPN también debe configurarse como servidor NAT o NAT estático — DSVPN no funciona a través de NAT outbound o inbound ordinario.
SOLUCIÓNSi un spoke está detrás de NAT, use NAT estático o un mapeo de servidor NAT en lugar de NAT outbound/inbound dinámico, y no espere un túnel directo spoke a spoke entre dos spokes que comparten un dispositivo NAT con PAT habilitado.
SÍNTOMAOSPF (u otro IGP) corre sobre el túnel DSVPN, pero las rutas entre spokes no se propagan como deberían, o el atajo spoke a spoke nunca llega a usarse aunque NHRP se resuelva.
CAUSAEl tipo de red y el ajuste de agregación de rutas correctos dependen de si el despliegue es shortcut o no shortcut. El no shortcut necesita el split horizontal y la agregación automática de rutas deshabilitados en la interfaz mGRE del hub, con el tipo de red OSPF configurado como broadcast; el shortcut necesita lo contrario — split y agregación habilitados, con OSPF configurado como punto a multipunto — y un diseño BGP shortcut necesita específicamente la agregación de rutas configurada en el hub.
SOLUCIÓNDecida shortcut o no shortcut antes de tocar la configuración del protocolo de enrutamiento, luego configure el tipo de red y el comportamiento de split/agregación para que coincida — copiar los ajustes de enrutamiento de un diseño al otro rompe silenciosamente la propagación de rutas o el atajo spoke a spoke.
SÍNTOMAUn comando ike peer que funciona en el firmware de un spoke es rechazado, o se comporta de forma inesperada, en otro spoke de la misma familia de hardware.
CAUSALas versiones anteriores a V200R008 usan ike peer peer-name [ v1 | v2 ] como un único comando. V200R008 y posteriores lo dividen en ike peer peer-name más un comando version { 1 | 2 } separado, y el comportamiento predeterminado de la versión IKE cambió en ese mismo punto. remote-name y local-id-type name también se renombraron a remote-id y local-id-type fqdn en versiones más nuevas.
SOLUCIÓNVerifique la versión exacta de software en cada spoke antes de copiar un bloque de peer IKE entre ellos — no asuma que dos spokes ejecutan el mismo firmware solo porque son el mismo modelo de hardware.
SÍNTOMAUn spoke pierde su conexión WAN o se reinicia, pero la tabla SA del peer sigue mostrando la sesión antigua como saludable durante un tiempo, y el tráfico destinado a ese spoke no tiene adónde ir mientras tanto.
CAUSASin detección de peer muerto, una sesión IKE/IPSec solo se derriba cuando expira su tiempo de vida o falla una nueva negociación — ninguna de las cuales ocurre rápido si el peer simplemente desapareció a mitad de sesión.
SOLUCIÓNHabilite el DPD periódico en el peer IKE de cada spoke para que una sesión muerta se detecte y limpie con prontitud en lugar de esperar toda la duración de vida de la SA.
[Spoke1-ike-peer-spoke1] dpd type periodicLa verdadera prueba no es la SA hub-spoke — es si dos spokes pueden construir un túnel directo entre sí.
[Spoke1] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
8 1.1.1.10 0 RD|ST 2
6 1.1.1.10 0 RD|ST 1
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
[Spoke1] display nhrp peer all
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
10.2.1.1 32 1.1.1.10 10.2.1.1 static hub
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 05:13:06
Expire time : --
-------------------------------------------------------------------------------
Protocol-addr Mask NBMA-addr NextHop-addr Type Flag
-------------------------------------------------------------------------------
10.2.1.3 32 1.1.3.10 10.2.1.3 dynamic route tunnel
-------------------------------------------------------------------------------
Tunnel interface: Tunnel0/0/0
Created time : 00:00:31
Expire time : 01:59:29
[Spoke1] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
22 1.1.1.3 0 RD|ST 2
15 1.1.1.3 0 RD|ST 1
8 1.1.1.10 0 RD|ST 2
6 1.1.1.10 0 RD|ST 1Si el túnel IPSec no se establece en absoluto, verifique si la ruta hacia el peer es realmente alcanzable y si las configuraciones IPSec de ambos extremos realmente coinciden. Si el túnel DSVPN en sí no se establece aunque IPSec parezca correcto, verifique si las configuraciones DSVPN de ambos extremos — network-id NHRP, clave de autenticación y registro — realmente coinciden.
Cinco preguntas que surgen casi cada vez que se construye un diseño DSVPN Hub-Spoke como este.
Directamente, una vez que NHRP ha resuelto la dirección pública del spoke remoto. Cada spoke se registra primero con el hub — el hub siempre conoce la dirección real de cada spoke — pero en cuanto un spoke necesita enviar tráfico a otro, NHRP le permite resolver la dirección real de ese spoke y construir un túnel directo. display nhrp peer all en cualquiera de los spokes muestra la diferencia: la entrada del hub es static, y la del otro spoke cambia a dynamic, etiquetada route tunnel, una vez que la ruta directa está activa.
No — este diseño vincula IPSec directamente a la interfaz de túnel con tunnel protection ipsec profile, haciendo referencia a un crypto ipsec profile construido a partir de un transform-set. No hay crypto map ni selector de tráfico basado en ACL, porque la propia interfaz de túnel mGRE define qué se protege: todo lo que viaja por ese túnel lo está.
Puede funcionar, pero solo dentro de los límites de NAT de DSVPN: el dispositivo frente al spoke debe hacer NAT estático o actuar como servidor NAT, no NAT outbound/inbound dinámico, y dos spokes que comparten un dispositivo NAT con PAT habilitado no pueden construir un túnel directo entre sí.
El no shortcut necesita una ruta estática o dinámica en cada dispositivo que apunte directamente a la dirección de túnel de cada otro dispositivo — incluidas las rutas spoke a spoke, como en el ejemplo de ruta estática de esta nota. El shortcut permite que los spokes aprendan primero la accesibilidad a través del hub y solo construye el túnel directo spoke a spoke bajo demanda, lo que necesita menos configuración manual de rutas pero cambia cómo deben configurarse el tipo de red OSPF y la agregación de rutas.
Exactamente lo que señala la guía original: si el túnel IPSec no sube, verifique si la ruta hacia el peer es realmente alcanzable y si las configuraciones IPSec de ambos extremos realmente coinciden. Si el túnel DSVPN en sí no sube, verifique si las configuraciones DSVPN de ambos extremos realmente coinciden.
Esta nota se basa en el ejemplo de dos spokes y hub Cisco de DSVPN Over IPSec de la guía de configuración de origen, incluyendo sus restricciones de NAT y su tabla de protocolos de enrutamiento. No cubre DSVPN con tres o más spokes que necesiten túneles shortcut simultáneos, IKEv2, un hub que no sea Cisco, ni protocolos de enrutamiento dinámico más allá de las combinaciones RIP/OSPF/BGP que documenta la guía original.
Cuántos spokes, qué fabricante de hub, con o sin shortcut — envíelo por WhatsApp y le ayudamos a alinear los parámetros en cada dispositivo.