Deux routeurs de succursale Huawei AR (Spoke1, Spoke2) et un routeur Cisco au siège (Hub), formant un réseau DSVPN Over IPSec — tunnels mGRE dynamiques, enregistrement NHRP, et profils IPSec par tunnel permettant aux succursales de communiquer directement entre elles sans passer par le siège.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Les tunnels IPSec ordinaires se multiplient une paire à la fois. DSVPN permet à chaque site d'atteindre tous les autres via un maillage dynamique unique.
Un tunnel IPSec succursale-siège comme ceux de nos autres notes fonctionne bien pour deux sites. Ajoutez une troisième succursale qui doit aussi atteindre les deux premières, et une conception statique point-à-point signifie configurer et maintenir un tunnel séparé pour chaque paire — le siège relayant chaque paquet succursale-à-succursale même quand les deux succursales pourraient se joindre directement. DSVPN (Dynamic Smart VPN) résout cela avec un modèle Hub-Spoke construit sur du GRE multipoint (mGRE) et NHRP : chaque spoke s'enregistre auprès du hub, et dès que deux spokes doivent se parler, ils peuvent construire un tunnel direct — sans que le siège ne relaie le trafic.
Cette note détaille la construction complète d'un DSVPN Over IPSec avec un routeur Cisco comme hub et deux routeurs Huawei AR comme spokes : les interfaces tunnel mGRE, l'enregistrement et l'authentification NHRP, les paramètres IKE/IPSec enveloppés autour du tunnel avec un profil IPSec, et la vérification confirmant que les spokes se trouvent réellement l'un l'autre directement plutôt que de passer par le hub.
Un hub, deux spokes — et une fois NHRP résolu, un tunnel direct entre les spokes eux-mêmes.
Les légendes du schéma restent en anglais pour la clarté technique.
Adressage
| Élément | Spoke1 — Huawei AR | Spoke2 — Huawei AR | Hub — Cisco |
|---|---|---|---|
| Adresse publique (WAN) | 1.1.2.10 | 1.1.3.10 | 1.1.1.10 |
| Adresse de l'interface tunnel | 10.2.1.2 | 10.2.1.3 | 10.2.1.1 |
| Sous-réseau privé | 10.1.1.0/24 | 10.1.2.0/24 | 10.1.0.0/24 |
Paramètres NHRP
| Paramètre | Valeur (cet exemple) |
|---|---|
| NHRP network-id (domaine) | 1000 |
| Clé d'authentification NHRP | huawei12 |
| Intervalle d'enregistrement du spoke | 1800 seconds |
| Holdtime NHRP du hub | 3600 seconds |
Phase 1 — Paramètres de négociation IKE
| Paramètre | Valeur (cet exemple) |
|---|---|
| Version IKE | IKEv1 |
| Mode de négociation | Mode principal |
| Méthode d'authentification | Clé pré-partagée |
| Clé pré-partagée (cet exemple) | huawei@123 — la clé de l'exemple source ; définissez toujours votre propre clé unique. |
| Algorithme de chiffrement | aes-cbc-128 |
| Algorithme d'authentification | sha1 |
| Groupe DH | group5 |
| Durée de vie de la SA | 28800 seconds |
| DPD | Activé (périodique) |
Phase 2 — Paramètres de négociation IPSec
| Paramètre | Valeur (cet exemple) |
|---|---|
| Protocole de sécurité | ESP |
| Mode d'encapsulation | Transport — mGRE fournit déjà le tunnel externe |
| Algorithme de chiffrement | aes-128 |
| Algorithme d'authentification | sha1 |
| Durée de vie de la SA | 3600 secondes (par défaut) |
| PFS | Désactivé |
Le tunnel mGRE, l'enregistrement NHRP et un profil IPSec lié directement à l'interface tunnel — pas de crypto map, pas d'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 profile1Mêmes six étapes, adressage en miroir — les routes statiques de Spoke2 pointent vers le hub et vers 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 profile1L'interface mGRE du hub est le point de rendez-vous multicast auquel chaque spoke s'enregistre — le mappage NHRP dynamique remplace une liste de pairs statique.
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 syntaxe côté Cisco de cette note a été vérifiée sur Cisco IOS Software, C3900e-UNIVERSALK9-M, version 15.2(4)M1 — IOS-XE et ASA utilisent une syntaxe proche mais non identique.
Les tunnels dynamiques Hub-Spoke apportent leurs propres modes de défaillance en plus de ceux d'IPSec ordinaire.
SYMPTÔMEUne conception DSVPN qui fonctionne bien entre appareils Huawei en laboratoire rencontre une question de conformité ou de licence une fois qu'elle est sur le point d'entrer en production avec un hub non-Huawei.
CAUSELe guide de configuration source précise explicitement que DSVPN est une implémentation propriétaire Huawei, et que l'interconnecter avec l'équipement d'un autre fournisseur peut comporter un risque juridique — le guide demande aux ingénieurs de vérifier auprès du bureau local Huawei et du service juridique avant de faire exactement cela. Certains appareils verrouillent également la fonctionnalité DSVPN derrière une licence restreinte par défaut.
SOLUTIONConfirmez que la licence DSVPN est active sur chaque spoke Huawei, et faites valider formellement la combinaison multi-fournisseurs avant sa mise en production — traitez cela comme un point de contrôle du premier jour, pas comme quelque chose découvert en cours de déploiement.
SYMPTÔMEDeux spokes derrière NAT s'enregistrent bien auprès du hub, mais le tunnel direct spoke-à-spoke entre eux ne se monte jamais, ou se monte de façon peu fiable.
CAUSEDSVPN ne prend pas en charge les tunnels spoke-à-spoke lorsque les deux spokes se trouvent derrière le même dispositif NAT les traduisant vers la même adresse, et ne prend pas en charge la traversée NAT lorsque les spokes sont derrière des dispositifs NAT différents avec PAT activé. Le dispositif NAT devant tout participant DSVPN doit également être configuré comme serveur NAT ou NAT statique — DSVPN ne fonctionne pas via un NAT outbound ou inbound ordinaire.
SOLUTIONSi un spoke est derrière NAT, utilisez du NAT statique ou un mappage serveur NAT plutôt qu'un NAT dynamique outbound/inbound, et ne vous attendez pas à un tunnel direct spoke-à-spoke entre deux spokes partageant un dispositif NAT avec PAT activé.
SYMPTÔMEOSPF (ou un autre IGP) tourne sur le tunnel DSVPN, mais les routes entre spokes ne se propagent pas comme elles devraient, ou le raccourci spoke-à-spoke n'est en fait jamais utilisé même après que NHRP se soit résolu.
CAUSELe bon type de réseau et le réglage d'agrégation de routes dépendent de si le déploiement est shortcut ou non-shortcut. Le non-shortcut nécessite le split horizontal et l'agrégation automatique de routes désactivés sur l'interface mGRE du hub, avec le type de réseau OSPF réglé sur broadcast ; le shortcut nécessite l'inverse — split et agrégation activés, avec OSPF réglé sur point-à-multipoint — et une conception BGP shortcut nécessite spécifiquement l'agrégation de routes configurée sur le hub.
SOLUTIONDécidez shortcut ou non-shortcut avant de toucher à la configuration du protocole de routage, puis réglez le type de réseau et le comportement split/agrégation en conséquence — copier les réglages de routage d'une conception sur l'autre casse silencieusement la propagation des routes ou le raccourci spoke-à-spoke.
SYMPTÔMEUne commande ike peer qui fonctionne sur le firmware d'un spoke est rejetée, ou se comporte de façon inattendue, sur un autre spoke de la même famille matérielle.
CAUSELes versions antérieures à V200R008 utilisent ike peer peer-name [ v1 | v2 ] comme une seule commande. V200R008 et ultérieures la scindent en ike peer peer-name plus une commande version { 1 | 2 } séparée, et le comportement par défaut de la version IKE a changé à cette même frontière. remote-name et local-id-type name ont également été renommés remote-id et local-id-type fqdn sur les versions plus récentes.
SOLUTIONVérifiez la version logicielle exacte de chaque spoke avant de copier un bloc de pair IKE entre eux — ne supposez pas que deux spokes exécutent un firmware identique simplement parce qu'ils sont du même modèle matériel.
SYMPTÔMEUn spoke perd sa connexion WAN ou redémarre, mais la table SA du pair continue d'afficher l'ancienne session comme saine pendant un moment, et le trafic destiné à ce spoke n'a nulle part où aller entre-temps.
CAUSESans détection de pair mort, une session IKE/IPSec n'est démontée que lorsque sa durée de vie expire ou qu'une nouvelle négociation échoue — ce qui n'arrive rapidement ni dans un cas ni dans l'autre si le pair a simplement disparu en cours de session.
SOLUTIONActivez le DPD périodique sur le pair IKE de chaque spoke afin qu'une session morte soit détectée et nettoyée rapidement au lieu d'attendre l'expiration complète de la durée de vie de la SA.
[Spoke1-ike-peer-spoke1] dpd type periodicLe vrai test n'est pas la SA hub-spoke — c'est de savoir si deux spokes peuvent construire un tunnel directement entre eux.
[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 le tunnel IPSec ne s'établit pas du tout, vérifiez si la route vers le pair est réellement joignable et si les configurations IPSec des deux extrémités correspondent réellement. Si le tunnel DSVPN lui-même ne s'établit pas alors qu'IPSec semble correct, vérifiez si les configurations DSVPN des deux extrémités — network-id NHRP, clé d'authentification et enregistrement — correspondent réellement.
Cinq questions qui reviennent presque à chaque fois qu'une conception DSVPN Hub-Spoke comme celle-ci est mise en place.
Directement, une fois que NHRP a résolu l'adresse publique du spoke distant. Chaque spoke s'enregistre d'abord auprès du hub — le hub connaît toujours l'adresse réelle de chaque spoke — mais dès qu'un spoke doit envoyer du trafic à un autre, NHRP lui permet de résoudre l'adresse réelle de ce spoke et de construire un tunnel direct. display nhrp peer all sur l'un ou l'autre spoke montre la différence : l'entrée du hub est static, et celle de l'autre spoke bascule en dynamic, marquée route tunnel, une fois le chemin direct établi.
Non — cette conception lie IPSec directement à l'interface tunnel avec tunnel protection ipsec profile, référençant un crypto ipsec profile construit à partir d'un transform-set. Il n'y a ni crypto map ni sélecteur de trafic basé sur une ACL, car l'interface tunnel mGRE elle-même définit ce qui est protégé : tout ce qui emprunte ce tunnel l'est.
Cela peut fonctionner, mais uniquement dans les limites NAT de DSVPN : le dispositif devant le spoke doit faire du NAT statique ou agir comme serveur NAT, pas du NAT outbound/inbound dynamique, et deux spokes partageant un dispositif NAT avec PAT activé ne peuvent pas construire de tunnel direct entre eux.
Le non-shortcut nécessite une route statique ou dynamique sur chaque appareil pointant directement vers l'adresse tunnel de chaque autre appareil — y compris les routes spoke-à-spoke, comme dans l'exemple de route statique de cette note. Le shortcut permet aux spokes d'apprendre d'abord l'accessibilité via le hub et ne construit le tunnel direct spoke-à-spoke qu'à la demande, ce qui nécessite moins de configuration manuelle de routes mais change la façon dont le type de réseau OSPF et l'agrégation de routes doivent être réglés.
Exactement ce que signale le guide source : si le tunnel IPSec ne se monte pas, vérifiez si la route vers le pair est réellement joignable et si les configurations IPSec des deux extrémités correspondent réellement. Si le tunnel DSVPN lui-même ne se monte pas, vérifiez si les configurations DSVPN des deux extrémités correspondent réellement.
Cette note s'appuie sur l'exemple à deux spokes et hub Cisco de DSVPN Over IPSec du guide de configuration source, y compris ses restrictions NAT et son tableau de protocoles de routage. Elle ne couvre pas le DSVPN avec trois spokes ou plus nécessitant des tunnels shortcut simultanés, IKEv2, un hub non-Cisco, ou des protocoles de routage dynamique au-delà des combinaisons RIP/OSPF/BGP documentées par le guide source.
Combien de spokes, quel fournisseur de hub, shortcut ou non — envoyez-le sur WhatsApp et nous vous aiderons à aligner les paramètres sur chaque appareil.