Home / Notes / Firewall Troubleshooting Guide
NOTES · FIREWALL TROUBLESHOOTING

Firewall Session, NAT and Policy Faults: A Field Troubleshooting Guide

When a Huawei USG firewall “won't pass traffic,” the fault almost always sits in one of three places — the security policy never matched, the session table shows something abnormal, or NAT translated the wrong thing. This is the order that finds it fastest: the display commands to run at each stage, how to read what comes back, and the debugging commands worth reaching for when display output alone isn't enough.

By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026

Why the Order Matters More Than Any Single Command

Three different failure shapes get filed under the same ticket — “the firewall won't pass traffic” — and each one has its own diagnostic order.

A firewall traffic complaint rarely comes with a clean symptom attached. “It doesn't work” can mean the security policy never matched the traffic in the first place, the session table shows something odd once a session does exist, or NAT translated something it shouldn't have — or didn't translate what it should have. Changing rules on the policy layer and the NAT layer at the same time, hoping something sticks, is the slowest way through this. Working the three categories in a fixed order — security policy, then session table, then NAT — finds the actual fault faster, because each stage rules out a distinct set of causes before you move on to the next.

What follows is that order: the exact display commands for each stage and how to read what comes back, the debugging and packet-capture commands worth reaching for once display output alone isn't enough, five gotchas pulled from real field fault cases, and five FAQ answers built the same way.

Read the Fault Tree Before You Touch Any Configuration

A firewall traffic fault splits cleanly into exactly three shapes — placing the symptom on this tree first tells you which section below actually applies.

Each branch below rules out a specific layer. Working top to bottom — policy, then session table, then NAT — means you're never troubleshooting NAT because you assumed the policy layer was fine.

Firewall Traffic Fault 1 · Security Policy Not Matching 2 · Session Table Abnormal 3 · NAT Problem HITS stays at 0matched a higher-priority rule, or the implicit default No policy name shown at allintra-zone / Local-zone traffic — expected, not a bypass No session created at allroute missing, policy deny, blacklist, session-limit reached Session exists, one direction is 0asymmetric routing, or a downstream drop on the return path NAT rule never hitspolicy source/dest isn't the real pre/post-NAT address Translation works, traffic still dropsPAT port conflict, or an anti-attack feature discarding it

Diagram labels are kept in English for engineering clarity.

Security policy, session table and NAT symptoms often look identical to the person reporting them — “it doesn't work.” Checking hits before session table before NAT, in that order, is what actually saves time: each stage gives a conclusive yes-or-no on whether to keep going.

Working Through Each Stage

Three categories, three different sets of things to look at — plus the debugging commands worth reaching for once display output alone isn't enough.

Stage 1 — Security Policy Not Matching

If the hit counter never moves, the traffic isn't reaching the rule you think it is — check what it's actually matching instead.

  1. Run display security-policy rule scoped to the traffic's real destination, protocol and port. If HITS stays at 0 across every rule, the traffic isn't hitting this rule set the way you expect — it may be matching a different, higher-priority rule, or falling through to the implicit default rule.
  2. Check rule order. Huawei evaluates security-policy rules top to bottom and stops at the first match, so a broad rule with a lower number can silently swallow traffic meant for a more specific rule sitting below it.
  3. If the policy is meant to govern one specific authenticated user, cross-check the authentication policy's destination zone against the session's actual destination zone — a mismatch there means the session never hits the authentication policy, so the user-based security-policy rule downstream never gets applied either.
  4. Remember that intra-zone traffic, and management traffic destined to the device itself under service-manage, can pass without ever showing a matched policy name in the session table. That's expected default packet-filter behavior, not evidence the policy layer has a hole in it.
<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

Stage 2 — Session Table Abnormal

A session either doesn't exist at all, or exists with counters that tell you exactly which direction is broken.

  1. Run display firewall session table verbose for the exact flow. If nothing comes back at all, the fault sits upstream of the session table itself — a missing route or a security-policy deny — not a session-table problem.
  2. If a session exists, read the packet/byte counters in both directions (the <-- and --> lines). Non-zero counts on both sides confirm the forward and return path both actually reach this device — the signature of a healthy flow.
  3. If one direction stays stuck at 0 packets/bytes while the other moves, that's the signature of asymmetric routing or a downstream device dropping the return traffic — not a local policy or NAT fault, and not worth chasing on this device any further.
  4. Note the Zone field on the session. IKE/IPSec control traffic destined to the device itself shows up in the local zone, not the zone you'd expect from the interface it physically arrived on — a common source of confusion when a VPN tunnel shares the same firewall.
