Un routeur de succursale Huawei série AR construisant un tunnel IPSec basé sur ACL vers un pare-feu Fortinet FortiGate du siège — comment la terminologie des deux fournisseurs pour la version IKE, la suite de chiffrement, PFS et la durée de vie se correspond, la configuration de chaque côté, et 5 pièges d'interopérabilité.
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
Une ligne de commande Huawei et un assistant FortiGate décrivent la même négociation de phase 1 / phase 2 — l'astuce consiste à savoir quel champ correspond à quel champ.
IPSec en soi est une norme IETF neutre vis-à-vis du fournisseur, mais chaque fournisseur nomme ses réglages différemment et les configure par défaut différemment. Coupler un routeur Huawei AR en succursale avec un pare-feu Fortinet FortiGate au siège signifie que le même tunnel doit être décrit une fois en CLI Huawei et une fois dans l'interface web de FortiGate — et les deux surfaces de configuration n'utilisent pas les mêmes mots pour la même chose.
Voici la configuration sur laquelle cette note s'appuie : un routeur de succursale Huawei utilisant l'IPSec basé sur ACL (et non une interface tunnel — voir notre note VTI distincte pour cette variante), un pare-feu de siège FortiGate configuré via son interface graphique, un tableau d'alignement terminologique afin que le même paramètre ne soit pas configuré deux fois sous deux noms différents, et les 5 problèmes d'interopérabilité qui apparaissent le plus souvent sur ce couplage exact.
Une ACL sur le routeur Huawei définit le trafic protégé ; un tunnel IPSec personnalisé FortiGate en fait le miroir via les Phase 2 Selectors.
Les légendes du schéma restent en anglais pour la clarté technique.
Adressage
| Élément | Router — passerelle Huawei de la succursale | FW — passerelle Fortinet du siège |
|---|---|---|
| Adresse publique (WAN) | 1.1.1.1 | 2.1.1.1 |
| Passerelle du sous-réseau privé | 10.1.1.2 | 10.1.2.1 |
Voici l'adressage publié dans le propre tableau de plan de données du guide de configuration source. Si une route statique ou une entrée ACL copiée d'un guide référence un sous-réseau différent de celui de son propre tableau de plan de données, considérez cela comme une erreur de documentation à vérifier, pas une valeur à croire aveuglément — voir le Piège 5 ci-dessous.
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-256 |
| Algorithme d'authentification | sha2-512 |
| Groupe DH | group14 |
| Durée de vie de la SA IKE | 28800 seconds |
| 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-256 |
| Algorithme d'authentification | sha2-512 |
| Durée de vie de la SA IPSec | 3600 seconds |
| PFS | Désactivé |
Même champ, nom différent — et, pour la durée de vie, des unités par défaut différentes que les ingénieurs supposent sans vérifier.
| Terme CLI Huawei | Ce que cela contrôle | Équivalent GUI FortiGate |
|---|---|---|
| ike proposal (encryption-algorithm / authentication-algorithm / dh) | Suite de chiffrement et groupe DH de phase 1 (SA IKE) | Phase 1 Proposal — combinaison d'algorithmes, DH Group |
| ike-proposal sa duration | Durée de vie de phase 1 (SA IKE) | Phase 1 Proposal — Key Lifetime (secondes) |
| ipsec proposal (esp authentication-algorithm / esp encryption-algorithm) | Suite de chiffrement de phase 2 (SA IPSec) | Phase 2 Proposal — Chiffrement / Authentification |
| ipsec policy ... sa duration time-based | Durée de vie de phase 2 (SA IPSec) | Phase 2 Proposal — Key Lifetime, secondes/KBytes/les deux |
| dpd type / dpd msg | Comportement de détection de pair mort et format de paquet | Dead Peer Detection — On Idle / On Demand, sous Phase 1 |
| acl number (advanced ACL, permit rule) | Quel trafic est « intéressant » et est protégé | Phase 2 Selectors — adresse locale/distante |
| ike peer ... v1 | Version du protocole IKE utilisée pour négocier | Section Network / IKE — champ IKE Version (1 ou 2) |
Les noms de menus FortiGate indiqués ici suivent le déroulé de l'interface graphique du guide de configuration Huawei sur lequel s'appuie cette note — les écrans « Authentication », « IKE », « Phase 1 Proposal » et « Phase 2 Selectors / Phase 2 Proposal » sous VPN > IPSec > Tunnels. Le libellé exact peut varier légèrement selon les versions de FortiOS.
Six étapes, pilotées par l'ACL : définissez d'abord le trafic intéressant, puis englobez-le dans une politique IPSec.
<Huawei> system-view
[Huawei] sysname Router
[Router] interface gigabitethernet 0/0/1
[Router-GigabitEthernet0/0/1] ip address 1.1.1.1 255.255.255.0
[Router-GigabitEthernet0/0/1] quit
[Router] interface gigabitethernet 0/0/2
[Router-GigabitEthernet0/0/2] ip address 10.1.1.1 255.255.255.0
[Router-GigabitEthernet0/0/2] quit
[Router] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
[Router] ip route-static 10.2.1.0 255.255.255.0 1.1.1.2
[Router] acl number 3101
[Router-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.2.1.0 0.0.0.255
[Router-acl-adv-3101] quit
[Router] ipsec authentication sha2 compatible enable
[Router] ipsec proposal tran1
[Router-ipsec-proposal-tran1] transform esp
[Router-ipsec-proposal-tran1] esp authentication-algorithm sha2-512
[Router-ipsec-proposal-tran1] esp encryption-algorithm aes-256
[Router-ipsec-proposal-tran1] encapsulation-mode tunnel
[Router] ike proposal 5
[Router-ike-proposal-5] encryption-algorithm aes-cbc-256
[Router-ike-proposal-5] authentication-algorithm sha2-512
[Router-ike-proposal-5] dh group14
[Router-ike-proposal-5] sa duration 28800
[Router-ike-proposal-5] authentication-method pre-share
[Router-ike-proposal-5] quit
[Router] ike peer feita v1
[Router-ike-peer-feita] ike-proposal 5
[Router-ike-peer-feita] pre-shared-key cipher huawei@123
[Router-ike-peer-feita] remote-address 2.1.1.1
[Router-ike-peer-feita] exchange-mode main
[Router-ike-peer-feita] dpd type periodic
[Router-ike-peer-feita] dpd msg seq-hash-notify
[Router-ike-peer-feita] quit
[Router] ipsec policy map1 10 isakmp
[Router-ipsec-policy-isakmp-map1-10] ike-peer feita
[Router-ipsec-policy-isakmp-map1-10] proposal tran1
[Router-ipsec-policy-isakmp-map1-10] security acl 3101
[Router-ipsec-policy-isakmp-map1-10] sa duration time-based 3600
[Router-ipsec-policy-isakmp-map1-10] quit
[Router] interface gigabitethernet 0/0/1
[Router-GigabitEthernet0/0/1] ipsec policy map1
[Router-GigabitEthernet0/0/1] quitVérification du résultat côté Huawei après application :
[Router] display ike proposal number 5
-------------------------------------------
IKE Proposal: 5
Authentication method : pre-shared
Authentication algorithm : SHA2-512
Encryption algorithm : AES-CBC-256
DH group : MODP-2048
SA duration : 28800
PRF : PRF-HMAC-SHA2-256
-------------------------------------------
[Router] display ipsec proposal
Number of proposals: 1
IPsec proposal name: tran1
Encapsulation mode: Tunnel
Transform : esp-new
ESP protocol : Authentication SHA2-HMAC-512
Encryption AES-256FortiGate est ici configuré via son interface web plutôt que la CLI — le guide source sur lequel s'appuie cette note parcourt les écrans de l'assistant, pas la syntaxe des commandes.
Les noms de menus et la disposition des écrans peuvent varier selon les versions de FortiOS ; la séquence des concepts — Network, Authentication, IKE, Phase 1 Proposal, Phase 2 Selectors, Phase 2 Proposal — reste la même dans les versions récentes.
Ceux-ci expliquent la plupart des tunnels qui se montent bien et ne font quand même pas passer le trafic prévu.
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 Fortinet 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é FortiGate.
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é FortiGate.
[Router-ike-peer-feita] dpd type periodic
[Router-ike-peer-feita] dpd msg seq-hash-notifySYMPTÔMESans la correction ci-dessous, ce couplage exact afficherait la phase 1 et la phase 2 comme établies, puis échouerait à faire passer le trafic, ou n'en laisserait passer qu'une partie — le symptôme classique « le tunnel est actif, pas les données ».
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 — SHA2-512 dans cet exemple — 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.
SOLUTIONActivez le mode de compatibilité SHA-2 sur le routeur Huawei comme étape standard dès que SHA-2 figure dans la proposition, plutôt que d'attendre un signalement de trafic défaillant.
[Router] ipsec authentication sha2 compatible enableSYMPTÔMELa phase 1 (IKE) s'établit proprement, mais la phase 2 (mode rapide / SA IPSec) ne se monte jamais, ou se monte et tombe de façon répétée.
CAUSEL'ACL Huawei définit le trafic protégé comme source 10.1.1.0/24 vers destination 10.2.1.0/24 ; les Phase 2 Selectors FortiGate doivent définir l'image miroir exacte — local 10.2.1.0/24 (ou le sous-réseau réel du siège), distant 10.1.1.0/24. Si les deux sélecteurs de trafic ne sont pas symétriques en sens inverse, la correspondance de la proposition de phase 2 échoue même si la phase 1 a réussi.
SOLUTIONVérifiez les sélecteurs de trafic des deux côtés côte à côte avant de dépanner quoi que ce soit d'autre en phase 2 — une incohérence ici est bien plus fréquente qu'une incohérence de chiffrement.
SYMPTÔMELe pair a été configuré en s'attendant spécifiquement à IKEv1, mais la négociation se comporte comme si IKEv2 était en jeu, ou les deux extrémités ne s'accordent pas 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 — comme dans cet exemple, correspondant au champ IKE Version du côté FortiGate réglé sur 1 — doit être configuré explicitement.
SOLUTIONConfigurez explicitement le pair pour v1, et vérifiez que le champ IKE Version côté FortiGate est également réglé sur 1, pas 2.
[Router] ike peer feita v1SYMPTÔMEUne route statique ou une règle ACL copiée d'un guide de configuration référence un sous-réseau qui ne correspond pas au propre tableau d'adressage du guide pour le même scénario.
CAUSELes guides de configuration sont fréquemment construits en adaptant un exemple précédent déjà validé. Une route ou une règle peut se retrouver encore pointée vers un sous-réseau utilisé dans un exemple antérieur différent au lieu de celui que le tableau de plan de données actuel documente réellement.
SOLUTIONRedérivez chaque adresse d'une ACL ou d'une route statique copiée à partir du plan d'adressage de votre propre réseau avant de l'appliquer — ne présumez jamais de la cohérence interne propre à un exemple validé.
« Établi » dans la table des SA est nécessaire mais pas suffisant — vérifiez aussi les compteurs de paquets.
[Router] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
16 2.1.1.1 0 RD|ST 2
14 2.1.1.1 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 — y compris le miroir ACL/Phase 2 Selectors décrit dans le Piège 3.
Les questions les plus fréquentes sur ce couplage Huawei-Fortinet exact.
Les deux peuvent fonctionner en principe, mais l'exemple validé sur lequel cette note s'appuie utilise l'IPSec basé sur ACL côté Huawei, correspondant à un tunnel IPSec personnalisé FortiGate avec des Phase 2 Selectors définis côté GUI. Si vous préférez l'approche interface tunnel (VTI), consultez notre note distincte Huawei-Cisco VTI pour la logique — le même raisonnement piloté par le routage s'applique face à un FortiGate prenant en charge le VPN basé sur le routage.
Parce que cet exemple utilise déjà SHA2-512 sur les propositions IKE et IPSec. La compatibilité SHA-2 entre fournisseurs est exactement le genre de chose qui monte un tunnel correctement mais casse silencieusement le plan de données, donc l'activer d'emblée — plutôt que d'attendre un ticket de trafic défaillant — est le choix par défaut le plus sûr dès que les deux extrémités négocient un algorithme SHA-2.
Sur l'interface FortiGate, Phase 1 Proposal couvre le même terrain qu'une proposition ike Huawei — chiffrement, authentification, groupe DH et durée de vie de clé pour la SA IKE. Phase 2 Proposal couvre le même terrain qu'une proposition ipsec Huawei — chiffrement, authentification et durée de vie pour la SA IPSec. Phase 2 Selectors est l'équivalent FortiGate de l'ACL qui définit le trafic protégé côté Huawei.
Oui, en sens inverse. L'ACL Huawei autorise le trafic du sous-réseau de la succursale vers le sous-réseau du siège ; les Phase 2 Selectors FortiGate doivent définir l'image miroir — sous-réseau du siège en local, sous-réseau de la succursale en distant. Si le sélecteur de trafic de l'un des côtés ne correspond pas en sens inverse à celui du pair, la négociation de phase 2 échoue même si la phase 1 a réussi.
Copiez la syntaxe des commandes, pas l'adressage. Les guides de configuration sont fréquemment adaptés à partir d'autres exemples validés, et une référence de route statique ou de sous-réseau peut se retrouver à pointer vers une adresse restante d'un exemple précédent au lieu de celle réellement utilisée. Redérivez toujours l'adressage à partir de votre propre réseau avant d'appliquer une configuration copiée.
Cette note s'appuie sur une configuration validée : un routeur Huawei (IKEv1, mode principal, clé pré-partagée, AES-256 / SHA2-512, basé sur ACL) rejoignant un pare-feu Fortinet FortiGate. Le libellé des menus FortiOS varie légèrement selon les versions ; IKEv2, le VPN VTI/basé sur le routage côté FortiGate, la traversée NAT, et une succursale en IP dynamique changent chacun davantage les détails. Cette note couvre la méthode basée sur ACL face à Fortinet, pas toutes les combinaisons.
Modèles d'appareils, version de FortiOS 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.