Accueil / Notes techniques / Guide de dépannage pare-feu

Pannes de session, NAT et politique du pare-feu : guide de dépannage sur le terrain

Lorsqu'un pare-feu Huawei USG « ne laisse pas passer le trafic », la panne se situe presque toujours à l'un de ces trois endroits — la politique de sécurité n'a jamais correspondu, la table de sessions montre une anomalie, ou le NAT a traduit la mauvaise chose. Voici l'ordre qui permet de le trouver le plus vite : les commandes display à exécuter à chaque étape, comment lire ce qu'elles renvoient, et les commandes de debugging à utiliser quand les commandes display seules ne suffisent pas.

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

Pourquoi l'ordre compte plus que n'importe quelle commande isolée

Trois formes de panne différentes finissent sous le même ticket — « le pare-feu ne laisse pas passer le trafic » — et chacune a son propre ordre de diagnostic.

Une plainte sur le trafic d'un pare-feu s'accompagne rarement d'un symptôme net. « Ça ne marche pas » peut signifier que la politique de sécurité n'a jamais correspondu au trafic, que la table de sessions montre quelque chose d'étrange une fois qu'une session existe, ou que le NAT a traduit quelque chose qu'il n'aurait pas dû — ou n'a pas traduit ce qu'il aurait dû. Modifier les règles de la couche politique et de la couche NAT en même temps, en espérant que quelque chose fonctionne, est la façon la plus lente de s'en sortir. Traiter les trois catégories dans un ordre fixe — politique de sécurité, puis table de sessions, puis NAT — trouve la vraie panne plus vite, car chaque étape élimine un ensemble distinct de causes avant de passer à la suivante.

Voici cet ordre : les commandes display exactes pour chaque étape et comment lire ce qu'elles renvoient, les commandes de debugging et de capture de paquets à utiliser quand les commandes display seules ne suffisent pas, cinq pièges tirés de cas réels de terrain, et cinq réponses aux questions fréquentes construites de la même façon.

Lisez l'arbre de pannes avant de toucher à la moindre configuration

Une panne de trafic sur un pare-feu se répartit clairement en exactement trois formes — placer le symptôme sur cet arbre en premier vous indique quelle section ci-dessous s'applique réellement.

Chaque branche ci-dessous élimine une couche spécifique. Procéder de haut en bas — politique, puis table de sessions, puis NAT — signifie que vous ne dépannez jamais le NAT en supposant, à tort, que la couche politique était correcte.

Les légendes du schéma restent en anglais pour la clarté technique.

Pour la personne qui signale le problème, les symptômes de politique de sécurité, de table de sessions et de NAT se ressemblent souvent — « ça ne marche pas ». Vérifier les hits avant la table de sessions avant le NAT, dans cet ordre, est ce qui fait réellement gagner du temps : chaque étape donne une réponse claire, oui ou non, sur s'il faut continuer.

Parcourir chaque étape

Trois catégories, trois ensembles différents de choses à examiner — plus les commandes de debugging à utiliser quand les commandes display seules ne suffisent pas.

Étape 1 — La politique de sécurité ne correspond pas

Si le compteur de hits ne bouge jamais, le trafic n'atteint pas la règle que vous pensez — vérifiez ce qu'il correspond réellement.

Exécutez display security-policy rule en le ciblant sur la destination, le protocole et le port réels du trafic. Si HITS reste à 0 sur toutes les règles, le trafic ne correspond pas à cet ensemble de règles comme prévu — il correspond peut-être à une autre règle de priorité supérieure, ou tombe sur la règle par défaut implicite.
Vérifiez l'ordre des règles. Huawei évalue les règles de politique de sécurité de haut en bas et s'arrête à la première correspondance, donc une règle large avec un numéro inférieur peut silencieusement absorber un trafic destiné à une règle plus spécifique située en dessous.
Si la politique doit régir un utilisateur authentifié spécifique, comparez la zone de destination de la politique d'authentification à la zone de destination réelle de la session — une discordance signifie que la session ne correspond jamais à la politique d'authentification, donc la règle de politique de sécurité basée sur l'utilisateur en aval ne s'applique pas non plus.
N'oubliez pas que le trafic intra-zone, ainsi que le trafic de gestion destiné à l'appareil lui-même sous service-manage, peut passer sans jamais afficher de nom de politique correspondant dans la table de sessions. C'est un comportement par défaut du filtrage de paquets attendu, pas la preuve d'une faille dans la couche politique.

