Une passerelle de succursale Huawei série AR utilisant une interface tunnel — et non une ACL — pour transporter un chemin protégé par IPSec vers un routeur Cisco du siège : pourquoi le VTI l'emporte sur l'IPSec basé sur des politiques pour ce cas, la configuration en six étapes, et comment confirmer que le tunnel est réellement protégé.
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
Le couplage à deux routeurs ici est familier — la vraie décision porte sur la façon dont le trafic protégé est défini, pas sur la façon dont le tunnel monte.
La façon habituelle de construire un tunnel IPSec entre une succursale et le siège est d'utiliser une ACL : une règle énumérant les paires de sous-réseaux comptant comme « trafic intéressant » à chiffrer. Cela fonctionne bien pour un petit ensemble fixe de sous-réseaux. Dès qu'une succursale est assez grande — de nombreux sous-réseaux, un trafic qui ne cesse de croître, un réseau qui ne cesse de changer — les directives de Huawei pour ce couplage recommandent de passer plutôt à une interface de tunnel virtuel (VTI) : le trafic sous l'interface tunnel obtient automatiquement la protection IPSec, sans ACL pour définir ce qui compte.
Voici la configuration sur laquelle cette note s'appuie, pourquoi le VTI convient mieux dès qu'une succursale dépasse une poignée de sous-réseaux, et les six pièges qui apparaissent le plus souvent lorsqu'une interface tunnel — et non une ACL — assure la protection.
Une interface tunnel de chaque côté — une véritable interface de couche 3 routable, pas un simple point d'accroche de politique sur un port physique.
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é |
Le chiffrement sous-jacent est le même ; la réponse diffère sur « quel trafic est protégé, et comment cela reste synchronisé avec le réseau ».
| Aspect | IPSec basé sur ACL / politique | Interface de tunnel virtuel (VTI) |
|---|---|---|
| Ce qui définit le trafic protégé | Une ACL énumérant des paires de sous-réseaux source/destination | Tout ce qui est routé vers l'interface tunnel |
| Ajouter un nouveau sous-réseau protégé | Ajouter ou modifier une règle ACL et réappliquer la politique | Ajouter une route — statique ou via un protocole de routage — vers le tunnel |
| Protocoles de routage dynamique à travers le tunnel | Non pris en charge nativement — il n'y a pas d'interface sur laquelle OSPF ou BGP puisse fonctionner | Fonctionne directement — l'interface tunnel est une interface de couche 3 normale |
| Trafic multicast | Nécessite des contournements supplémentaires via GRE ou un profil | Fonctionne sur le tunnel comme sur n'importe quelle interface routée |
| Cas d'usage idéal | Un petit nombre fixe de paires de sous-réseaux | Sites de succursale volumineux ou en croissance, ou sites exécutant déjà du routage dynamique |
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] ospf 2
[RouterA-ospf-2] area 0.0.0.0
[RouterA-ospf-2-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-2-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[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ême logique d'interface tunnel, famille de commandes différente : une interface tunnel en mode ipsec ipv4, crypto isakmp policy pour les attributs de phase 1, crypto ipsec transform-set pour les attributs de phase 2, et un crypto ipsec profile lié à l'interface tunnel via tunnel protection ipsec profile — l'équivalent Cisco de l'application du profil ipsec Huawei sur Tunnel0/0/0.
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)#RouterB ospf 2
RouterB(config-RouterB)#network 10.2.1.0 0.0.0.255 area 0
RouterB(config-RouterB)#network 10.1.2.0 0.0.0.255 area 0
RouterB(config-RouterB)#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.
Le premier est spécifique à la construction d'IPSec sur une interface tunnel ; les autres s'appliquent à ce couplage Huawei-Cisco quelle que soit la méthode utilisée pour monter le tunnel.
SYMPTÔMEL'interface Tunnel0/0/0 s'affiche active, et les pings passent même à travers — mais display ike sa ne montre aucune association de sécurité.
CAUSELes étapes 2 à 5 construisent une interface tunnel et un profil IPSec comme deux objets distincts. Rien ne les relie tant que l'étape 6 n'applique pas explicitement le profil à l'interface. Tant que cette commande n'est pas exécutée, l'interface tunnel se comporte comme n'importe quelle autre interface routable transportant du trafic en clair — « interface active » et « trafic protégé » sont deux faits différents.
SOLUTIONVérifiez que le profil ipsec est appliqué sur l'interface tunnel elle-même, pas seulement défini comme un objet autonome.
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ipsec profile profile1SYMPTÔ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.
Les questions les plus fréquentes sur ce couplage VTI exact.
Non — c'est tout l'intérêt de l'approche par interface de tunnel virtuel. Il n'y a aucune ACL de sélection de trafic ; tout ce que la table de routage envoie vers l'interface tunnel obtient la protection IPSec. Il faut quand même une route normale, statique ou dynamique, pour dire au routeur d'y envoyer ce trafic en premier lieu.
Oui. Le guide de configuration officiel de Huawei pour cet exemple exact montre l'exécution d'OSPF entre les deux adresses d'interface tunnel afin que le sous-réseau privé distant devienne joignable sans route statique — l'un des avantages pratiques du VTI par rapport à l'IPSec basé sur ACL, puisque le tunnel est une interface de couche 3 routable, pas seulement un point d'accroche de politique sur une interface physique.
Si la source de l'interface tunnel a été configurée comme une adresse IP spécifique, le tunnel se rompt la prochaine fois que cette adresse change — ce qui compte sur une succursale avec une IP publique dynamique via DHCP ou PPPoE. Configurez source comme l'interface de sortie elle-même, pas un instantané de son adresse — voir le Piège 4 ci-dessus.
Les paramètres IKE et IPSec ainsi que la logique de l'interface tunnel dans cette note sont des standards neutres vis-à-vis du fournisseur ; seule la syntaxe des commandes de l'autre extrémité change. Ce guide a été vérifié avec un routeur Cisco. Fortinet et d'autres fournisseurs suivent la même logique de phase 1 / phase 2 via un chemin de configuration différent — voir notre note distincte sur Huawei vers FortiGate pour un exemple basé sur des politiques face à un pare-feu.
L'exemple de cette note fonctionne avec PFS désactivé, conformément à la configuration source sur laquelle il s'appuie. Activer PFS ajoute un nouvel échange Diffie-Hellman à chaque renouvellement de clé de phase 2, ce qui résiste mieux au rejeu en cas de compromission de clé, au prix d'un léger coût CPU — à activer pour les segments à sécurité renforcée, tant que les deux extrémités s'accordent sur le même groupe DH.
Cette note s'appuie sur une configuration validée : un routeur Huawei (IKEv1, mode principal, clé pré-partagée, AES-128 / SHA-1) rejoignant un routeur Cisco via une interface de tunnel virtuel. L'IPSec basé sur ACL/politique, IKEv2, le mode agressif, la traversée NAT, et les pairs non-Cisco — FortiGate par exemple, voir notre note complémentaire — changent chacun les détails. Cette note couvre la méthode VTI face à Cisco, pas toutes les combinaisons.
Modèles d'appareils, versions logicielles et si vous penchez pour VTI ou ACL — envoyez-les sur WhatsApp et nous vous aiderons à aligner les paramètres des deux côtés.