The server-map entry is correct. The route is correct. The ARP entry is correct. And the mapping still doesn't work — because every one of those checks passing is exactly what makes this fault hide from the obvious troubleshooting order. This is the diagnostic chain that goes one layer deeper, down to the forwarding-plane counter that actually names the problem.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
server-map normal, route normal, ARP normal — and the client on the internet still can't reach the mapped server.
A NAT Server mapping that simply doesn't work is one of the more disorienting faults on a Huawei AR router, precisely because the first three things anyone checks — display firewall server-map nat-server, display ip routing-table, display arp — all come back clean. If you've already configured NAT Server correctly (see our Easy IP configuration walkthrough for the setup itself), the fault isn't in the mapping definition; it's somewhere in the forwarding path underneath it, and the fastest way to it is a session-table check followed by a forwarding-plane packet-drop counter, not another look at the NAT configuration.
What follows is that diagnostic chain in order, the root causes it actually turns up, and field-case FAQ answers on the NAT Server behaviors that keep causing confusion.
Four checks look completely normal in this fault, one at a time, before the actual drop shows up on a forwarding-plane counter nobody thinks to check first.
This is a linear chain, not a fork — each stage either confirms "not here" and sends you to the next check, or names the actual cause and stops you from re-verifying configuration that was never the problem.
Diagram labels are kept in English for engineering clarity.
The first two stages are worth confirming quickly and then trusting — going back to re-check the server-map or the route a second and third time after they've already come back clean is the single biggest time-sink in this fault. The session table and the forwarding counter are what actually distinguish "the mapping is wrong" from "the mapping is right but forwarding never gets to use it."
The first two checks confirm the mapping isn't the problem — the last two prove the drop and name it.
Three commands, all clean, and none of them are where the fault actually is.
<sysname> display firewall server-map nat-server
Current Total Server-map : 2
Type: Nat Server, ANY -> 100.1.1.101[192.168.205.101], Zone:---, protocol:---
Vpn: public -> public
Type: Nat Server Reverse, 192.168.205.101[100.1.1.101] -> ANY, Zone:---, protocol:---
Vpn: public -> public, counter: 1
// both forward and reverse entries present -- mapping itself is fine
[sysname] display ip routing-table 192.168.205.101
Destination/Mask Proto Pre Cost Flags NextHop Interface
192.168.205.0/24 Direct 0 0 D 192.168.205.1 10GE0/0/1
// route resolves correctly
[sysname] display arp network 192.168.205.101 32
IP ADDRESS MAC ADDRESS EXP(M) TYPE/VLAN INTERFACE VPN-INSTANCE
192.168.205.101 0000-c0a8-cd65 11 D 10GE0/0/1
// real MAC, not Incomplete -- ARP is fine tooThis is where the fault actually shows itself — one layer below everything you already confirmed was fine.
<sysname> system-view
[sysname] diagnose
[sysname-diagnose] display forward information cpu-forward slot 0 cpuid 0 "hsd diag set pfa counter debug 0 1"
[sysname-diagnose] display forward information cpu-forward slot 0 cpuid 0 "hsd diag clear pfa counter 1"
// trigger the Telnet attempt against the mapped port here, then read the counter
[sysname-diagnose] display forward information cpu-forward slot 0 cpuid 0 "hsd diag show pfa counter all 1"
Module | error | Value
[ 4]IPV4
[ 4]ERROR_CNT_IPV4_ARPMISS 14
[ 6]ERROR_CNT_IPV4_NHP_DWN 14
[ 62]ERROR_CNT_BLACK_HOLE 37
// ARP Miss and black-hole counts climbing -- traffic never resolved to the right next hop
[sysname] interface 10GE0/0/1
[sysname-10GE0/0/1] display this
#
interface 10GE0/0/1
ip address 100.1.1.100 255.255.255.0
device transceiver 10GBASE-FIBER
#
// nat enable is missing here -- ingress traffic never went through server-map translation
[sysname-10GE0/0/1] nat enableOnce the chain above has told you the mapping and route were never the problem, these five account for most of what's actually wrong.
SYMPTOMserver-map, route and ARP for the inside address all check out clean, but no session is ever created for traffic aimed at the mapped public address, and the forwarding-plane ARP-Miss error counter climbs every time you try.
CAUSEThe server-map entry exists globally on the device, but NAT translation only actually runs on an interface where nat enable is configured. Without it, traffic destined for the public mapped address is forwarded as a plain IP lookup against that address — which was never meant to be routed anywhere — instead of being translated to the inside address first.
FIXConfirm with display this on the ingress interface, then add nat enable.
[sysname-10GE0/0/1] display this
#
interface 10GE0/0/1
ip address 100.1.1.100 255.255.255.0
#
[sysname-10GE0/0/1] nat enableSYMPTOMTraffic in one direction across the same path works fine; the other direction fails, even though both ends' configuration and the link itself check out — display ike sa (or the tunnel equivalent) shows everything established.
CAUSENAT Server's automatic reverse-session behavior takes priority over a source-NAT policy, even one that explicitly denies translating the protected traffic. The private address gets translated to the public address anyway on the return path, breaking whatever expected that traffic to arrive untranslated.
FIXConfigure no-reverse on the nat server command when the server-side address should only ever be translated inbound, never on its own outbound traffic; check display firewall server-map for the "Nat Server Reverse" entry to confirm it's actually in play.
[sysname2] nat server 0 protocol tcp global 2.1.1.10 3389 inside 10.1.2.2 3389 no-reverseSYMPTOMNo obvious symptom until you dig into it — but under load, or after a topology change, traffic toward the NAT Server's global address starts looping between the device and the downstream router instead of reaching the server.
CAUSEWhen the NAT pool address or the NAT Server's global address isn't on the same subnet as the outbound interface, the device still needs a route for it to exist locally so a downstream device doesn't try bouncing matching traffic back. Without a black-hole route, the downstream device believes the destination is still reachable through the device and sends it back, forming a loop.
FIXConfigure a black-hole route for the NAT Server's global address (or the NAT pool range) whenever it isn't in the same subnet as the physical outbound interface — and consider one even when it is, since it also stops the device generating unnecessary ARP requests for an address that's never actually a real host.
[sysname] ip route-static 100.1.1.101 255.255.255.255 NULL0SYMPTOMThe mapping and the route both look correct, but traffic still gets dropped, and the drop only clears once the security/ACL policy is rewritten to reference the server's private address instead of the public one.
CAUSENAT Server translation happens before the security policy check in the forwarding order — once a packet matches the server-map entry, its destination address is already rewritten to the inside address by the time policy evaluation happens. A policy written against the original public destination will never match.
FIXWrite the security policy's destination address as the server's private (inside) address, not the public address configured in the NAT Server mapping.
SYMPTOMYou want to confirm traffic is actually hitting a specific NAT Server or pool entry, as opposed to just existing as a mapping, and the obvious commands don't show a per-entry counter.
CAUSEThere is no display command that reports how many packets have matched a specific NAT Server or NAT address-pool entry directly.
FIXUse display nat-policy rule all instead — it reports a HITS counter per NAT policy rule, which is the closest available proxy for confirming a given rule (and by extension its associated server-map or pool) is actually being matched by real traffic.
<sysname> display nat-policy rule all
Total:3
RULE ID RULE NAME STATE ACTION HITS
1 test disable no-nat 0
2 abc enable src-nat 5
0 default enable no-nat 0Pulled straight from the field — the ones worth having an answer ready for.
Technically yes, but avoid it. Once that interface IP becomes the NAT Server's global address, every packet destined for the interface itself gets translated to the server's inside address first — which breaks ping, Web management and Telnet to the device on that address. Using the interface IP for source-NAT translation instead doesn't have this problem, since traffic actively initiated toward the interface follows the first-packet process and bypasses the source-NAT policy.
Not directly. There's no counter dedicated to a single NAT Server or NAT pool entry. display nat-policy rule all is the closest thing — it reports a HITS count per configured NAT policy rule.
Two cases: when the NAT pool or NAT Server global address is on a different subnet than the outbound interface (mandatory, to prevent a forwarding loop), and — worth doing anyway — even when it's on the same subnet, since it stops the device from generating pointless ARP requests for an address that was never a real host.
This is the no-reverse behavior. Without it, NAT Server's automatic reverse-session translates the server's own outbound traffic to the same public address as the mapping — which is usually fine. But if a source-NAT policy or a different address pool is also handling that server's outbound traffic, the two translations disagree and connections fail; align them to the same public address, or apply no-reverse and configure outbound NAT explicitly for that host.
Because NAT Server translation happens before the security policy check. By the time the policy evaluates the packet, the destination has already become the private inside address. Point the policy's destination address at the inside address instead.
The configuration guide gets you to a mapping that's defined correctly. This note is for the case where the definition is already correct and traffic still doesn't arrive — which almost always means the fault is one layer down, in whether NAT translation is actually being applied to the ingress interface, or in a forwarding-plane drop the mapping itself can't show you.
This note is built around the Huawei AR-series router's NAT Server fault model, server-map / forward information cpu-forward diagnostics and the field cases behind them. On different platforms the equivalent forwarding-plane drop counters live under different commands, but the underlying chain — mapping, route, ARP, session, forwarding drop, interface NAT enablement — carries over directly. It doesn't cover load-balanced or multi-active NAT Server deployments in depth, or NAT64/NAT-PT scenarios.
Send us your display firewall server-map nat-server output plus which stage of this chain you've confirmed clean, and we'll help you read the rest.