<sysname> display security-policy rule destination 1.1.1.1 protocol tcp destination-port 8888
RULE ID RULE NAME                      STATE      ACTION     HITS
-------------------------------------------------------------------------------
1       1                              enable     permit     0
2       2                              enable     permit     0
5       5                              enable     permit     0
6       6                              enable     deny       0
0       default                        enable     deny       0
-------------------------------------------------------------------------------
// HITS stays at 0 on every rule -> this traffic never reached this rule set as you defined it

<sysname> display firewall session table verbose
// cross-check the session's actual destination zone against the authentication policy's configured destination zone

Étape 2 — Table de sessions anormale

Une session n'existe tout simplement pas, ou existe avec des compteurs qui indiquent précisément quelle direction est cassée.

Exécutez display firewall session table verbose pour le flux exact. Si rien ne revient du tout, la panne se situe en amont de la table de sessions elle-même — une route manquante ou un refus de politique de sécurité — et non un problème de table de sessions.
Si une session existe, lisez les compteurs de paquets/octets dans les deux sens (les lignes <-- et -->). Des comptages non nuls des deux côtés confirment que les chemins aller et retour atteignent bien cet appareil — la signature d'un flux sain.
Si une direction reste bloquée à 0 paquet/octet pendant que l'autre bouge, c'est la signature d'un routage asymétrique ou d'un appareil en aval qui rejette le trafic de retour — pas une panne de politique locale ou de NAT, et pas la peine de continuer à chercher sur cet appareil.
Notez le champ Zone de la session. Le trafic de contrôle IKE/IPSec destiné à l'appareil lui-même apparaît dans la zone local, pas dans la zone à laquelle on s'attendrait d'après l'interface d'arrivée physique — source fréquente de confusion quand un tunnel VPN partage le même pare-feu.

<sysname> display firewall session table verbose source global 10.107.7.23 destination global 10.3.8.211 destination-port global 80
tcp  VPN: public --> public  ID: a38f5d6f74b701cf56ec2a0d
Zone: untrust --> trust  TTL: 00:20:00  Left: 00:17:57
Interface: Eth-Trunk0  NextHop: 0.0.0.0  MAC: 0000-0000-0000
<--packets: 10 bytes: 703 -->packets: 10 bytes: 703
10.107.7.23:47150 --> 10.3.8.211:80  PolicyName: 1
// non-zero packet count in both directions -> forward and return path both reach this device, networking is normal

// the same command on a failing flow instead shows:
<--packets: 0 bytes: 0 -->packets: 12 bytes: 840
// one direction stuck at 0 -> asymmetric routing or a downstream drop on the return path, not a local fault

<sysname> display firewall session table verbose
udp  VPN: public --> public  ID: a68f5bd4603f01f756c5ab54663
Zone: local --> trust  TTL: 00:02:00  Left: 00:01:58
// IKE/IPSec control traffic to the device itself lands in the local zone, not the interface's usual zone

Étape 3 — Problème de NAT

Les pannes de NAT ont tendance à se cacher à l'un de ces trois endroits : la mauvaise adresse configurée dans la politique, l'épuisement des ports sur un pool PAT, ou une fonctionnalité sans rapport qui rejette silencieusement le paquet déjà traduit.

