A Huawei AR-series branch router building an ACL-based IPSec tunnel to a Fortinet FortiGate firewall at headquarters — how the two vendors' terminology for IKE version, cipher suite, PFS and lifetime lines up, the configuration on each side, and 5 interop gotchas.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A Huawei command line and a FortiGate wizard describe the same phase 1 / phase 2 negotiation — the trick is knowing which field means which.
IPSec itself is a vendor-neutral IETF standard, but every vendor names its knobs differently and defaults them differently. Pairing a Huawei AR router at a branch with a Fortinet FortiGate firewall at headquarters means the same tunnel has to be described once in Huawei CLI and once in FortiGate's web GUI — and the two configuration surfaces don't use the same words for the same thing.
Below is the configuration this note is based on: a Huawei branch router using ACL-based IPSec (not a Tunnel interface — see our separate VTI note for that variant), a FortiGate headquarters firewall configured through its GUI, a terminology alignment table so the same parameter doesn't get set twice with two different names, and the 5 interop issues that show up most often on this exact pairing.
An ACL on the Huawei router defines the protected traffic; a FortiGate custom IPSec tunnel mirrors it as Phase 2 Selectors.
Diagram labels are kept in English for engineering clarity.
Addressing
| Item | Router — Huawei branch gateway | FW — Fortinet HQ gateway |
|---|---|---|
| Public (WAN) address | 1.1.1.1 | 2.1.1.1 |
| Private subnet gateway | 10.1.1.2 | 10.1.2.1 |
This is the addressing published in the source configuration guide's own data-plan table. If a static route or ACL entry you copy from a guide references a different subnet than the one in its own data-plan table, treat that as a documentation slip to verify, not a value to trust blindly — see Gotcha 5 below.
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-256 |
| Authentication algorithm | sha2-512 |
| DH group | group14 |
| IKE SA lifetime | 28800 seconds |
| DPD | Enabled |
Phase 2 — IPSec Negotiation Parameters
| Parameter | Value (this example) |
|---|---|
| Security protocol | ESP |
| Encapsulation mode | Tunnel |
| Encryption algorithm | aes-256 |
| Authentication algorithm | sha2-512 |
| IPSec SA lifetime | 3600 seconds |
| PFS | Disabled |
Same field, different name — and, for lifetime, different default units engineers assume without checking.
| Huawei CLI term | What it controls | FortiGate GUI equivalent |
|---|---|---|
| ike proposal (encryption-algorithm / authentication-algorithm / dh) | Phase-1 (IKE SA) cipher suite and DH group | Phase 1 Proposal — Algorithms combo, DH Group |
| ike-proposal sa duration | Phase-1 (IKE SA) lifetime | Phase 1 Proposal — Key Lifetime (seconds) |
| ipsec proposal (esp authentication-algorithm / esp encryption-algorithm) | Phase-2 (IPSec SA) cipher suite | Phase 2 Proposal — Encryption / Authentication |
| ipsec policy ... sa duration time-based | Phase-2 (IPSec SA) lifetime | Phase 2 Proposal — Key Lifetime, seconds/KBytes/Both |
| dpd type / dpd msg | Dead Peer Detection behavior and packet format | Dead Peer Detection — On Idle / On Demand, under Phase 1 |
| acl number (advanced ACL, permit rule) | Which traffic is "interesting" and gets protected | Phase 2 Selectors — local/remote address |
| ike peer ... v1 | IKE protocol version used to negotiate | Network / IKE section — IKE Version field (1 or 2) |
FortiGate menu names shown here follow the GUI walkthrough in the Huawei configuration guide this note is based on — "Authentication", "IKE", "Phase 1 Proposal" and "Phase 2 Selectors / Phase 2 Proposal" screens under VPN > IPSec > Tunnels. Exact wording can shift slightly between FortiOS versions.
Six steps, ACL-driven: define the interesting traffic first, then wrap it in an IPSec policy.
<Huawei> system-view
[Huawei] sysname Router
[Router] interface gigabitethernet 0/0/1
[Router-GigabitEthernet0/0/1] ip address 1.1.1.1 255.255.255.0
[Router-GigabitEthernet0/0/1] quit
[Router] interface gigabitethernet 0/0/2
[Router-GigabitEthernet0/0/2] ip address 10.1.1.1 255.255.255.0
[Router-GigabitEthernet0/0/2] quit
[Router] ip route-static 2.1.1.0 255.255.255.0 1.1.1.2
[Router] ip route-static 10.2.1.0 255.255.255.0 1.1.1.2
[Router] acl number 3101
[Router-acl-adv-3101] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.2.1.0 0.0.0.255
[Router-acl-adv-3101] quit
[Router] ipsec authentication sha2 compatible enable
[Router] ipsec proposal tran1
[Router-ipsec-proposal-tran1] transform esp
[Router-ipsec-proposal-tran1] esp authentication-algorithm sha2-512
[Router-ipsec-proposal-tran1] esp encryption-algorithm aes-256
[Router-ipsec-proposal-tran1] encapsulation-mode tunnel
[Router] ike proposal 5
[Router-ike-proposal-5] encryption-algorithm aes-cbc-256
[Router-ike-proposal-5] authentication-algorithm sha2-512
[Router-ike-proposal-5] dh group14
[Router-ike-proposal-5] sa duration 28800
[Router-ike-proposal-5] authentication-method pre-share
[Router-ike-proposal-5] quit
[Router] ike peer feita v1
[Router-ike-peer-feita] ike-proposal 5
[Router-ike-peer-feita] pre-shared-key cipher huawei@123
[Router-ike-peer-feita] remote-address 2.1.1.1
[Router-ike-peer-feita] exchange-mode main
[Router-ike-peer-feita] dpd type periodic
[Router-ike-peer-feita] dpd msg seq-hash-notify
[Router-ike-peer-feita] quit
[Router] ipsec policy map1 10 isakmp
[Router-ipsec-policy-isakmp-map1-10] ike-peer feita
[Router-ipsec-policy-isakmp-map1-10] proposal tran1
[Router-ipsec-policy-isakmp-map1-10] security acl 3101
[Router-ipsec-policy-isakmp-map1-10] sa duration time-based 3600
[Router-ipsec-policy-isakmp-map1-10] quit
[Router] interface gigabitethernet 0/0/1
[Router-GigabitEthernet0/0/1] ipsec policy map1
[Router-GigabitEthernet0/0/1] quitChecking the result on the Huawei side after applying:
[Router] display ike proposal number 5
-------------------------------------------
IKE Proposal: 5
Authentication method : pre-shared
Authentication algorithm : SHA2-512
Encryption algorithm : AES-CBC-256
DH group : MODP-2048
SA duration : 28800
PRF : PRF-HMAC-SHA2-256
-------------------------------------------
[Router] display ipsec proposal
Number of proposals: 1
IPsec proposal name: tran1
Encapsulation mode: Tunnel
Transform : esp-new
ESP protocol : Authentication SHA2-HMAC-512
Encryption AES-256FortiGate is configured through its web GUI here rather than the CLI — the source guide this note is based on walks through the wizard screens, not command syntax.
Menu names and screen layout can vary between FortiOS releases; the sequence of concepts — Network, Authentication, IKE, Phase 1 Proposal, Phase 2 Selectors, Phase 2 Proposal — stays the same across recent versions.
These account for most of the tunnels that build fine and still don't pass the traffic they're supposed to.
SYMPTOMDead Peer Detection is enabled, and the tunnel behaves unpredictably instead of cleanly detecting a dead peer.
CAUSEFortinet'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 FortiGate side.
FIXOn the Huawei router, set the DPD message format to seq-hash-notify so it matches what the FortiGate side expects.
[Router-ike-peer-feita] dpd type periodic
[Router-ike-peer-feita] dpd msg seq-hash-notifySYMPTOMWithout the fix below, this exact pairing would show phase 1 and phase 2 as established, then fail to pass traffic, or pass only part of it — the classic "tunnel is up, data isn't" symptom.
CAUSEWhen the Huawei router and the other vendor's device both use a SHA-2 algorithm in the IPSec security proposal — SHA2-512 in this example — their SHA-2 encryption/decryption implementations can differ just enough that the tunnel negotiates fine but the data plane doesn't.
FIXEnable SHA-2 compatibility mode on the Huawei router as a standard step whenever SHA-2 is in the proposal, rather than waiting for a broken-traffic report.
[Router] ipsec authentication sha2 compatible enableSYMPTOMPhase 1 (IKE) establishes cleanly, but phase 2 (quick mode / IPSec SA) never comes up, or comes up and drops repeatedly.
CAUSEThe Huawei ACL defines protected traffic as source 10.1.1.0/24 to destination 10.2.1.0/24; the FortiGate Phase 2 Selectors must define the exact mirror image — local 10.2.1.0/24 (or whatever the actual HQ subnet is), remote 10.1.1.0/24. If the two traffic selectors are not reverse-symmetric, phase 2 proposal matching fails even though phase 1 succeeded.
FIXCheck both sides' traffic selectors side by side before troubleshooting anything else in phase 2 — a mismatch here is far more common than a cipher mismatch.
SYMPTOMThe peer was configured expecting IKEv1 specifically, but negotiation behaves like IKEv2 is in play, or the two ends fail to agree on a version.
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 — as this example does, matching the FortiGate side's IKE Version field set to 1 — has to be configured explicitly.
FIXConfigure the peer for v1 explicitly, and confirm the FortiGate IKE Version field is also set to 1, not 2.
[Router] ike peer feita v1SYMPTOMA static route or ACL rule copied from a configuration guide references a subnet that doesn't match the guide's own addressing table for the same scenario.
CAUSEConfiguration guides are frequently built by adapting a previous worked example. A route or rule can end up still pointing at a subnet used in an earlier, different example instead of the one the current data-plan table actually documents.
FIXRe-derive every address in a copied ACL or static route from your own network's addressing plan before applying it — never assume a worked example's own internal consistency.
"Established" in the SA table is necessary but not sufficient — check the packet counters too.
[Router] display ike sa
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------
16 2.1.1.1 0 RD|ST 2
14 2.1.1.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, 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 — including the ACL/Phase 2 Selectors mirror described in Gotcha 3.
Questions this exact Huawei-Fortinet pairing comes up with most.
Either can work in principle, but the worked example this note is based on uses ACL-based IPSec on the Huawei side, matching a FortiGate custom IPSec tunnel with defined Phase 2 Selectors on the GUI side. If you want the Tunnel-interface (VTI) approach instead, see our separate Huawei-to-Cisco VTI note for the logic — the same routing-driven reasoning applies against a FortiGate that supports route-based VPN.
Because this example already runs SHA2-512 on both IKE and IPSec proposals. SHA-2 compatibility between vendors is exactly the kind of thing that builds a tunnel fine but breaks the data plane silently, so enabling it upfront — rather than waiting for a broken-traffic ticket — is the safer default whenever both ends negotiate a SHA-2 algorithm.
On the FortiGate GUI, Phase 1 Proposal covers the same ground as a Huawei ike proposal — encryption, authentication, DH group and key lifetime for the IKE SA. Phase 2 Proposal covers the same ground as a Huawei ipsec proposal — encryption, authentication and lifetime for the IPSec SA. Phase 2 Selectors is the FortiGate equivalent of the ACL that defines protected traffic on the Huawei side.
Yes, in reverse. The Huawei ACL permits traffic from the branch subnet to the headquarters subnet; the FortiGate Phase 2 Selectors must define the mirror image — headquarters subnet as local, branch subnet as remote. If either side's traffic selector does not match its peer's in reverse, phase 2 negotiation fails even though phase 1 succeeded.
Copy the command syntax, not the addressing. Configuration guides are frequently adapted from other worked examples, and a static route or subnet reference can end up pointing at an address left over from a previous example instead of the one actually in use. Always re-derive the addressing from your own network before applying a copied configuration.
This note is based on one worked configuration: a Huawei router (IKEv1, main mode, pre-shared key, AES-256 / SHA2-512, ACL-based) reaching a Fortinet FortiGate firewall. FortiOS menu wording shifts slightly between versions; IKEv2, VTI/route-based VPN on the FortiGate side, NAT traversal, and a dynamic-IP branch each shift the details further. This note covers the ACL-based method against Fortinet, not every combination.
Device models, FortiOS version 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.