A Huawei AR-series branch gateway using a Tunnel interface — not an ACL — to carry an IPSec-protected path to a Cisco router at headquarters: why VTI beats policy-based IPSec for this job, the six-step configuration, and how to confirm the tunnel is actually protected.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The two-router pairing here is a familiar one — the real decision is how the protected traffic gets defined, not how the tunnel comes up.
The usual way to build an IPSec tunnel between a branch and headquarters is with an ACL: a rule enumerating which subnet pairs count as "interesting traffic" that gets encrypted. That works fine for a small, fixed set of subnets. Once a branch is large enough — many subnets, traffic that keeps growing, a network that keeps changing — Huawei's own guidance for this pairing recommends switching to a virtual tunnel interface (VTI) instead: traffic under the Tunnel interface gets IPSec protection automatically, with no ACL defining what qualifies.
Below is the configuration this note is based on, why VTI is the better fit once a branch grows past a handful of subnets, and the six gotchas that show up most often when a Tunnel interface — not an ACL — is doing the protecting.
A Tunnel interface on each side — a real, routable Layer-3 interface, not a policy hook on a physical port.
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 |
Same encryption underneath; a different answer to "what traffic gets protected, and how does that stay in sync with the network."
| Aspect | ACL / policy-based IPSec | Virtual tunnel interface (VTI) |
|---|---|---|
| What defines protected traffic | An ACL enumerating source/destination subnet pairs | Whatever is routed toward the Tunnel interface |
| Adding a new protected subnet | Add or edit an ACL rule and re-apply the policy | Add a route — static, or via a routing protocol — toward the tunnel |
| Dynamic routing protocols across the tunnel | Not natively supported — there is no interface for OSPF or BGP to run over | Works directly — the Tunnel interface is a normal Layer-3 interface |
| Multicast traffic | Needs extra GRE or profile workarounds | Runs over the tunnel like it would over any routed interface |
| Best fit | A small, fixed number of subnet pairs | Large or growing branch sites, or sites already running dynamic routing |
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] ospf 2
[RouterA-ospf-2] area 0.0.0.0
[RouterA-ospf-2-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-2-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[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 tunnel-interface logic, different command family: a Tunnel interface in ipsec ipv4 mode, crypto isakmp policy for the phase-1 attributes, crypto ipsec transform-set for the phase-2 attributes, and a crypto ipsec profile bound to the tunnel interface with tunnel protection ipsec profile — the Cisco equivalent of applying the Huawei ipsec profile to Tunnel0/0/0.
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)#RouterB ospf 2
RouterB(config-RouterB)#network 10.2.1.0 0.0.0.255 area 0
RouterB(config-RouterB)#network 10.1.2.0 0.0.0.255 area 0
RouterB(config-RouterB)#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.
The first one is specific to building IPSec on a Tunnel interface; the rest apply to this Huawei-Cisco pairing whichever method builds the tunnel.
SYMPTOMThe Tunnel0/0/0 interface shows up, and pings even pass across it — but display ike sa shows no security association at all.
CAUSESteps 2 through 5 build a Tunnel interface and an IPSec profile as two separate objects. Nothing connects them until step 6 explicitly applies the profile to the interface. Until that command runs, the Tunnel interface behaves like any other routable interface carrying traffic in the clear — "interface up" and "traffic protected" are two different facts.
FIXConfirm the ipsec profile is applied on the Tunnel interface itself, not just defined as a standalone object.
[RouterA] interface tunnel 0/0/0
[RouterA-Tunnel0/0/0] ipsec profile profile1SYMPTOMDead 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.
Questions this exact VTI pairing comes up with most.
No — that is the whole point of the virtual tunnel interface approach. There is no traffic-selector ACL at all; whatever the routing table sends toward the Tunnel interface gets IPSec protection. You still need a normal route, static or dynamic, telling the router to send that traffic there in the first place.
Yes. Huawei's own configuration guide for this exact example shows running OSPF between the two Tunnel interface addresses so the remote private subnet becomes reachable without a static route — one of the practical advantages of VTI over ACL-based IPSec, since the tunnel is a routable Layer-3 interface, not just a policy hook on a physical interface.
If the Tunnel interface's source was configured as a specific IP address, the tunnel breaks the next time that address changes — which matters on a branch with a dynamic public IP from DHCP or PPPoE. Configure source as the outbound interface itself, not a snapshot of its address — see Gotcha 4 above.
The IKE and IPSec parameters and the Tunnel-interface logic in this note are vendor-neutral standards; only the command syntax on the far end changes. This walkthrough was verified against a Cisco router. Fortinet and other vendors follow the same phase 1 / phase 2 logic through a different configuration path — see our separate Huawei-to-FortiGate note for a policy-based example against a firewall.
The example in this note runs with PFS disabled, matching the source configuration it is based on. Enabling PFS adds a fresh Diffie-Hellman exchange for every phase-2 rekey, which is more resistant to key-compromise replay at a small CPU cost — worth turning on for higher-security segments, as long as both ends agree on the same DH group.
This note is based on one worked configuration: a Huawei router (IKEv1, main mode, pre-shared key, AES-128 / SHA-1) reaching a Cisco router over a virtual tunnel interface. ACL/policy-based IPSec, IKEv2, aggressive mode, NAT traversal, and non-Cisco peers — FortiGate, for instance, see our companion note — each shift the details. This note covers the VTI method against Cisco, not every combination.
Device models, software versions and whether you're leaning VTI or ACL-based — send it over WhatsApp and we'll help you line up the parameters on both ends.