Confirmez que l'adresse configurée dans la politique de sécurité est bien l'adresse réelle pour ce sens. Dans un scénario de source-NAT, l'adresse source de la politique doit être l'adresse pré-NAT ; dans un scénario de destination-NAT, l'adresse de destination de la politique doit être l'adresse post-NAT. Configurer le mauvais côté de cette paire est invisible tant que vous ne tracez pas réellement une session.
Si la traduction elle-même semble échouer par intermittence quand la charge augmente, vérifiez display nat port conflict pour un historique de conflits croissant lié à un groupe d'adresses spécifique.
N'oubliez pas que les pools en mode PAT permettent à une seule IP publique de dépasser le plafond de sessions brut par IP grâce à la réutilisation des ports, mais la probabilité de conflit augmente avec le taux de réutilisation — les recommandations de terrain limitent cela à environ 200 000 sessions par IP publique comme plafond pratique, pas théorique.
Si le NAT et le routage semblent tous deux corrects mais que le trafic est toujours rejeté, vérifiez display firewall statistic system discard avant de supposer que le NAT lui-même est en cause — une fonctionnalité anti-attaque (la détection d'usurpation IP en est un exemple courant) peut rejeter silencieusement des paquets d'une manière qui ressemble exactement, de l'extérieur, à un problème de NAT ou de session.

[sysname-diagnose] display nat port conflict
The history data of port conflict, Slot: 1 CPU: 0
2015-11-19 16:03:53 vsys:public protocol:17
192.168.1.1:2048[10.2.2.2:23878]-->8.8.8.8:53
pool:addressgroup1 porthash:**********

[FW] nat address-group addressgroup2
[FW-address-group-addressgroup2] mode no-pat global
[FW-address-group-addressgroup2] section 10.2.2.2
[FW-address-group-addressgroup2] route enable

<sysname> display firewall statistic system discard
Discard statistic information:
                IP header field invalid packets discarded:5
                       TCP session miss packets discarded:7
                   ATK packets discarded：77
// rising ATK-discard count with NAT/session otherwise healthy -> check anti-attack false positives, e.g. IP-spoofing detection

Points de débogage : quand les commandes display ne suffisent pas

Une fois que les étapes ci-dessus vous ont indiqué où se situe le problème mais pas pourquoi, voici l'ordre pour recourir au debugging et à la capture de paquets.

Activez d'abord terminal monitor et terminal debugging — sans les deux, la sortie de debugging ne s'affichera pas du tout dans votre session.
debugging ikev1 all / debugging ikev2 all associé à debugging ipsec all permet de circonscrire une panne liée à IPSec jusqu'à l'échange de négociation exact, une fois que display ike sa / display ipsec sa seuls ne l'ont pas expliqué.
Pour un flux spécifique, limitez une capture de paquets à une ACL et une seule interface plutôt que de tout capturer — cela garde le fichier de capture lisible et le coût CPU maîtrisé.
Une fois que vous avez une découverte qui mérite d'être escaladée, exportez un ensemble complet de diagnostics plutôt que de redécrire le symptôme de mémoire dans un ticket.

<sysname> terminal monitor
<sysname> terminal debugging
<sysname> debugging ikev1 all
<sysname> debugging ipsec all

[sysname] acl 3100
[sysname-acl-adv-3100] rule 5 permit ip source 10.1.1.1 0 destination 10.2.1.1 0
[sysname] packet-capture ipv4-packet 3100 interface GigabitEthernet 1/0/1
[sysname] packet-capture startup packet-num 1500
[sysname] packet-capture queue 0 to-file 1.cap

<sysname> display diagnostic-information dia-info.txt
<sysname> save logfile all

5 pièges tirés de cas réels de panne

Une fois que les trois étapes ci-dessus vous ont indiqué où se situe le problème, voici les pièges spécifiques qui reviennent constamment une fois rendu là.

1. Les adresses de la politique de sécurité doivent être l'adresse réelle, pas celle à laquelle on s'attendrait

SYMPTÔMELe trafic est rejeté même si une règle de politique de sécurité semble, sur le papier, l'autoriser — dans un scénario où le NAT est également configuré sur le même chemin.

CAUSELa politique de sécurité évalue toujours l'adresse réelle pour ce sens, pas celle qui semble intuitive : dans un scénario de source-NAT, l'adresse source de la politique doit être l'adresse pré-NAT, et dans un scénario de destination-NAT, l'adresse de destination de la politique doit être l'adresse post-NAT. Configurer le mauvais côté de cette paire produit une règle qui semble correcte et qui pourtant ne correspond jamais.

SOLUTIONRenseignez l'adresse de la politique avec l'adresse réelle pré- ou post-NAT, correspondant au sens de la traduction — pas l'adresse qu'un utilisateur ou la documentation publique du service référencerait.

[FW] nat address-group addressgroup2
[FW-address-group-addressgroup2] mode no-pat global
[FW-address-group-addressgroup2] section 10.2.2.2
[FW-address-group-addressgroup2] route enable
// security-policy source-address for this flow must reference the pre-NAT address, not 10.2.2.2

2. Le trafic de zone locale et intra-zone peut passer sans jamais afficher de politique correspondante

SYMPTÔMEdefault action deny est configuré et aucune règle explicite de politique de sécurité n'existe, pourtant le trafic entre interfaces de la même zone — ou le trafic de gestion vers l'appareil lui-même — passe toujours.

CAUSELe trafic intra-zone correspond bien toujours au chemin d'évaluation de la politique de sécurité, mais sous le comportement par défaut du filtrage de paquets, il n'affiche pas de nom de politique correspondant à moins qu'une règle détaillée avec zone source et zone de destination explicitement configurées ne soit présente. Par ailleurs, lorsque service-manage enable est actif sur une interface, le trafic de gestion destiné à la zone Local contourne entièrement la correspondance de la politique de sécurité — l'autorisation de filtrage de paquets pour ce trafic est décidée par service-manage, pas par le moteur de politique.

SOLUTIONNe comprenez pas « pas de nom de politique dans la session » comme « rien ne filtre ceci ». Si vous avez besoin de visibilité ou de contrôle sur le trafic intra-zone, ajoutez une règle détaillée avec la zone source et la zone de destination correspondantes explicitement définies ; gérez délibérément les services ouverts sous service-manage, puisque ce chemin contourne le moteur de politique par conception.

3. Une politique basée sur l'utilisateur a aussi besoin d'une zone de destination de politique d'authentification correspondante

SYMPTÔMEUne règle de politique de sécurité configurée pour refuser le trafic d'un utilisateur authentifié spécifique ne prend pas effet — l'utilisateur est confirmé en ligne, mais son trafic n'est pas bloqué.

CAUSELa zone de destination de la politique d'authentification ne correspond pas à la zone de destination réelle de la session, donc la session ne correspond jamais à la politique d'authentification en premier lieu — et une règle de politique de sécurité basée sur l'utilisateur en aval n'a jamais l'occasion de s'appliquer non plus, peu importe si elle est écrite correctement.

SOLUTIONComparez display firewall session table verbose avec la configuration de la politique d'authentification ; si la zone de destination doit couvrir plus d'une zone, définissez-la sur any, puis vérifiez à nouveau que le compteur de hits de la règle basée sur l'utilisateur commence réellement à bouger.

4. La réutilisation des ports d'un pool d'adresses NAT a un plafond pratique, pas seulement théorique

SYMPTÔMELe NAT fonctionne bien sous faible charge, puis les sessions via un pool PAT déjà fonctionnel commencent à échouer par intermittence ou à être rejetées à mesure que le trafic augmente.

CAUSELe mode PAT permet à une seule IP publique de dépasser sa limite brute de 63 488 sessions grâce à la réutilisation des ports, mais la probabilité d'un conflit de port augmente avec le taux de réutilisation. La pratique de terrain limite généralement cela à environ 200 000 sessions par IP publique comme plafond de fonctionnement, bien en deçà de tout maximum théorique.

SOLUTIONVérifiez display nat port conflict pour un historique de conflits croissant avant de supposer que la configuration du pool elle-même est défectueuse ; si une seule IP publique est véritablement surchargée, ajoutez davantage d'adresses au pool ou répartissez le trafic sur des IP publiques supplémentaires.

[sysname-diagnose] display nat port conflict
The history data of port conflict, Slot: 1 CPU: 0
2015-11-19 16:03:53 vsys:public protocol:17
192.168.1.1:2048[10.2.2.2:23878]-->8.8.8.8:53
pool:addressgroup1 porthash:**********

5. Un faux positif anti-attaque peut ressembler exactement à une panne de NAT ou de session

SYMPTÔMEUn mappage NAT qui fonctionnait de manière fiable depuis longtemps cesse soudainement de fonctionner, souvent sur un pare-feu à double sortie, sans aucun changement de configuration côté NAT ou routage.

CAUSEUne fonctionnalité anti-attaque — la détection d'usurpation IP en est un exemple courant — peut commencer à rejeter silencieusement des paquets qui déclenchent ses heuristiques, sans symptôme au niveau NAT ou session à pointer directement. De l'extérieur, cela se présente de manière identique à une panne de NAT ou de routage.

SOLUTIONVérifiez display firewall statistic system discard pour un comptage de rejets ATK en hausse avant de passer plus de temps sur une configuration NAT ou de table de sessions déjà correcte ; désactivez ou ajustez la fonctionnalité anti-attaque spécifique une fois confirmé, plutôt que de désactiver l'anti-attaque en bloc.

<sysname> display firewall statistic system discard
Discard statistic information:
                IP header field invalid packets discarded:5
                       TCP session miss packets discarded:7
                   ATK packets discarded：77

Cinq questions qui reviennent constamment

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.

display firewall session table ne renvoie absolument rien pour ce trafic — par où commencer ?

Confirmez d'abord l'accessibilité de la route, puis vérifiez si la politique de sécurité autorise réellement le trafic avec display security-policy rule et son compteur HITS. Une session qui n'a jamais été créée signifie presque toujours que le paquet n'a jamais atteint l'appareil, ou a été refusé avant même qu'une session ne puisse être construite — pas un bug de la table de sessions.

Le compteur HITS de la règle que j'attends n'augmente jamais. Qu'est-ce que cela m'indique réellement ?

Cela signifie que le trafic correspond à autre chose — une autre règle de priorité supérieure, ou la règle par défaut implicite — avant même d'atteindre la règle que vous surveillez. Vérifiez l'ordre des règles et affinez les conditions de correspondance ; une règle dont le compteur de hits reste à zéro est rarement « cassée », elle n'est généralement tout simplement pas la règle réellement évaluée.

Pourquoi le trafic passe-t-il encore alors que je n'ai configuré aucune règle de politique de sécurité et que default action est deny ?

Cela ne s'applique qu'au trafic intra-zone et au trafic de gestion de zone Local sous service-manage. Le trafic intra-zone est toujours évalué par le moteur de politique mais n'affiche pas de nom de politique correspondant sous le comportement par défaut du filtrage de paquets, sauf si une règle détaillée existe ; le trafic service-manage vers l'appareil lui-même contourne entièrement le moteur de politique par conception. Aucun des deux n'est un bug — les deux sont un comportement par défaut documenté.

Quelle est réellement la différence entre un problème de table de sessions et un problème de politique, si un ticket dit simplement « le trafic ne fonctionne pas » ?

Aucune session du tout dans display firewall session table verbose signifie que le trafic n'a jamais dépassé la couche politique — vérifiez d'abord les hits. Une session qui existe, avec les compteurs de paquets/octets d'une direction bloqués à 0 pendant que l'autre bouge, signifie que la politique a déjà laissé passer le trafic et que le vrai problème est un routage asymétrique ou un rejet en aval — ce n'est pas du tout un problème de politique, et cela ne vaut pas la peine de retoucher la configuration de la politique.

Quand dois-je passer des commandes display au debugging ?

Une fois que les commandes display vous ont indiqué à quelle étape ça bloque mais pas pourquoi — par exemple, une négociation IKE que display ike sa montre comme absente, sans raison claire côté politique ou routage. Activez d'abord terminal monitor et terminal debugging, puis exécutez la commande de debugging ciblée pour cette fonctionnalité (debugging ikev1 all, debugging ipsec all, etc.) avec une capture de paquets limitée, et exportez un ensemble complet de diagnostics avec display diagnostic-information et save logfile all avant d'escalader.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'appuie sur le jeu de commandes de table de sessions, de politique de sécurité et de NAT du pare-feu Huawei série USG, ainsi que sur les cas de panne de terrain qui les sous-tendent. Elle ne couvre pas les pannes au niveau des profils UTM (IPS, antivirus, filtrage d'URL en tant que fonctionnalités d'inspection de contenu plutôt que de correspondance de politique), les cas particuliers de basculement haute disponibilité/actif-actif, ni en profondeur l'héritage de politique spécifique aux systèmes virtuels (vsys) — ces sujets ont une portée suffisamment différente pour mériter leur propre traitement.

Bloqué sur une panne de pare-feu spécifique ?

Dites-nous à quelle étape ça bloque — politique, table de sessions ou NAT — avec la sortie de display security-policy / display firewall session table, et nous vous aiderons à l'interpréter.

WhatsApp avec un ingénieur →