Dois roteadores de filial Huawei AR (Spoke1, Spoke2) e um roteador Cisco na matriz (Hub), formando uma rede DSVPN Over IPSec — túneis mGRE dinâmicos, registro NHRP e perfis IPSec por túnel que permitem que as filiais se comuniquem diretamente entre si sem passar pela matriz.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Túneis IPSec comuns se multiplicam um por par. O DSVPN permite que cada site alcance todos os outros através de uma única malha dinâmica.
Um túnel IPSec de filial para matriz como os de nossas outras notas funciona bem para dois sites. Adicione uma terceira filial que também precisa alcançar as duas primeiras, e um projeto estático ponto a ponto significa configurar e manter um túnel separado para cada par — com a matriz retransmitindo cada pacote entre filiais mesmo quando as duas poderiam se comunicar diretamente. O DSVPN (Dynamic Smart VPN) resolve isso com um modelo Hub-Spoke construído sobre GRE multiponto (mGRE) e NHRP: cada spoke se registra no hub, e assim que dois spokes precisam conversar entre si, eles podem construir um túnel direto — sem que a matriz encaminhe o tráfego.
Esta nota percorre uma construção completa de DSVPN Over IPSec com um roteador Cisco como hub e dois roteadores Huawei AR como spokes: as interfaces de túnel mGRE, o registro e autenticação NHRP, os parâmetros IKE/IPSec envolvidos no túnel com um perfil IPSec, e a verificação que confirma que os spokes realmente se encontram diretamente em vez de passar pelo hub.
Um hub, dois spokes — e assim que o NHRP resolve, um túnel direto entre os próprios spokes.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Endereçamento
| Item | Spoke1 — Huawei AR | Spoke2 — Huawei AR | Hub — Cisco |
|---|---|---|---|
| Endereço público (WAN) | 1.1.2.10 | 1.1.3.10 | 1.1.1.10 |
| Endereço da interface de túnel | 10.2.1.2 | 10.2.1.3 | 10.2.1.1 |
| Sub-rede privada | 10.1.1.0/24 | 10.1.2.0/24 | 10.1.0.0/24 |
Parâmetros NHRP
| Parâmetro | Valor (este exemplo) |
|---|---|
| NHRP network-id (domínio) | 1000 |
| Chave de autenticação NHRP | huawei12 |
| Intervalo de registro do spoke | 1800 seconds |
| Holdtime NHRP do hub | 3600 seconds |
Fase 1 — Parâmetros de negociação IKE
| Parâmetro | Valor (este exemplo) |
|---|---|
| Versão IKE | IKEv1 |
| Modo de negociação | Modo principal |
| Método de autenticação | Chave pré-compartilhada |
| Chave pré-compartilhada (este exemplo) | huawei@123 — a chave do exemplo de origem; defina sempre sua própria chave exclusiva. |
| Algoritmo de criptografia | aes-cbc-128 |
| Algoritmo de autenticação | sha1 |
| Grupo DH | group5 |
| Tempo de vida da SA | 28800 seconds |
| DPD | Ativado (periódico) |
Fase 2 — Parâmetros de negociação IPSec
| Parâmetro | Valor (este exemplo) |
|---|---|
| Protocolo de segurança | ESP |
| Modo de encapsulamento | Transporte — o mGRE já fornece o túnel externo |
| Algoritmo de criptografia | aes-128 |
| Algoritmo de autenticação | sha1 |
| Tempo de vida da SA | 3600 segundos (padrão) |
| PFS | Desativado |
O túnel mGRE, o registro NHRP e um perfil IPSec vinculado diretamente à interface de túnel — sem crypto map, sem 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 profile1Os mesmos seis passos, endereçamento espelhado — as rotas estáticas do Spoke2 apontam para o hub e para o 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 profile1A interface mGRE do hub é o ponto de encontro multicast contra o qual cada spoke se registra — o mapeamento NHRP dinâmico substitui uma 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)#exitA sintaxe do lado Cisco desta nota foi verificada no Cisco IOS Software, C3900e-UNIVERSALK9-M, versão 15.2(4)M1 — IOS-XE e ASA usam sintaxe parecida, mas não idêntica.
Os túneis dinâmicos Hub-Spoke trazem seus próprios modos de falha além dos do IPSec comum.
SINTOMAUm design DSVPN que funciona bem entre dispositivos Huawei no laboratório esbarra em uma questão de conformidade ou licenciamento assim que está prestes a entrar em produção com um hub não Huawei.
CAUSAO guia de configuração de origem é explícito ao afirmar que o DSVPN é uma implementação proprietária da Huawei, e que interconectá-lo com equipamentos de outro fabricante pode trazer risco legal — o guia instrui os engenheiros a verificar com o escritório local da Huawei e o departamento jurídico antes de fazer exatamente isso. Alguns dispositivos também bloqueiam o recurso DSVPN atrás de uma licença restrita por padrão.
SOLUÇÃOConfirme se o licenciamento do DSVPN está ativo em cada spoke Huawei, e obtenha a aprovação formal da combinação entre fabricantes antes de entrar em produção — trate isso como um item de checklist do primeiro dia, não algo descoberto durante a implantação.
SINTOMADois spokes atrás de NAT se registram bem no hub, mas o túnel direto spoke a spoke entre eles nunca sobe, ou sobe de forma instável.
CAUSAO DSVPN não suporta túneis spoke a spoke quando os dois spokes estão atrás do mesmo dispositivo NAT que os traduz para o mesmo endereço, e não suporta travessia de NAT quando os spokes estão atrás de dispositivos NAT diferentes com PAT habilitado. O dispositivo NAT na frente de qualquer participante do DSVPN também precisa ser configurado como servidor NAT ou NAT estático — o DSVPN não funciona através de NAT outbound ou inbound comum.
SOLUÇÃOSe um spoke estiver atrás de NAT, use NAT estático ou um mapeamento de servidor NAT em vez de NAT outbound/inbound dinâmico, e não espere um túnel direto spoke a spoke entre dois spokes que compartilham um dispositivo NAT com PAT habilitado.
SINTOMAO OSPF (ou outro IGP) roda sobre o túnel DSVPN, mas as rotas entre spokes não se propagam como deveriam, ou o atalho spoke a spoke nunca chega a ser usado mesmo depois que o NHRP resolve.
CAUSAO tipo de rede e a configuração de agregação de rotas corretos dependem de o deployment ser shortcut ou não shortcut. O não shortcut precisa do split horizontal e da agregação automática de rotas desabilitados na interface mGRE do hub, com o tipo de rede OSPF definido como broadcast; o shortcut precisa do oposto — split e agregação habilitados, com OSPF definido como ponto a multiponto — e um design BGP shortcut precisa especificamente de agregação de rotas configurada no hub.
SOLUÇÃODecida shortcut ou não shortcut antes de mexer na configuração do protocolo de roteamento, depois defina o tipo de rede e o comportamento de split/agregação para corresponder — copiar as configurações de roteamento de um design para o outro quebra silenciosamente a propagação de rotas ou o atalho spoke a spoke.
SINTOMAUm comando ike peer que funciona no firmware de um spoke é rejeitado, ou se comporta de forma inesperada, em outro spoke da mesma família de hardware.
CAUSAVersões anteriores ao V200R008 usam ike peer peer-name [ v1 | v2 ] como um único comando. O V200R008 e versões posteriores dividem isso em ike peer peer-name mais um comando version { 1 | 2 } separado, e o comportamento padrão da versão IKE mudou nesse mesmo ponto. remote-name e local-id-type name também foram renomeados para remote-id e local-id-type fqdn em versões mais novas.
SOLUÇÃOVerifique a versão exata do software em cada spoke antes de copiar um bloco de peer IKE entre eles — não presuma que dois spokes rodam o mesmo firmware só porque são o mesmo modelo de hardware.
SINTOMAUm spoke perde sua conexão WAN ou reinicia, mas a tabela SA do peer ainda mostra a sessão antiga como saudável por um tempo, e o tráfego destinado a esse spoke não tem para onde ir nesse meio tempo.
CAUSASem detecção de peer inativo, uma sessão IKE/IPSec só é derrubada quando seu tempo de vida expira ou uma nova negociação falha — nenhuma das quais acontece rapidamente se o peer simplesmente desapareceu no meio da sessão.
SOLUÇÃOHabilite o DPD periódico no peer IKE de cada spoke para que uma sessão morta seja percebida e limpa prontamente em vez de esperar todo o tempo de vida da SA.
[Spoke1-ike-peer-spoke1] dpd type periodicO verdadeiro teste não é a SA hub-spoke — é se dois spokes conseguem construir um túnel direto entre si.
[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 1Se o túnel IPSec não se estabelecer de forma alguma, verifique se a rota até o peer é realmente alcançável e se as configurações IPSec dos dois lados realmente coincidem. Se o próprio túnel DSVPN não se estabelecer mesmo com o IPSec parecendo correto, verifique se as configurações DSVPN dos dois lados — network-id NHRP, chave de autenticação e registro — realmente coincidem.
Cinco perguntas que surgem quase toda vez que um design DSVPN Hub-Spoke como este é montado.
Diretamente, assim que o NHRP resolve o endereço público do spoke remoto. Cada spoke se registra primeiro no hub — o hub sempre conhece o endereço real de cada spoke — mas assim que um spoke precisa enviar tráfego para outro, o NHRP permite que ele resolva o endereço real desse spoke e construa um túnel direto. display nhrp peer all em qualquer um dos spokes mostra a diferença: a entrada do hub é static, e a do outro spoke muda para dynamic, marcada como route tunnel, assim que o caminho direto está ativo.
Não — este design vincula o IPSec diretamente à interface de túnel com tunnel protection ipsec profile, referenciando um crypto ipsec profile construído a partir de um transform-set. Não há crypto map nem seletor de tráfego baseado em ACL, porque a própria interface de túnel mGRE define o que é protegido: tudo que trafega por esse túnel é protegido.
Pode funcionar, mas apenas dentro dos limites de NAT do DSVPN: o dispositivo na frente do spoke precisa fazer NAT estático ou atuar como servidor NAT, não NAT outbound/inbound dinâmico, e dois spokes compartilhando um dispositivo NAT com PAT habilitado não conseguem construir um túnel direto entre si.
O não shortcut precisa de uma rota estática ou dinâmica em cada dispositivo apontando diretamente para o endereço de túnel de cada outro dispositivo — incluindo rotas spoke a spoke, como no exemplo de rota estática desta nota. O shortcut permite que os spokes aprendam a acessibilidade primeiro através do hub e só constrói o túnel direto spoke a spoke sob demanda, o que precisa de menos configuração manual de rotas, mas muda como o tipo de rede OSPF e a agregação de rotas precisam ser configurados.
Exatamente o que o guia de origem aponta: se o túnel IPSec não subir, verifique se a rota até o peer é realmente alcançável e se as configurações IPSec dos dois lados realmente coincidem. Se o próprio túnel DSVPN não subir, verifique se as configurações DSVPN dos dois lados realmente coincidem.
Esta nota se baseia no exemplo de dois spokes e hub Cisco de DSVPN Over IPSec do guia de configuração de origem, incluindo suas restrições de NAT e sua tabela de protocolos de roteamento. Não cobre DSVPN com três ou mais spokes precisando de túneis shortcut simultâneos, IKEv2, um hub que não seja Cisco, ou protocolos de roteamento dinâmico além das combinações RIP/OSPF/BGP que o guia de origem documenta.
Quantos spokes, qual fabricante do hub, shortcut ou não — mande pelo WhatsApp e a gente ajuda a alinhar os parâmetros em todos os dispositivos.