Sur un pare-feu, IPSec ne fonctionne pas de manière autonome — chaque paquet que le tunnel envoie ou protège doit d'abord passer par le moteur de politique de sécurité. Voici la configuration sur laquelle cette note s'appuie : zones de sécurité et interfaces, paramètres IKE et IPSec, et — la partie qu'une expérience limitée aux routeurs fait manquer — les règles de politique de sécurité qui autorisent séparément le trafic de négociation propre au tunnel et le trafic privé qu'il protè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
Sur un pare-feu, c'est la politique de sécurité qui décide si le trafic de négociation propre au tunnel — et le trafic qu'il protège — est même autorisé à atteindre IPSec.
Sur un routeur, IPSec est largement autonome : diriger le trafic vers une ACL, négocier, c'est fait. Un pare-feu ajoute une couche intermédiaire par conception — chaque paquet, y compris les paquets de négociation IKE et la charge utile encapsulée en ESP elle-même, doit encore passer le moteur de politique de sécurité et ses règles de zone à zone avant qu'IPSec n'ait la moindre chance de le traiter. Cela signifie qu'une configuration IPSec qui fonctionnerait parfaitement sur un routeur — proposition, pair, politique, ACL, tout correct — peut rester là, entièrement configurée sur un pare-feu, et pourtant ne laisser passer aucun paquet, parce que la politique de sécurité l'a refusé avant même qu'IPSec n'ait quoi que ce soit à faire.
Cette note est écrite spécifiquement pour le côté pare-feu : configurer ensemble les zones de sécurité, les règles de politique de sécurité et le VPN IPSec sur un Huawei USG afin que les deux couches s'accordent l'une avec l'autre. Si vous construisez plutôt le tunnel entre un routeur Huawei AR et le pare-feu d'un autre fournisseur, consultez notre guide de configuration d'interopérabilité Huawei-Fortinet ; si un tunnel est déjà actif mais que quelque chose ne va toujours pas, consultez notre organigramme de dépannage de tunnel IPSec — ces deux notes sont écrites du côté routeur de ce même problème, pas du côté pare-feu traité ici.
Deux pare-feu, deux LAN privés, un tunnel IPSec à travers Internet — plus la carte des zones qui décide si tout cela est réellement autorisé à se produire.
Les légendes du schéma restent en anglais pour la clarté technique.
Adressage
| Élément | Valeur (cet exemple) |
|---|---|
| Interface trust de FW1 — GigabitEthernet1/0/0 | 10.1.1.1/24 |
| Interface untrust (publique) de FW1 — GigabitEthernet1/0/1 | 1.1.1.1/24 |
| Interface untrust (publique) de FW2 — le pair du tunnel | 2.1.1.1/24 |
| Sous-réseau protégé derrière FW1 | 10.1.1.0/24 |
| Sous-réseau protégé derrière FW2 | 10.1.2.0/24 |
Affectez les interfaces aux zones, configurez IKE et IPSec, appliquez la politique — puis, l'étape qu'un routeur n'a pas besoin de faire, rédigez les règles de politique de sécurité pour le trafic propre du tunnel et le trafic qu'il protège.
#
firewall zone trust
set priority 85
add interface GigabitEthernet1/0/0
#
firewall zone untrust
set priority 5
add interface GigabitEthernet1/0/1
#
ike proposal 10
authentication-method pre-shared-key
authentication-algorithm sha2-256
encryption-algorithm aes-256
dh group14
prf hmac-sha2-256
#
ike peer huawei
ike-proposal 10
pre-shared-key cipher <same-key-on-both-ends>
remote-address 2.1.1.1
#
ipsec proposal p1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
acl number 3100
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec policy policy1 10 isakmp
security acl 3100
ike-peer huawei
proposal p1
#
interface GigabitEthernet1/0/0
ip address 10.1.1.1 255.255.255.0
#
interface GigabitEthernet1/0/1
ip address 1.1.1.1 255.255.255.0
ipsec policy policy1
#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.254
#C'est la partie qu'une expérience IPSec limitée aux routeurs manque entièrement — deux paires de règles distinctes, pas une seule, et aucune n'est facultative.
security-policy
rule name ike-esp-out
source-zone local
destination-zone untrust
source-address 1.1.1.1 mask 255.255.255.255
destination-address 2.1.1.1 mask 255.255.255.255
action permit
rule name ike-esp-in
source-zone untrust
destination-zone local
source-address 2.1.1.1 mask 255.255.255.255
destination-address 1.1.1.1 mask 255.255.255.255
action permit
rule name private-out
source-zone trust
destination-zone untrust
source-address 10.1.1.0 mask 255.255.255.0
destination-address 10.1.2.0 mask 255.255.255.0
action permit
rule name private-in
source-zone untrust
destination-zone trust
source-address 10.1.2.0 mask 255.255.255.0
destination-address 10.1.1.0 mask 255.255.255.0
action permitCe schéma de règles exact — une paire pour le trafic IKE/ESP propre du tunnel dans la zone local, une paire pour le trafic privé en trust/untrust — provient directement d'un cas de panne réel où le tunnel s'affichait comme établi des deux côtés, alors que les deux LAN privés ne pouvaient toujours pas se joindre, parce que seule la première paire avait été configurée.
Ceux qui transforment une configuration IPSec fonctionnelle en un tunnel qui négocie bien mais ne laisse toujours passer aucun paquet.
SYMPTÔMEdisplay ike sa montre la SA IKE comme établie sur les deux pare-feu, mais rien ne semble jamais se négocier, ou la négociation redémarre constamment.
CAUSELes paquets de négociation IKE (UDP 500/4500) et les paquets du protocole ESP eux-mêmes doivent atteindre le pare-feu et être autorisés, exactement comme tout autre trafic destiné à l'appareil. Si la politique de sécurité n'autorise pas explicitement le trafic UDP 500/4500 et le protocole AH/ESP vers et depuis l'adresse publique du pare-feu lui-même, le tunnel n'a tout simplement aucun chemin pour négocier.
SOLUTIONConfigurez une paire dédiée de règles de politique de sécurité autorisant le trafic UDP 500/4500 et protocole AH/ESP entre l'adresse propre du pare-feu et celle du pair — ceci est distinct de, et s'ajoute à, la règle qui autorise le trafic privé lui-même.
SYMPTÔMEdisplay ike sa montre le tunnel comme entièrement établi des deux côtés, mais les hôtes des deux LAN privés ne peuvent toujours pas se joindre.
CAUSEL'ACL IPSec définit uniquement quel trafic est chiffré et envoyé dans le tunnel — elle ne dit rien sur le fait que le moteur de politique de sécurité autorise réellement ce trafic entre les zones. Sans une règle de politique de sécurité distincte autorisant les sous-réseaux privés entre les zones trust et untrust, le trafic n'atteint jamais le point où IPSec le chiffrerait.
SOLUTIONConfigurez la paire de règles de politique de sécurité trust-vers-untrust et untrust-vers-trust pour les vrais sous-réseaux privés, en plus de l'ACL IPSec — les deux servent des objectifs différents et aucun ne remplace l'autre.
SYMPTÔMEUne règle de politique de sécurité a été écrite en untrust-vers-trust ou trust-vers-untrust pour couvrir le trafic du tunnel, et ça ne fonctionne toujours pas, même si les adresses semblent correctes.
CAUSELe trafic destiné à l'adresse IP du pare-feu lui-même — ce qui est exactement le cas de la négociation IKE et de l'extrémité de terminaison d'ESP — est évalué par rapport à la zone local, quelle que soit l'interface physique ou la zone par laquelle il est arrivé. Une règle écrite avec trust ou untrust comme zone de destination ne correspondra jamais à ce trafic.
SOLUTIONRédigez la paire de règles pour le trafic propre du tunnel avec local comme zone du côté qui est cet appareil, et confirmez-le dans display firewall session table verbose — une session IKE fonctionnelle affiche Zone: local --> untrust (ou l'inverse), pas trust --> untrust.
<FW1> display firewall session table verbose
udp VPN: public --> public ID: a68f5bd4603f01f756c5ab54663
Zone: local --> untrust TTL: 00:02:00 Left: 00:01:58
1.1.1.1:500 --> 2.1.1.1:500 PolicyName: ike-esp-outSYMPTÔMELa phase 1 négocie avec succès dans un mode d'échange lors des tests, puis échoue une fois que la configuration du pair change légèrement, ou une fois passé à un autre mode d'échange.
CAUSEEn tant qu'initiateur, si le ike peer référence explicitement un ike-proposal, c'est exactement cette proposition qui est envoyée pour la négociation. Si elle n'est pas référencée, le mode principal envoie toutes les propositions IKE configurées localement pour que le pair choisisse, tandis que le mode agressif n'envoie que la proposition par défaut — deux comportements différents pour la même ligne de configuration manquante, selon le mode d'échange actif.
SOLUTIONRéférencez toujours un ike-proposal explicite sous le ike peer plutôt que de vous fier à des valeurs par défaut dépendant du mode d'échange, afin que le même ensemble de paramètres soit proposé quel que soit le mode finalement utilisé.
ike peer huawei
ike-proposal 10
remote-address 2.1.1.1SYMPTÔMEUne partie du trafic entre les deux sites passe par le tunnel chiffré comme prévu ; une autre partie du trafic entre ce qui semble être les deux mêmes sous-réseaux est rejetée, ou sort non chiffrée.
CAUSEL'ACL IPSec et les adresses de la règle de politique de sécurité ont été configurées à des moments différents, par des personnes différentes, ou copiées d'exemples différents, et leurs plages de sous-réseaux ne décrivent plus exactement le même trafic. Le trafic qui correspond à la politique de sécurité mais qui sort de la plage de l'ACL IPSec n'est jamais chiffré ; le trafic qui correspond à l'ACL mais qui sort de la plage de la politique de sécurité n'y arrive jamais du tout.
SOLUTIONDéfinissez la règle permit de l'ACL IPSec et les adresses source/destination de la règle de politique de sécurité à partir de la même source de vérité, et revérifiez les deux ensemble chaque fois que l'une ou l'autre change — pas seulement celle qui a été modifiée.
Une SA IKE établie est nécessaire mais pas suffisante — confirmez que ce sont bien les règles de politique de sécurité qui sont réellement touchées, pas seulement présentes.
<FW1> display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------------
151003222 2.1.1.1:500 RD|ST|A v1:2
151003215 2.1.1.1:500 RD|ST|A v1:1
Number of IKE SA : 2
<FW1> display firewall session table verbose
udp VPN: public --> public ID: a68f5bd4603f01f756c5ab54663
Zone: local --> untrust TTL: 00:02:00 Left: 00:01:58
1.1.1.1:500 --> 2.1.1.1:500 PolicyName: ike-esp-out
<FW1> display current-configuration configuration policy-security
security-policy
rule name ike-esp-out
source-zone local
destination-zone untrust
action permit
rule name private-out
source-zone trust
destination-zone untrust
action permitCette note est basée sur une configuration concrète : deux pare-feu Huawei série USG, IPSec IKEv1 basé sur ACL, une paire de sous-réseaux protégés de chaque côté, des règles de politique de sécurité couvrant le tunnel et le trafic privé. Elle ne couvre pas les nuances de configuration spécifiques à IKEv2, l'IPSec VTI (basé sur le routage) sur un pare-feu, la coexistence du NAT avec cette même politique IPSec sur la même interface, la séparation de politique spécifique aux systèmes virtuels (vsys), ni les paires de pare-feu haute disponibilité/actif-actif — chacun de ces sujets modifie suffisamment la configuration pour mériter son propre traitement.
Tirées des mêmes cas de configuration sur lesquels cette note s'appuie.
Oui, toujours les deux. La règle IKE/ESP autorise la négociation propre du tunnel et sa charge chiffrée à atteindre l'appareil (zone local) ; la règle de trafic privé autorise le trafic métier réel à passer de trust à untrust afin qu'IPSec ait quelque chose à chiffrer en premier lieu. L'absence de l'une ou l'autre produit un tunnel qui semble correct dans display ike sa mais qui ne fait toujours rien d'utile.
Local — parce qu'il est destiné à l'adresse IP publique du pare-feu lui-même, et non routé à travers lui. C'est vrai quelle que soit l'interface physique ou la zone à laquelle cette interface a été affectée ; une règle écrite avec trust ou untrust comme zone de destination pour ce trafic ne le correspondra jamais.
Techniquement, le trafic passerait de toute façon, mais un default permit large n'est pas la posture sûre en production que cette note suppose, et cela rend le dépannage bien plus difficile par la suite — les compteurs de hits de display security-policy rule deviennent inutiles quand tout correspond à une seule règle fourre-tout. Configurez quand même les paires de règles spécifiques, et passez à default action deny une fois leur bon fonctionnement confirmé.
Les paramètres IKE et IPSec eux-mêmes — proposition, pair, politique, ACL — sont essentiellement les mêmes concepts sur les deux plateformes. Ce qu'un routeur n'a pas, c'est la couche de politique de sécurité placée devant IPSec : sur un routeur, une fois l'ACL et la configuration de l'interface correctes, le trafic atteint directement IPSec. Sur ce pare-feu, la politique de sécurité doit séparément autoriser à la fois le trafic propre du tunnel et le trafic protégé avant qu'IPSec n'ait la moindre chance d'agir sur l'un ou l'autre. Consultez notre guide de configuration Huawei-Fortinet et notre organigramme de dépannage de tunnel IPSec pour la version côté routeur de cette même logique de tunnel.
Oui, mais la même règle qui régit les routeurs s'applique ici aussi : le NAT est évalué avant IPSec dans l'ordre de transfert, donc l'ACL de correspondance de la politique NAT doit exclure explicitement le trafic destiné aux sous-réseaux protégés du tunnel, sinon ce trafic est traduit et envoyé vers Internet au lieu d'être chiffré dans le tunnel — sans erreur à signaler, si ce n'est un compteur de chiffrement bloqué.
Dites-nous votre disposition de zones et quels sous-réseaux doivent traverser le tunnel, et nous vous aiderons à obtenir les bonnes règles de politique de sécurité du premier coup.