<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

Stage 3 — NAT Problem

NAT faults tend to hide in one of three places: the wrong address configured in the policy, port exhaustion on a PAT pool, or an unrelated feature silently discarding the already-translated packet.

  1. Confirm the address configured in the security policy is the real address for this direction. In a source-NAT scenario the policy's source address must be the pre-NAT address; in a destination-NAT scenario the policy's destination address must be the post-NAT address. Configuring the wrong side of that pair is invisible until you actually trace a session.
  2. If translation itself seems to intermittently fail as load rises, check display nat port conflict for a rising conflict history tied to a specific address-group.
  3. Remember that PAT-mode pools let one public IP exceed the raw per-IP session ceiling through port reuse, but conflict probability rises with the reuse rate — field guidance keeps it to roughly 200,000 sessions per public IP as a practical ceiling, not the theoretical one.
  4. If NAT and routing both look correct but traffic still drops, check display firewall statistic system discard before assuming NAT itself is at fault — an anti-attack feature (IP-spoofing detection is a common one) can silently discard packets in a way that looks exactly like a NAT or session problem from the outside.
[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

Debug Points: When Display Commands Aren't Enough

Once the stages above have told you where the problem sits but not why, this is the order to reach for debugging and packet capture.

  1. Enable terminal monitor and terminal debugging first — without both, debugging output won't print to your session at all.
  2. debugging ikev1 all / debugging ikev2 all plus debugging ipsec all narrow an IPSec-adjacent fault down to the exact negotiation exchange, once display ike sa / display ipsec sa alone haven't explained it.
  3. For a specific flow, scope a packet capture to an ACL and a single interface rather than capturing everything — it keeps the capture file readable and the CPU cost contained.
  4. Once you have a finding worth escalating, export a full diagnostic bundle rather than re-describing the symptom from memory in a 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 Gotchas From Real Fault Cases

Once the three stages above have told you where the problem sits, these are the specific traps that keep showing up once you're there.

1. Security Policy Addresses Must Be the Real Address, Not the One You'd Expect

SYMPTOMTraffic gets dropped even though a security-policy rule appears, on paper, to allow it — in a scenario where NAT is also configured on the same path.

CAUSEThe security policy always evaluates the real address for that direction, not the one that seems intuitive: in a source-NAT scenario the policy's source address has to be the pre-NAT address, and in a destination-NAT scenario the policy's destination address has to be the post-NAT address. Configuring the wrong side of that pair produces a rule that looks correct and still never matches.

FIXWrite the policy address for the actual pre- or post-NAT address, matching the direction of translation — not the address a user or the public documentation for the service would reference.

[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. Local-Zone and Intra-Zone Traffic Can Pass Without Ever Showing a Matched Policy

SYMPTOMdefault action deny is configured and no explicit security-policy rule exists, yet traffic between interfaces in the same zone — or management traffic to the device itself — still gets through.

CAUSEIntra-zone traffic does still match the security-policy evaluation path, but under default packet-filter behavior it doesn't display a matched policy name unless a detailed rule with both source-zone and destination-zone explicitly configured is present. Separately, when service-manage enable is active on an interface, management traffic destined to the Local zone skips security-policy matching entirely — packet-filter permission for it is decided by service-manage, not by the policy engine.

FIXDon't read “no policy name in the session” as “nothing is filtering this.” If you need visibility or control over intra-zone traffic, add a detailed rule with the matching source-zone and destination-zone explicitly set; manage which services are open under service-manage deliberately, since that path bypasses the policy engine by design.

3. A User-Based Policy Needs a Matching Authentication Policy Destination Zone Too

SYMPTOMA security-policy rule configured to deny a specific authenticated user's traffic doesn't take effect — the user is confirmed online, but their traffic isn't being blocked.

CAUSEThe authentication policy's destination zone doesn't match the session's actual destination zone, so the session never hits the authentication policy in the first place — and a user-based security-policy rule downstream of that never gets a chance to apply either, regardless of how correctly it's written.

FIXCompare display firewall session table verbose against the authentication-policy configuration; if the destination zone needs to cover more than one zone, set it to any, then re-check that the user-based rule's hit count actually starts moving.

4. NAT Address-Pool Port Reuse Has a Practical Ceiling, Not Just a Theoretical One

SYMPTOMNAT works fine under light load, then sessions through an already-working PAT pool start intermittently failing or getting dropped as traffic grows.

CAUSEPAT mode lets a single public IP exceed its raw 63,488-session limit through port reuse, but the probability of a port conflict rises with the reuse rate. Field practice generally keeps this to roughly 200,000 sessions per public IP as a working ceiling, well short of any theoretical maximum.

FIXCheck display nat port conflict for a rising conflict history before assuming the pool configuration itself is broken; if a single public IP is genuinely overloaded, add more addresses to the pool or split traffic across additional public IPs.

[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. An Anti-Attack False Positive Can Look Exactly Like a NAT or Session Fault

SYMPTOMA NAT mapping that has worked reliably for a long time suddenly stops working, often on a dual-egress firewall, with no configuration change on the NAT or routing side.

CAUSEAn anti-attack feature — IP-spoofing detection is a common one — can start silently discarding packets that trip its heuristics, with no NAT-layer or session-layer symptom to point at directly. From the outside it presents identically to a NAT or routing fault.

FIXCheck display firewall statistic system discard for a rising ATK-discard count before spending more time on NAT or session-table configuration that's already correct; disable or tune the specific anti-attack feature once confirmed, rather than leaving anti-attack disabled wholesale.

<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

Related solution designs

Enterprise Internet Edge SecurityThe firewall zoning, policy and NAT layer this troubleshooting order applies to directly — not a hypothetical, the actual edge design these commands run against. Ransomware Protection & Network SegmentationZone segmentation depends on the same security-policy engine covered here actually enforcing what you think it enforces — worth reading once the troubleshooting basics are solid.

Five Questions That Come Up Constantly

Pulled straight from the field — the ones worth having an answer ready for.

display firewall session table shows nothing at all for this traffic — where do I even start?

Confirm route reachability first, then check whether the security policy actually permits the traffic with display security-policy rule and its HITS count. A session that was never created almost always means the packet either never reached the device, or was denied before a session could even be built — not a session-table bug.

The HITS count on the rule I expect never increases. What does that actually tell me?

It means the traffic is matching something else — a different, higher-priority rule, or the implicit default rule — before it ever reaches the rule you're watching. Check the rule order and refine the matching conditions; a rule with a hit count stuck at zero is rarely “broken,” it's usually just not the rule that's actually being evaluated.

Why does traffic still get through when I haven't configured any security-policy rule and default action is deny?

This only applies to intra-zone traffic and to Local-zone management traffic under service-manage. Intra-zone traffic is still evaluated by the policy engine but doesn't display a matched policy name under default packet-filter behavior unless a detailed rule exists; service-manage traffic to the device itself bypasses the policy engine entirely by design. Neither is a bug — both are documented default behavior.

What's actually the difference between a session-table problem and a policy problem, if a ticket just says “traffic doesn't work”?

No session at all in display firewall session table verbose means the traffic never got past the policy layer — check hits before anything else. A session that does exist, with one direction's packet/byte counters stuck at 0 while the other moves, means the policy already let the traffic through and the real problem is asymmetric routing or a downstream drop — not a policy issue at all, and not worth re-touching the policy configuration over.

When should I move from display commands to debugging?

Once display commands have told you which stage is stuck but not why — for example, an IKE negotiation that display ike sa shows as absent, with no clear reason on the policy or routing side. Enable terminal monitor and terminal debugging first, then run the targeted debugging command for that feature (debugging ikev1 all, debugging ipsec all, and so on) alongside a scoped packet-capture, and export a full diagnostic bundle with display diagnostic-information and save logfile all before escalating.

Honest Limits of This Note

Honest Limits of This Note

This note is built around the Huawei USG-series firewall's session table, security-policy and NAT command set, plus the field fault cases behind them. It doesn't cover UTM-profile-level faults (IPS, antivirus, URL filtering as content-inspection features rather than policy-matching features), high-availability/dual-active switchover edge cases, or virtual-system (vsys) specific policy inheritance in depth — those are different enough in scope to need their own treatment.

Stuck on a specific firewall fault?

Tell us which stage it's stuck at — policy, session table, or NAT — plus the display security-policy / display firewall session table output, and we'll help you read it.

WhatsApp an engineer →

Related Reading

Firewall Security Policy + IPSec VPN: Configuration WalkthroughThe worked configuration this troubleshooting order assumes you already have in place, including the policy rules that permit the tunnel's own traffic. Fault Information to Collect Before You EscalateWhat to capture — diagnostic bundle, debugging output, packet capture — before handing a firewall fault to a second-line engineer. Enterprise Internet Edge SecurityThe wider gateway design these session-table, policy and NAT commands are diagnosing in the first place.