Une passerelle de succursale Huawei série AR établissant un tunnel IPSec avec un routeur Cisco du siège via Internet public — les étapes de configuration, le plan de données, et cinq problèmes d'interopérabilité qui coupent le trafic même quand le tunnel indique « actif ».
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
J'ai déjà réalisé plusieurs fois exactement ce couplage multi-fournisseurs — Huawei d'un côté, Cisco de l'autre.
Faire monter un tunnel IPSec entre un routeur Huawei et un routeur Cisco n'est généralement pas la partie difficile — les deux côtés établissent la phase 1 et la phase 2 sans trop de drame dès que les paramètres de base correspondent. Ce qui consomme réellement du temps, c'est ce qui se passe après que le tunnel affiche « actif » : du trafic qui ne passe toujours pas, ou un tunnel qui fonctionne un moment puis s'arrête discrètement.
Voici la configuration sur laquelle ce billet s'appuie — une passerelle de succursale Huawei rejoignant une passerelle de siège Cisco via Internet public — ainsi que les cinq problèmes d'interopérabilité qui expliquent la plupart des tickets « ça monte mais ça ne marche pas » que j'ai vus sur ce couplage.
Une interface tunnel de chaque côté, transportant le trafic entre le sous-réseau de la succursale et celui du siège.
Les légendes du schéma restent en anglais pour la clarté technique.
Adressage
| Élément | RouterA — passerelle Huawei de la succursale | RouterB — passerelle Cisco du siège |
|---|---|---|
| Adresse publique (WAN) | 1.1.2.10 | 1.1.1.10 |
| Adresse de l'interface tunnel | 10.2.1.2 | 10.2.1.1 |
| Passerelle du sous-réseau privé | 10.1.1.1 | 10.1.2.1 |
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 |
| DPD | Activé |
Phase 2 — Paramètres de négociation IPSec
| Paramètre | Valeur (cet exemple) |
|---|---|
| Protocole de sécurité | ESP |
| Mode d'encapsulation | Tunnel |
| Algorithme de chiffrement | aes-128 |
| Algorithme d'authentification | sha1 |
| Durée de vie de la SA | 3600 secondes (par défaut) |
| PFS | Désactivé |
Six étapes transforment une simple interface tunnel en une interface réellement protégée par IPSec.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 1.1.2.10 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
[RouterA] ip route-static 0.0.0.0 0.0.0.0 1.1.2.1
[RouterA] interface Tunnel0/0/0
[RouterA-Tunnel0/0/0] ip address 10.2.1.2 255.255.255.0
[RouterA-Tunnel0/0/0] tunnel-protocol ipsec
[RouterA-Tunnel0/0/0] source gigabitethernet 1/0/0
[RouterA-Tunnel0/0/0] destination 1.1.1.10
[RouterA-Tunnel0/0/0] quit
[RouterA] ike proposal 5
[RouterA-ike-proposal-5] encryption-algorithm aes-cbc-128
[RouterA-ike-proposal-5] authentication-algorithm sha1
[RouterA-ike-proposal-5] dh group5
[RouterA-ike-proposal-5] authentication-method pre-share
[RouterA-ike-proposal-5] quit
[RouterA] ike peer RouterA v1
[RouterA-ike-peer-RouterA] ike-proposal 5
[RouterA-ike-peer-RouterA] pre-shared-key cipher huawei@123
[RouterA-ike-peer-RouterA] dpd type periodic
[RouterA-ike-peer-RouterA] dpd msg seq-hash-notify
[RouterA-ike-peer-RouterA] quit
[RouterA] ipsec proposal RouterA
[RouterA-ipsec-proposal-RouterA] transform esp
[RouterA-ipsec-proposal-RouterA] encapsulation-mode tunnel
[RouterA-ipsec-proposal-RouterA] esp authentication-algorithm sha1
[RouterA-ipsec-proposal-RouterA] esp encryption-algorithm aes-128
[RouterA] ipsec profile profile1
[RouterA-ipsec-profile-profile1] ike-peer RouterA
[RouterA-ipsec-profile-profile1] proposal RouterA
[RouterA-ipsec-profile-profile1] quit
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ipsec profile profile1Mêmes cinq ingrédients, famille de commandes différente : crypto isakmp policy remplace la proposition IKE, crypto ipsec transform-set remplace la proposition IPSec, et un crypto ipsec profile lié à l'interface tunnel via tunnel protection ipsec profile remplace l'étape ipsec profile côté Huawei.
RouterB#configure
RouterB(config)#interface gigabitethernet 0/1
RouterB(config-if)#ip address 1.1.1.10 255.255.255.0
RouterB(config-if)#exit
RouterB(config)#interface gigabitethernet 0/2
RouterB(config-if)#ip address 10.1.2.1 255.255.255.0
RouterB(config-if)#exit
RouterB(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.1
RouterB(config)#interface tunnel 0
RouterB(config-if)#ip address 10.2.1.1 255.255.255.0
RouterB(config-if)#tunnel mode ipsec ipv4
RouterB(config-if)#tunnel source gigabitethernet0/1
RouterB(config-if)#tunnel destination 1.1.2.10
RouterB(config-if)#exit
RouterB(config)#crypto isakmp policy 10
RouterB(config-isakmp)#hash sha
RouterB(config-isakmp)#encryption aes 128
RouterB(config-isakmp)#group 5
RouterB(config-isakmp)#authentication pre-share
RouterB(config-isakmp)#exit
RouterB(config)#crypto isakmp key huawei@123 address 0.0.0.0 no-xauth
RouterB(config)#crypto isakmp keepalive 10 periodic
RouterB(config)#crypto ipsec transform-set tran1 esp-sha-hmac esp-aes 128
RouterB(cfg-crypto-trans)#mode tunnel
RouterB(cfg-crypto-trans)#exit
RouterB(config)#crypto ipsec profile profile1
RouterB(ipsec-profile)#set transform-set tran1
RouterB(ipsec-profile)#exit
RouterB(config)#interface tunnel 0
RouterB(config-if)#tunnel protection ipsec profile profile1
RouterB(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.
Ces cinq points expliquent la plupart des tickets « le tunnel est actif mais pas le trafic » et « ça marchait hier » que j'ai vus sur ce couplage exact.
SYMPTÔMELa détection de pair mort (DPD) est activée, et le tunnel se comporte de façon imprévisible au lieu de détecter proprement un pair mort.
CAUSELe format de paquet DPD par défaut de Cisco n'est pas le même que celui par défaut du routeur Huawei. Laissé sur sa valeur par défaut, le côté Huawei ne parle pas réellement le même dialecte DPD que le côté Cisco.
SOLUTIONSur le routeur Huawei, définissez le format de message DPD sur seq-hash-notify pour qu'il corresponde à ce qu'attend le côté Cisco.
[RouterA-ike-peer-RouterA] dpd type periodic
[RouterA-ike-peer-RouterA] dpd msg seq-hash-notifySYMPTÔMEdisplay ike sa (ou show crypto isakmp sa) montre la phase 1 et la phase 2 établies, mais un ping à travers le tunnel échoue, ou seule une partie du trafic passe.
CAUSELorsque le routeur Huawei et l'appareil de l'autre fournisseur utilisent tous deux un algorithme SHA-2 dans la proposition de sécurité IPSec, leurs implémentations de chiffrement/déchiffrement SHA-2 peuvent différer juste assez pour que le tunnel se négocie correctement mais que le plan de données non.
SOLUTIONSur le routeur Huawei, activez le mode de compatibilité SHA-2 pour que les deux extrémités traitent SHA-2 de la même façon.
[RouterA] ipsec authentication sha2 compatible enableSYMPTÔMELe tunnel tombe sans qu'aucune configuration n'ait changé des deux côtés — généralement juste après que l'IP publique de la succursale change lors d'un renouvellement DHCP ou PPPoE.
CAUSELa source de l'interface tunnel a été configurée comme une adresse IP fixe, mais cette adresse est attribuée dynamiquement sur l'interface de sortie. Une fois l'adresse modifiée, la source configurée du tunnel ne correspond plus à la réalité.
SOLUTIONConfigurez source comme l'interface de sortie elle-même, pas son adresse IP actuelle, afin que le tunnel suive l'interface plutôt qu'un instantané de son adresse.
[RouterA-Tunnel0/0/0] source gigabitethernet 1/0/0SYMPTÔMELe pair a été configuré en s'attendant à IKEv1 pour correspondre à une ancienne configuration Cisco, mais la négociation se comporte comme IKEv2 — ou les deux extrémités ne s'accordent pas du tout sur une version.
CAUSEPar défaut, un pair IKE Huawei a IKEv1 et IKEv2 activés tous les deux. Lorsqu'il initie la négociation, il utilise IKEv2 ; lorsqu'il répond, il prend en charge les deux. Le besoin spécifique d'IKEv1 doit être configuré explicitement — cela ne se produit pas automatiquement simplement parce que l'autre extrémité est un ancien équipement Cisco.
SOLUTIONDésactivez explicitement IKEv2 pour que le pair n'initie et n'accepte qu'IKEv1.
[RouterA-ike-peer-RouterA] version 1
[RouterA-ike-peer-RouterA] undo version 2SYMPTÔMEUne commande issue d'un exemple de configuration — remote-name, local-id-type name, ou un pre-shared-key nu — est rejetée, ou se comporte différemment, sur l'appareil devant vous.
CAUSEHuawei a renommé plusieurs commandes de pair IKE selon les versions logicielles. Le comportement fonctionnel est identique ; le mot-clé ne l'est pas.
SOLUTIONFaites correspondre la syntaxe à la version logicielle réellement exécutée avant de copier une ligne de configuration.
| Ancienne syntaxe | Syntaxe actuelle (vérifiez votre version) |
|---|---|
| ike peer peer-name [ v1 | v2 ] | ike peer peer-name + version { 1 | 2 } (V200R008+) |
| remote-name | remote-id (V200R008+) |
| local-id-type name | local-id-type fqdn (V200R008+) |
| pre-shared-key key | pre-shared-key { simple | cipher } key (V200R003C00+) |
Les mots-clés de commande et les numéros de version restent dans leur forme d'origine dans toutes les langues, pour une référence exacte.
« Établi » dans la table des SA est nécessaire mais pas suffisant — vérifiez aussi les compteurs de paquets.
[RouterA] 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 UPSi le tunnel ne s'établit pas du tout, les deux premières choses à vérifier sont toujours les mêmes : la route sous-jacente vers l'adresse publique du pair est-elle réellement joignable, et les configurations des deux extrémités correspondent-elles vraiment, paramètre par paramètre.
Cette note s'appuie sur une configuration validée : un routeur Huawei (IKEv1, mode principal, clé pré-partagée, AES-128 / SHA-1) vers un routeur Cisco. Les combinaisons de fournisseurs, versions logicielles et suites de chiffrement se multiplient vite — IKEv2, mode agressif, traversée NAT, succursale en IP dynamique, ou un fournisseur homologue totalement différent (Fortinet, par exemple) changent chacun les détails. Cette note couvre la combinaison la plus courante, pas toutes.
Modèles d'appareils, versions logicielles et suite de chiffrement que vous essayez d'utiliser — envoyez-les sur WhatsApp et nous vous aiderons à aligner les paramètres des deux côtés.