Un tunnel qui refuse de se former, ou qui monte sans laisser passer le trafic, est l'un des problèmes les plus courants en IPSec site à site. Voici l'ordre de diagnostic qui trouve la panne le plus vite — quoi regarder à chaque étape, les commandes display à exécuter, et les causes qui expliquent la plupart de ces tickets.
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
Je reviens toujours à la même courte séquence de vérifications — non pas parce qu'IPSec est simple, mais parce que ses façons de tomber en panne se répètent.
Un tunnel IPSec qui ne monte pas, ou qui monte sans laisser passer le trafic, est l'un des problèmes les plus courants en connectivité site à site. Le réflexe est de modifier les paramètres des deux côtés à la fois — mais il est bien plus rapide de parcourir les étapes de négociation dans l'ordre : la négociation IKE est-elle seulement déclenchée, la phase 1 (l'IKE SA) aboutit-elle, la phase 2 (l'IPSec SA) aboutit-elle, et c'est seulement ensuite qu'on regarde si le trafic protégé circule réellement.
Voici l'arbre de panne sur lequel ce texte s'appuie, les vérifications pour chaque étape avec les commandes exactes à exécuter, les causes qui reviennent sans cesse une fois passées les premières vérifications, et quelques réponses de FAQ tirées de cas de terrain réels.
Les pannes IPSec se répartissent en exactement deux formes : le tunnel ne monte jamais, ou il monte et quelque chose ne va toujours pas.
Placer d'abord le symptôme sur cet arbre évite beaucoup d'allers-retours par la suite — cela indique laquelle des sections ci-dessous s'applique réellement à ce que vous observez.
Les légendes du schéma restent en anglais pour la clarté technique.
L'échec de négociation de l'IKE SA ou de l'IPSec SA est au cœur de la plupart des pannes IPSec, et mérite d'être analysé directement au regard du processus de négociation. Presque tout le reste de cet arbre — une interface, une route, une ACL, une règle NAT — est une simple erreur de configuration d'une autre fonctionnalité, à traquer dans son propre contexte, pas dans le processus IPSec lui-même.
Quatre étapes, quatre ensembles différents de choses à vérifier — et la commande qui indique à quelle étape vous êtes réellement bloqué.
Si display ike sa n'affiche rien du tout, ne présumez pas que la phase 1 a échoué — vérifiez d'abord si la négociation a même été déclenchée.
<Huawei> display ipsec policy
===========================================
IPSec policy group: "10"
Using interface: GigabitEthernet1/0/0
===========================================
Sequence number: 10
Security data flow: 3100/IPv4
SA trigger mode: Traffic-based // default trigger mode
<Huawei> display ipsec statistics
negotiate about packet statistics:
IKE ctrl packet inbound ok: 0, outbound ok: 0
trigger ok: 0, switch sa: 0, sync sa: 0
// outbound ok = 0 -> no IKE packet has left this router yet
<Huawei> display ipsec interface brief
------------------------------------------------
IPSec policy : policy1
Using interface : GigabitEthernet1/0/0
------------------------------------------------
<Huawei> display acl 3100
Advanced ACL 3100, 1 rule
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 (0 times matched)Trois combinaisons de compteurs différentes sur display ipsec statistics pointent vers trois endroits différents à examiner — à vérifier avant tout le reste.
<Router1> display ipsec statistics
negotiate about packet statistics:
IKE ctrl packet inbound ok: 0, outbound ok: 4
// outbound ok not 0 but the peer's inbound stays 0 -> peer never received it
<Router> display ike peer name 1
------------------------------------------
Remote IP : 1.1.1.1(www.huawei.com)
IKE version : v1
Exchange mode : main on phase 1
Local ID type : IP
Remote ID type : any
NAT-traversal : Enable
<Router> display ike proposal number 10
-------------------------------------------
Authentication Method : PRE_SHARED
Authentication Algorithm : SHA2-256
Encryption Algorithm : AES-256
Diffie-Hellman Group : MODP-2048
Prf Algorithm : HMAC-SHA2-256
-------------------------------------------La phase 1 réussit, display ike sa montre une SA établie, mais il n'y a toujours pas d'IPSec SA — c'est presque toujours l'ACL ou la proposition.
<Huawei> display acl 3100
Advanced ACL 3100, 1 rule
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
// the peer's rule should mirror this: source 10.1.1.0/24 destination 10.1.2.0/24
<Huawei> display ipsec proposal
IPSec proposal name: p1
Encapsulation mode: Tunnel
Transform : ah-esp-new
ESP protocol : Authentication SHA2-HMAC-256
Encryption AES-256
<Huawei> display ipsec policy brief
Policy name Mode ACL Peer name
policy1-100 isakmp 3002/IPv4 peer1
// Perfect forward secrecy: DH group 14 -- must match on both ends if configureddisplay ipsec sa montre une SA établie des deux côtés — cela confirme que le tunnel existe, pas que le trafic l'emprunte.
<Huawei> display ipsec sa
-----------------------------
Flow source : 10.1.0.0/255.255.0.0 0/0
Flow destination : 10.2.0.0/255.255.0.0 0/0
// compare this against the real business subnets, not just "tunnel is up"
<Huawei> display ike peer
NAT-traversal : Enable
<Huawei> display ipsec proposal
Transform : esp-new // must be ESP, not AH, when NAT-T is in play
<Huawei> display ipsec statistics
dropped security packet detail:
authentication: 33, replay: 0
// non-zero authentication drops with SHA-2 in the proposal -> compat mode needed
[Huawei] ipsec authentication sha2 compatible enableUne fois que les quatre étapes ci-dessus ont indiqué où se situe le problème, ces six causes expliquent l'essentiel de ce qui ne va vraiment pas.
SYMPTÔMEL'IKE SA ne se forme jamais — display ike sa reste vide ou montre la connexion bloquée en négociation, et c'est le seul paramètre de phase 1 qui semble encore non confirmé.
CAUSEAvec l'authentification par clé pré-partagée, les clés des deux côtés doivent être identiques, caractère pour caractère. Comme la clé configurée est stockée et affichée sous forme chiffrée, une faute de frappe d'un côté ou de l'autre ne se détecte pas en relisant la configuration active — les deux côtés peuvent chacun sembler « configurés » et pourtant ne pas correspondre.
SOLUTIONRessaisissez délibérément la même clé en clair des deux côtés, plutôt que de faire confiance à une valeur copiée précédemment.
[Router] ike peer huawei
[Router-ike-peer-huawei] pre-shared-key cipher <same-key-on-both-ends>SYMPTÔMEdisplay ike error-info rapporte phase1 proposal mismatch.
CAUSEDans un cas réel avec exactement ce code d'erreur, la proposition IKE d'un routeur utilisait AES-128 tandis que le pair (un appareil d'un autre fournisseur) utilisait AES-256 — un seul paramètre divergent suffit à faire échouer toute la négociation de phase 1.
SOLUTIONComparez display ike proposal côte à côte ; lorsque le pair est d'un autre fournisseur et que vous ne pouvez pas obtenir directement sa configuration, debugging ikev1 all (ou debugging ikev2 all) sur votre propre routeur montre les attributs de proposition réellement envoyés par l'autre côté.
<AR1> display ike error-info
peer port error-reason version error-time
2.1.1.1 500 phase1 proposal mismatch v1 2017-09-05 15:22:32
// debugging ikev1 all on AR1 showed what the peer actually sent:
Attribute ENCRYPTION_ALGORITHM value AES_CBC
Attribute KEY_LENGTH value 256
Attribute HASH_ALGORITHM value SHA2-256
Attribute AUTHENTICATION_METHOD value PRE_SHARED
Attribute GROUP_DESCRIPTION value MODP_2048
// AR1 was configured for AES-128; the peer proposed AES-256 -- align the two
[AR1] ike proposal 10
[AR1-ike-proposal-10] encryption-algorithm aes-256SYMPTÔMEL'IPSec SA ne se négocie pas du tout, ou — dans un hub avec plusieurs succursales — seul le trafic d'une succursale ne passe pas alors que les autres fonctionnent bien.
CAUSELes ACL des deux côtés devraient être des images miroir l'une de l'autre (source et destination inversées) ; sinon, la négociation ne réussit que si la plage de l'initiateur est un sous-ensemble de celle du répondant. Par ailleurs, lorsqu'un hub a plusieurs tunnels de succursale, des plages d'adresses qui se chevauchent entre différentes ACL du même groupe de politiques font que le trafic d'une succursale est silencieusement récupéré par le tunnel d'une autre succursale.
SOLUTIONFaites en sorte que la source/destination de l'ACL se reflètent des deux côtés, et assurez-vous qu'aucune des ACL référencées par le même groupe de politiques IPSec n'a de plages de règles qui se chevauchent.
SYMPTÔMELe tunnel s'affiche comme établi des deux côtés, mais le compteur d'encapsulation sortante ne bouge jamais — aucun paquet chiffré n'est réellement envoyé.
CAUSESur un routeur qui fait aussi du NAT, le NAT s'applique avant IPSec dans l'ordre de transfert. Si l'ACL du NAT correspond toujours au trafic destiné au tunnel, ce trafic est traduit et routé vers Internet au lieu du tunnel — aucune erreur, aucun journal, rien à observer sauf un compteur de paquets figé. Par ailleurs, lorsqu'il y a un équipement NAT entre les deux pairs, les deux côtés doivent activer explicitement la traversée NAT, et le protocole de sécurité doit être ESP — AH ne survit pas à la traduction d'adresse.
SOLUTIONAjoutez une règle deny pour les adresses protégées du tunnel en tête de l'ACL NAT afin que ce trafic ne soit jamais traduit ; activez nat traversal sur les deux pairs IKE lorsqu'un équipement NAT se trouve sur le chemin ; et utilisez ESP, pas AH, dès que le NAT-T est en jeu.
acl number 3300
rule 5 deny ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
rule 10 permit ip
[Router-ike-peer-huawei] nat traversalSYMPTÔMELe tunnel n'est pas en panne pour une raison évidente, mais il oscille — il tombe et se reconstruit — alors que le lien et les deux routeurs vont bien.
CAUSELa détection de pair mort (DPD) doit s'accorder sur la séquence de charge utile de ses propres paquets de maintien en vie. Lorsque l'ordre des messages DPD des deux côtés ne correspond pas, le DPD échoue silencieusement à confirmer que le pair est vivant, et le tunnel est démonté puis reconstruit sur une fausse alerte.
SOLUTIONConfigurez des paramètres DPD identiques des deux côtés — séquence de message, mode de détection, temps d'inactivité, intervalle de retransmission, limite de tentatives.
[Router-ike-peer-huawei] dpd msg seq-hash-notify
[Router-ike-peer-huawei] dpd type periodic
[Router-ike-peer-huawei] dpd idle-time 20
[Router-ike-peer-huawei] dpd retransmit-interval 10
[Router-ike-peer-huawei] dpd retry-limit 4SYMPTÔMELes journaux montrent des événements répétés phase1 hard expiry ou phase2 hard expiry, et le tunnel semble se renégocier plus souvent — ou de façon moins symétrique — que prévu.
CAUSEL'IKE SA et l'IPSec SA portent toutes deux une durée de vie configurée (sa duration, ou le ipsec sa global-duration global). Si les deux côtés ne sont pas configurés avec la même valeur, un côté fait vieillir sa SA et commence à renégocier pendant que l'autre détient encore l'ancienne, ce qui se traduit par une agitation inutile plutôt qu'un renouvellement propre et simultané.
SOLUTIONComparez le champ SA Duration de display ike proposal et la durée de vie équivalente de l'IPSec SA des deux côtés, et égalisez-les avec sa duration ou ipsec sa global-duration.
<sysname> display ike proposal number 10
SA Duration(Seconds) : 86400
<sysname> display ipsec global config
IPSec sa global-duration time-based(seconds) : 3600Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
AH (Authentication Header) fournit l'authentification d'origine des données, la vérification d'intégrité et l'anti-rejeu, mais ne chiffre pas du tout la charge utile — il convient au trafic où la confidentialité importe peu mais où la falsification compte. ESP (Encapsulating Security Payload) fait tout ce que fait AH, en plus de pouvoir chiffrer la charge utile, et peut être configuré pour le chiffrement seul, l'authentification seule, ou les deux. Les deux peuvent être combinés sur le même tunnel ; dans ce cas, ESP est appliqué en premier, puis AH, pour une assurance supplémentaire.
Faites d'abord un Ping pour confirmer la joignabilité du réseau public. Si le tunnel est négocié par IKE, vérifiez display ike sa — si la phase 1 n'est même pas établie, voilà votre réponse. Si la phase 1 semble correcte, attendez environ dix secondes et revérifiez ; l'installation de la SA n'est pas toujours instantanée. Confirmez ensuite que l'interface portant la politique IPSec est bien Up, et seulement après commencez à examiner la configuration IPSec elle-même.
Oui. Le côté à IP fixe configure une politique IPSec basée sur un modèle de politique qui ne nécessite pas de connaître l'adresse du pair à l'avance, et son entrée de pair IKE omet simplement remote-address. Le côté à IP dynamique se configure normalement, en pointant remote-address vers le pair fixe. Le côté dont l'adresse est imprévisible doit être celui qui initie.
Cela signifie généralement qu'une nouvelle succursale essaie de protéger un trafic qui chevauche un flux de données qu'un tunnel existant au hub protège déjà. Le conflit bloque carrément la nouvelle négociation, et ne se résout qu'une fois l'ancien tunnel démonté — ce qu'un redémarrage force. ipsec remote traffic-identical accept permet à un nouveau pair avec une définition de flux protégé identique de prendre rapidement le relais, faisant vieillir l'ancienne SA plutôt que d'être bloqué par elle.
Quatre suspects habituels : la charge CPU d'autres fonctionnalités (défense anti-attaque, autres SA) fonctionnant en parallèle d'IPSec ; une discordance d'ordre de charge utile DPD faisant osciller le tunnel sur de fausses alertes de pair mort ; une perte de chemin Internet ordinaire en amont du tunnel ; et la fragmentation IP — la surcharge d'encapsulation propre à IPSec pousse les paquets au-delà du MTU du chemin, et fragmenter comme réassembler du trafic chiffré coûte du CPU qu'un routeur chargé n'a pas toujours en réserve. Tester avec différentes tailles de ping pour trouver le point de rupture, puis ajuster le MTU de l'interface et tcp adjust-mss, est la solution standard pour ce dernier point.
Cette note s'appuie sur le modèle de classification des pannes IPSec du routeur Huawei série AR et ses commandes display ike sa / ipsec sa / ipsec statistics, ainsi que sur les cas de terrain qui les sous-tendent. Si votre passerelle est d'un autre fournisseur, les commandes exactes changent, mais la logique de négociation sous-jacente — déclenchement, phase 1, phase 2, correspondance ACL, interaction NAT, DPD, durée de vie de la SA — s'applique directement. Elle ne couvre pas en profondeur les cas particuliers spécifiques à IKEv2 comme l'authentification EAP ou par enveloppe numérique, ni les scénarios overlay SD-WAN.
Dites-nous à quelle étape ça bloque — phase 1, phase 2, ou actif mais sans trafic — avec la sortie de display ike sa / display ipsec sa, et nous vous aiderons à l'interpréter.