A Huawei AR branch router with a DHCP-assigned public address, sitting behind a NAT device, building an IPSec tunnel to a fixed-address Cisco router at headquarters — aggressive mode, NAT traversal, the Cisco-side dynamic-map template, and the failure modes that only show up once NAT and a moving IP address are both in the picture.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The previous Huawei-Cisco note assumed both ends had a known IP address. Take that away and the design changes.
A branch office rarely gets a fixed public IP from its ISP, and it usually sits behind a NAT device of some kind — a carrier CPE, a dedicated NAT box, or NAT running on the AR router's own WAN interface. Main-mode IKE negotiation, which identifies peers by IP address, doesn't tolerate either condition well: a dynamic address means headquarters can't pre-configure a fixed peer address for that branch, and NAT rewrites the very source address IKE would otherwise use to pick the right pre-shared key.
This note works through the configuration that handles both problems together — a Huawei AR branch gateway with a DHCP-assigned WAN address, sitting behind a separate NAT device, negotiating IKEv1 aggressive mode with NAT traversal enabled to a Cisco router at headquarters that accepts the branch through a dynamic-map template — plus what changes when the branch router does its own NAT instead of using a separate box, and what changes again when it's headquarters, not the branch, sitting behind NAT.
Three devices this time, not two — the branch router, a NAT device, and the Cisco headquarters router.
Diagram labels are kept in English for engineering clarity.
Addressing — RouterA and RouterB
| Item | RouterA — Huawei branch gateway | RouterB — Cisco HQ gateway |
|---|---|---|
| Public (WAN) address | DHCP-assigned, reached through NATer | 60.1.2.1 (static) |
| Private subnet | 10.1.1.0/24 | 10.1.2.0/24 |
| IKE identity | local-name huawei | expects remote peer name RouterB |
NAT Device (NATer)
| Item | Value (this example) |
|---|---|
| WAN interface (toward internet) | 60.1.1.1/24 — nat outbound |
| LAN interface (toward RouterA) | 192.168.1.1/24 — dhcp select interface |
| Static route | 0.0.0.0/0 via 60.1.1.2 |
Phase 1 — IKE Negotiation Parameters
| Parameter | Value (this example) |
|---|---|
| IKE version | IKEv1 |
| Negotiation mode | Aggressive mode |
| Authentication method | Pre-shared key |
| Pre-shared key (this example) | YsHsjx_202206 — the source example's key; always set a unique key of your own. |
| Encryption algorithm | aes-cbc-128 |
| Authentication algorithm | sha2-256 |
| DH group | group14 |
| NAT traversal | Enabled (nat traversal) |
| Peer identity | Name-based (local-id-type name / remote-name) |
Phase 2 — IPSec Negotiation Parameters
| Parameter | Value (this example) |
|---|---|
| Security protocol | ESP |
| Encapsulation mode | Tunnel (device default) |
| Encryption algorithm | aes-128 |
| Authentication algorithm | sha2-256 |
| Protected flow (ACL 3000) | 10.1.1.0/24 ↔ 10.1.2.0/24 |
Aggressive mode plus NAT traversal replace main mode's fixed-IP assumptions.
#
sysname RouterA
#
ipsec authentication sha2 compatible enable
#
ike local-name huawei
#
acl number 3000
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec proposal prop1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-128
#
ike proposal 1
encryption-algorithm aes-cbc-128
dh group14
authentication-algorithm sha2-256
#
ike peer peer1 v1
exchange-mode aggressive
pre-shared-key cipher
ike-proposal 1
local-id-type name
remote-name RouterB
nat traversal
remote-address 60.1.2.1
#
ipsec policy policy1 10 isakmp
security acl 3000
ike-peer peer1
proposal prop1
#
interface GigabitEthernet0/0/1
ipsec policy policy1
ip address dhcp-alloc
#
interface GigabitEthernet0/0/2
ip address 10.1.1.1 255.255.255.0
#
returnA dedicated box between the branch router and the internet. It doesn't need to know anything about the IPSec-protected flow — it simply translates every outbound packet and hands the branch router a private address by DHCP.
#
sysname NATer
#
dhcp enable
#
acl number 3000
rule 5 permit ip
#
interface GigabitEthernet0/0/1
ip address 60.1.1.1 255.255.255.0
nat outbound 3000
#
interface GigabitEthernet0/0/2
ip address 192.168.1.1 255.255.255.0
dhcp select interface
#
ip route-static 0.0.0.0 0.0.0.0 60.1.1.2
#
returnBecause the branch's address can change and other branches may need to connect the same way, the Cisco side accepts by identity rather than by a fixed peer address, through a dynamic crypto map.
!
hostname RouterB
!
crypto isakmp policy 1
encryption aes 128
hash sha256
authentication pre-share
group 14
crypto isakmp key YsHsjx_202206 hostname huawei
!
crypto isakmp identity hostname
!
crypto ipsec transform-set p1 esp-sha256-hmac esp-aes 128
!
crypto dynamic-map p1 1
set transform-set p1
match address 102
!
crypto map p1 1 ipsec-isakmp dynamic p1
!
interface GigabitEthernet0/0
ip address 60.1.2.1 255.255.255.0
duplex auto
speed auto
crypto map p1
!
interface GigabitEthernet0/1
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 60.1.2.2
!
access-list 102 permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255
!
endCisco-side syntax in this note was verified against Cisco IOS Software, C3900e-UNIVERSALK9-M, release 15.2(4)M1 — IOS-XE and ASA use related but not identical syntax.
The example above has the Huawei branch initiate. If the Cisco router needs to initiate aggressive mode toward a branch sitting behind NAT, it needs a peer-specific block instead of the dynamic map.
crypto isakmp peer ip-address 60.1.1.1
set aggressive-mode client-endpoint fqdn huawei
set aggressive-mode password YsHsjx_202206Some branches don't have a separate NAT device — the AR router itself does NAT on the same interface that carries the IPSec-protected traffic. In that case the processing order matters: NAT runs before IPSec encryption, so unless the protected flow is explicitly excluded from the NAT ACL, NAT rewrites the source address before IPSec's own ACL ever sees it, and the tunnel's security ACL stops matching. The ACL used for NAT must deny the IPSec-protected flow and only permit everything else:
acl number 3001
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
#
interface GigabitEthernet0/0/1
ipsec policy policy1
nat outbound 3001
ip address dhcp-allocThese are the issues that specifically come from adding NAT and a moving IP address to an otherwise ordinary Huawei-Cisco tunnel.
SYMPTOMPhase 1 negotiation fails or picks the wrong pre-shared key as soon as a NAT device sits between the branch and headquarters — even though the exact same parameters worked fine on a direct public-IP link.
CAUSEMain mode selects the pre-shared key based on the peer's IP address. Once NAT rewrites that address in transit, the far end is no longer looking up the key by the address the near end actually configured.
FIXSwitch to aggressive mode and identify the peer by name instead of by IP address — a name survives NAT translation, an IP address doesn't.
[RouterA] ike peer peer1 v1
[RouterA-ike-peer-peer1] exchange-mode aggressive
[RouterA-ike-peer-peer1] local-id-type name
[RouterA-ike-peer-peer1] remote-name RouterBSYMPTOMThe nat traversal command is rejected on one device, or NAT-T behaves as if it were never configured on another, even though both are Huawei AR routers.
CAUSEOn V200R008, NAT traversal is enabled by default and the command itself isn't supported. On versions after V200R008, it has to be configured explicitly with the nat traversal command under the IKE peer.
FIXCheck the software version before assuming NAT-T's state — don't copy an IKE peer block from one AR firmware branch onto another without confirming whether the command applies.
[RouterA-ike-peer-peer1] nat traversalSYMPTOMThe branch does its own NAT (no separate NATer box), and traffic that should be encrypted goes out untouched — or the tunnel never sees the traffic it's supposed to protect.
CAUSEWhen IPSec and NAT are configured on the same outbound interface, the router processes NAT first and IPSec encryption second. If the NAT ACL doesn't explicitly exclude the IPSec-protected flow, NAT rewrites the source address before the tunnel's own security ACL ever gets a chance to match it.
FIXDeny the IPSec-protected flow in the NAT ACL first, then permit everything else — that way NAT only touches traffic that isn't supposed to go through the tunnel.
acl number 3001
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 ipSYMPTOMThe tunnel works fine, then stops passing traffic after a period of low activity — with no configuration change on either side.
CAUSENAT devices age out idle UDP bindings. If neither side is actively probing the peer, the NAT device's translation entry for the IKE/IPSec session can expire while the SA itself still looks "established" — the next packet from headquarters has nowhere valid to go.
FIXEnable periodic Dead Peer Detection on the IKE peer so both sides keep probing each other and the NAT binding stays refreshed.
[RouterA-ike-peer-peer1] dpd type periodicSYMPTOMPhase 1 never completes, or the Cisco router logs an identity mismatch, even though the pre-shared key is typed correctly on both ends.
CAUSEBy default Cisco's ISAKMP identity is address-based. If the Huawei branch is presenting a name-based identity (as aggressive mode requires here), the Cisco router won't match it against the right key unless it's told to expect a hostname.
FIXSet the ISAKMP identity to hostname on the Cisco router, and key the pre-shared secret to that same hostname rather than to an IP address.
crypto isakmp key YsHsjx_202206 hostname huawei
crypto isakmp identity hostname"Established" in the SA table is necessary but not sufficient behind NAT — the NAT-T ports have to actually be forwarding too.
[RouterA] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
8 60.1.2.1 0 RD|ST 2
6 60.1.2.1 0 RD|ST 1
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UPIf the tunnel won't establish at all behind NAT, confirm the NAT device is actually forwarding UDP 500 and UDP 4500 toward the branch — NAT-T typically shifts IKE traffic to port 4500 once translation is detected, and a device that only opens 500 will quietly break negotiation.
Five questions that come up almost every time this exact combination — dynamic IP, NAT, Huawei to Cisco — gets built.
If a NAT device sits anywhere in the path, no — main mode selects the pre-shared key by the peer's IP address, and NAT rewrites that address before it reaches the far end. Aggressive mode identifies the peer by name instead, which survives NAT translation. If there's genuinely no NAT and only the IP is dynamic, main mode with a wildcard pre-shared key bound to any address can still work.
Either works. A separate NAT device, as in this note's main example, keeps IPSec and NAT cleanly apart. If the AR router does its own NAT on the same interface, remember that NAT runs before IPSec — the NAT ACL must explicitly deny the IPSec-protected flow, or NAT rewrites it before the tunnel gets a chance to protect it.
Then the device in front of headquarters needs static port forwarding rather than the outbound NAT used for the branch: forward UDP 500 and UDP 4500 to the Cisco router's private address so IKE and NAT-T traffic actually reach it, plus ICMP if connectivity testing needs to pass.
nat server protocol udp global current-interface 500 inside 192.168.1.2 500
nat server protocol udp global current-interface 4500 inside 192.168.1.2 4500
nat server protocol icmp global current-interface inside 192.168.1.2As configured here, the pre-shared key is bound to the branch's IKE name (crypto isakmp key ... hostname huawei), so this dynamic map effectively accepts that one identified branch. To let the same map accept any branch, bind the key to a wildcard address instead of a hostname — the same dynamic-map template combined with an IP-based identity on the branch side will accept any peer that presents the matching key.
Cisco IOS Software, C3900e-UNIVERSALK9-M, release 15.2(4)M1. IOS-XE and ASA use related but not identical syntax. The source configuration guide also flags MD5, SHA-1, DES and 3DES as algorithms with known weaknesses — avoid them if the far end can negotiate something stronger.
This note is based on the aggressive-mode, NAT-traversal, dynamic-map combination from the source configuration guide, plus the branch-side-NAT and headquarters-side-NAT variants it documents. It doesn't cover IKEv2 behind NAT, double-NAT chains, carrier-grade NAT (CGN) address sharing, or a NAT device from a third-party vendor whose translation behavior doesn't match this exact Huawei-to-Huawei NATer test setup.
Branch behind NAT, dynamic IP, a specific Cisco IOS version — send it over WhatsApp and we'll help you line up the parameters on both ends.