A Huawei AR-series branch gateway building an IPSec tunnel to a Cisco router at headquarters over the public internet — the configuration steps, the data plan, and five interoperability issues that most often break traffic even after the tunnel shows “up”.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
I've built this exact cross-vendor pairing more than once — Huawei on one end, Cisco on the other.
Getting an IPSec tunnel to form between a Huawei router and a Cisco router is usually not the hard part — both sides will bring up phase 1 and phase 2 without much drama once the basic parameters match. What actually eats the time is what happens after the tunnel shows “up”: traffic that still won't pass, or a tunnel that works for a while and then quietly stops.
Below is the configuration this is based on — a Huawei branch gateway meeting a Cisco headquarters gateway over the public internet — plus the five interoperability issues that account for most of the “it's up but it doesn't work” tickets I've seen on this pairing.
One tunnel interface on each side, carrying traffic between the branch subnet and the headquarters subnet.
Diagram labels are kept in English for engineering clarity.
Addressing
| Item | RouterA — Huawei branch gateway | RouterB — Cisco HQ gateway |
|---|---|---|
| Public (WAN) address | 1.1.2.10 | 1.1.1.10 |
| Tunnel interface address | 10.2.1.2 | 10.2.1.1 |
| Private subnet gateway | 10.1.1.1 | 10.1.2.1 |
Phase 1 — IKE Negotiation Parameters
| Parameter | Value (this example) |
|---|---|
| IKE version | IKEv1 |
| Negotiation mode | Main mode |
| Authentication method | Pre-shared key |
| Pre-shared key (this example) | huawei@123 — the source example's key; always set a unique key of your own. |
| Encryption algorithm | aes-cbc-128 |
| Authentication algorithm | sha1 |
| DH group | group5 |
| DPD | Enabled |
Phase 2 — IPSec Negotiation Parameters
| Parameter | Value (this example) |
|---|---|
| Security protocol | ESP |
| Encapsulation mode | Tunnel |
| Encryption algorithm | aes-128 |
| Authentication algorithm | sha1 |
| SA lifetime | 3600 seconds (default) |
| PFS | Disabled |
Six steps turn a plain Tunnel interface into one that is actually protected by IPSec.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 1.1.2.10 255.255.255.0
[RouterA-GigabitEthernet1/0/0] quit
[RouterA] interface gigabitethernet 2/0/0
[RouterA-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0
[RouterA-GigabitEthernet2/0/0] quit
[RouterA] ip route-static 0.0.0.0 0.0.0.0 1.1.2.1
[RouterA] interface Tunnel0/0/0
[RouterA-Tunnel0/0/0] ip address 10.2.1.2 255.255.255.0
[RouterA-Tunnel0/0/0] tunnel-protocol ipsec
[RouterA-Tunnel0/0/0] source gigabitethernet 1/0/0
[RouterA-Tunnel0/0/0] destination 1.1.1.10
[RouterA-Tunnel0/0/0] quit
[RouterA] ike proposal 5
[RouterA-ike-proposal-5] encryption-algorithm aes-cbc-128
[RouterA-ike-proposal-5] authentication-algorithm sha1
[RouterA-ike-proposal-5] dh group5
[RouterA-ike-proposal-5] authentication-method pre-share
[RouterA-ike-proposal-5] quit
[RouterA] ike peer RouterA v1
[RouterA-ike-peer-RouterA] ike-proposal 5
[RouterA-ike-peer-RouterA] pre-shared-key cipher huawei@123
[RouterA-ike-peer-RouterA] dpd type periodic
[RouterA-ike-peer-RouterA] dpd msg seq-hash-notify
[RouterA-ike-peer-RouterA] quit
[RouterA] ipsec proposal RouterA
[RouterA-ipsec-proposal-RouterA] transform esp
[RouterA-ipsec-proposal-RouterA] encapsulation-mode tunnel
[RouterA-ipsec-proposal-RouterA] esp authentication-algorithm sha1
[RouterA-ipsec-proposal-RouterA] esp encryption-algorithm aes-128
[RouterA] ipsec profile profile1
[RouterA-ipsec-profile-profile1] ike-peer RouterA
[RouterA-ipsec-profile-profile1] proposal RouterA
[RouterA-ipsec-profile-profile1] quit
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ipsec profile profile1Same five ingredients, different command family: crypto isakmp policy takes the place of the IKE proposal, crypto ipsec transform-set the place of the IPSec proposal, and a crypto ipsec profile bound to the tunnel interface with tunnel protection ipsec profile replaces the Huawei ipsec profile step.
RouterB#configure
RouterB(config)#interface gigabitethernet 0/1
RouterB(config-if)#ip address 1.1.1.10 255.255.255.0
RouterB(config-if)#exit
RouterB(config)#interface gigabitethernet 0/2
RouterB(config-if)#ip address 10.1.2.1 255.255.255.0
RouterB(config-if)#exit
RouterB(config)#ip route 0.0.0.0 0.0.0.0 1.1.1.1
RouterB(config)#interface tunnel 0
RouterB(config-if)#ip address 10.2.1.1 255.255.255.0
RouterB(config-if)#tunnel mode ipsec ipv4
RouterB(config-if)#tunnel source gigabitethernet0/1
RouterB(config-if)#tunnel destination 1.1.2.10
RouterB(config-if)#exit
RouterB(config)#crypto isakmp policy 10
RouterB(config-isakmp)#hash sha
RouterB(config-isakmp)#encryption aes 128
RouterB(config-isakmp)#group 5
RouterB(config-isakmp)#authentication pre-share
RouterB(config-isakmp)#exit
RouterB(config)#crypto isakmp key huawei@123 address 0.0.0.0 no-xauth
RouterB(config)#crypto isakmp keepalive 10 periodic
RouterB(config)#crypto ipsec transform-set tran1 esp-sha-hmac esp-aes 128
RouterB(cfg-crypto-trans)#mode tunnel
RouterB(cfg-crypto-trans)#exit
RouterB(config)#crypto ipsec profile profile1
RouterB(ipsec-profile)#set transform-set tran1
RouterB(ipsec-profile)#exit
RouterB(config)#interface tunnel 0
RouterB(config-if)#tunnel protection ipsec profile profile1
RouterB(config-if)#exitCisco-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.
These five account for most of the “tunnel is up, traffic isn't” and “it worked yesterday” tickets I've seen on this exact pairing.
SYMPTOMDead Peer Detection is enabled, and the tunnel behaves unpredictably instead of cleanly detecting a dead peer.
CAUSECisco's default DPD packet format is not the same as the Huawei router's default. Left on its default, the Huawei side isn't actually speaking the same DPD dialect as the Cisco side.
FIXOn the Huawei router, set the DPD message format to seq-hash-notify so it matches what the Cisco side expects.
[RouterA-ike-peer-RouterA] dpd type periodic
[RouterA-ike-peer-RouterA] dpd msg seq-hash-notifySYMPTOMdisplay ike sa (or show crypto isakmp sa) shows both phase 1 and phase 2 as established, but a ping across the tunnel fails, or only part of the traffic gets through.
CAUSEWhen the Huawei router and the other vendor's device both use a SHA-2 algorithm in the IPSec security proposal, their SHA-2 encryption/decryption implementations can differ just enough that the tunnel negotiates fine but the data plane doesn't.
FIXOn the Huawei router, enable SHA-2 compatibility mode so both ends process SHA-2 the same way.
[RouterA] ipsec authentication sha2 compatible enableSYMPTOMThe tunnel drops with no configuration change on either side — usually right after the branch's public IP changes on a DHCP or PPPoE renewal.
CAUSEThe Tunnel interface's source was configured as a fixed IP address, but that address is dynamically assigned on the outbound interface. Once the address changes, the tunnel's configured source no longer matches reality.
FIXConfigure source as the outbound interface itself, not its current IP address, so the tunnel tracks the interface instead of a snapshot of its address.
[RouterA-Tunnel0/0/0] source gigabitethernet 1/0/0SYMPTOMThe peer was configured expecting IKEv1 to match an older Cisco config, but negotiation behaves like IKEv2 — or the two ends fail to agree on a version at all.
CAUSEBy default, a Huawei IKE peer has both IKEv1 and IKEv2 enabled. When it initiates negotiation it uses IKEv2; when it responds, it supports both. Needing IKEv1 specifically has to be configured explicitly — it doesn't happen automatically just because the far end is older Cisco gear.
FIXDisable IKEv2 explicitly so the peer only initiates and accepts IKEv1.
[RouterA-ike-peer-RouterA] version 1
[RouterA-ike-peer-RouterA] undo version 2SYMPTOMA command from a configuration example — remote-name, local-id-type name, or a bare pre-shared-key — is rejected, or behaves differently, on the device in front of you.
CAUSEHuawei renamed several IKE peer commands across software versions. The functional behavior is the same; the keyword is not.
FIXMatch the syntax to the software version actually running before you copy a configuration line.
| Older syntax | Current syntax (check your version) |
|---|---|
| ike peer peer-name [ v1 | v2 ] | ike peer peer-name + version { 1 | 2 } (V200R008+) |
| remote-name | remote-id (V200R008+) |
| local-id-type name | local-id-type fqdn (V200R008+) |
| pre-shared-key key | pre-shared-key { simple | cipher } key (V200R003C00+) |
Command keywords and version numbers are kept in their original form across languages for exact reference.
“Established” in the SA table is necessary but not sufficient — check the packet counters too.
[RouterA] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
8 1.1.1.10 0 RD|ST 2
6 1.1.1.10 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, the first two things to check are always the same: is the underlying route to the peer's public address actually reachable, and do both ends' configurations genuinely match, parameter for parameter.
This note is based on one worked configuration: a Huawei router (IKEv1, main mode, pre-shared key, AES-128 / SHA-1) to a Cisco router. Vendor combinations, software versions and cipher suites multiply fast — IKEv2, aggressive mode, NAT traversal, a dynamic-IP branch, or a different peer vendor entirely (Fortinet, for instance) each shift the details. This note covers the most common combination, not all of them.
Device models, software versions and the cipher suite you're trying to run — send it over WhatsApp and we'll help you line up the parameters on both ends.