On a firewall, IPSec doesn't run on its own — every packet the tunnel sends or protects still has to clear the security-policy engine first. This is the configuration this note is based on: security zones and interfaces, IKE and IPSec parameters, and — the part a router-only background misses — the security-policy rules that separately permit the tunnel's own negotiation traffic and the private traffic it protects.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
On a firewall, the security policy decides whether the tunnel's own negotiation traffic — and the traffic it protects — is even allowed to reach IPSec in the first place.
On a router, IPSec is largely self-contained: point the traffic at an ACL, negotiate, done. A firewall adds a layer in the way by design — every packet, including the IKE negotiation packets and the ESP-encapsulated payload itself, still has to clear the security-policy engine and its zone-to-zone rules before IPSec ever gets a chance to process it. That means an IPSec configuration that would work fine on a router — proposal, peer, policy, ACL, all correct — can sit there fully configured on a firewall and still refuse to pass a single packet, because the security policy denied it before IPSec had anything to do.
This note is written for the firewall side specifically: configuring security zones, security-policy rules and IPSec VPN together on a Huawei USG so both layers agree with each other. If you're building the tunnel between a Huawei AR router and a different vendor's firewall instead, see our Huawei-to-Fortinet interop configuration guide; if a tunnel is already up but something's still wrong, see our IPSec tunnel troubleshooting flowchart — both of those are written from the router side of this exact problem, not the firewall side covered here.
Two firewalls, two private LANs, one IPSec tunnel across the internet — plus the zone map that decides whether any of it is actually allowed to happen.
Diagram labels are kept in English for engineering clarity.
Addressing
| Item | Value (this example) |
|---|---|
| FW1 trust interface — GigabitEthernet1/0/0 | 10.1.1.1/24 |
| FW1 untrust (public) interface — GigabitEthernet1/0/1 | 1.1.1.1/24 |
| FW2 untrust (public) interface — the tunnel peer | 2.1.1.1/24 |
| Protected subnet behind FW1 | 10.1.1.0/24 |
| Protected subnet behind FW2 | 10.1.2.0/24 |
Assign the interfaces to zones, configure IKE and IPSec, apply the policy — then, the step a router doesn't need, write the security-policy rules for both the tunnel's own traffic and the traffic it protects.
#
firewall zone trust
set priority 85
add interface GigabitEthernet1/0/0
#
firewall zone untrust
set priority 5
add interface GigabitEthernet1/0/1
#
ike proposal 10
authentication-method pre-shared-key
authentication-algorithm sha2-256
encryption-algorithm aes-256
dh group14
prf hmac-sha2-256
#
ike peer huawei
ike-proposal 10
pre-shared-key cipher <same-key-on-both-ends>
remote-address 2.1.1.1
#
ipsec proposal p1
esp authentication-algorithm sha2-256
esp encryption-algorithm aes-256
#
acl number 3100
rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
#
ipsec policy policy1 10 isakmp
security acl 3100
ike-peer huawei
proposal p1
#
interface GigabitEthernet1/0/0
ip address 10.1.1.1 255.255.255.0
#
interface GigabitEthernet1/0/1
ip address 1.1.1.1 255.255.255.0
ipsec policy policy1
#
ip route-static 0.0.0.0 0.0.0.0 1.1.1.254
#This is the part a router-only IPSec background misses entirely — two separate pairs of rules, not one, and neither is optional.
security-policy
rule name ike-esp-out
source-zone local
destination-zone untrust
source-address 1.1.1.1 mask 255.255.255.255
destination-address 2.1.1.1 mask 255.255.255.255
action permit
rule name ike-esp-in
source-zone untrust
destination-zone local
source-address 2.1.1.1 mask 255.255.255.255
destination-address 1.1.1.1 mask 255.255.255.255
action permit
rule name private-out
source-zone trust
destination-zone untrust
source-address 10.1.1.0 mask 255.255.255.0
destination-address 10.1.2.0 mask 255.255.255.0
action permit
rule name private-in
source-zone untrust
destination-zone trust
source-address 10.1.2.0 mask 255.255.255.0
destination-address 10.1.1.0 mask 255.255.255.0
action permitThis exact rule pattern — one pair for the tunnel's own IKE/ESP traffic in the local zone, one pair for the private traffic in trust/untrust — comes directly from a real fault case where the tunnel showed as established on both ends, yet the two private LANs still couldn't reach each other, because only the first pair had been configured.
The ones that turn a working IPSec configuration into a tunnel that negotiates fine and still doesn't pass a single packet.
SYMPTOMdisplay ike sa shows the IKE SA as established on both firewalls, but nothing ever seems to negotiate, or negotiation restarts constantly.
CAUSEThe IKE negotiation packets (UDP 500/4500) and the ESP-protocol packets themselves have to reach the firewall and be permitted, exactly like any other traffic destined to the device. If the security policy doesn't explicitly permit UDP 500/4500 and AH/ESP protocol traffic to and from the firewall's own public address, the tunnel has no path to negotiate over in the first place.
FIXConfigure a dedicated security-policy rule pair permitting UDP 500/4500 and AH/ESP protocol traffic between the firewall's own address and the peer's — this is separate from, and in addition to, the rule that permits the private traffic itself.
SYMPTOMdisplay ike sa shows the tunnel as fully established on both ends, but hosts on the two private LANs still can't reach each other.
CAUSEThe IPSec ACL only defines which traffic gets encrypted and sent into the tunnel — it says nothing about whether the security-policy engine actually permits that traffic across zones. Without a separate security-policy rule permitting the private subnets between the trust and untrust zones, the traffic never gets to the point where IPSec would encrypt it.
FIXConfigure the trust-to-untrust and untrust-to-trust security-policy rule pair for the real private subnets, in addition to the IPSec ACL — the two serve different purposes and neither one covers for the other.
SYMPTOMA security-policy rule was written for untrust-to-trust or trust-to-untrust to cover the tunnel traffic, and it still doesn't work, even though the addresses look correct.
CAUSETraffic destined to the firewall's own IP address — which is exactly what IKE negotiation and the terminating end of ESP are — is evaluated against the local zone, regardless of which physical interface or zone it arrived on. A rule written for trust or untrust as the destination zone will never match this traffic.
FIXWrite the rule pair for the tunnel's own traffic with local as the zone on whichever side is this device, and confirm it in display firewall session table verbose — a working IKE session shows Zone: local --> untrust (or the reverse), not trust --> untrust.
<FW1> display firewall session table verbose
udp VPN: public --> public ID: a68f5bd4603f01f756c5ab54663
Zone: local --> untrust TTL: 00:02:00 Left: 00:01:58
1.1.1.1:500 --> 2.1.1.1:500 PolicyName: ike-esp-outSYMPTOMPhase 1 negotiates successfully in one exchange mode during testing, then fails once the peer's configuration changes slightly, or once switched to a different exchange mode.
CAUSEAs the initiator, if the ike peer has an ike-proposal explicitly referenced, that exact proposal is sent for negotiation. If it isn't referenced, main mode sends every locally configured IKE proposal for the peer to choose from, while aggressive mode sends only the default proposal — two different behaviors from the same missing configuration line, depending on which exchange mode is active.
FIXAlways reference an explicit ike-proposal under the ike peer rather than relying on exchange-mode-dependent defaults, so the same set of parameters is offered regardless of which mode ends up being used.
ike peer huawei
ike-proposal 10
remote-address 2.1.1.1SYMPTOMSome traffic between the two sites goes through the tunnel encrypted as expected; other traffic between what looks like the same two subnets is dropped, or goes out unencrypted.
CAUSEThe IPSec ACL and the security-policy rule addresses were configured at different times, by different people, or copied from different examples, and their subnet ranges no longer describe exactly the same traffic. Traffic that matches the security policy but falls outside the IPSec ACL's range never gets encrypted; traffic that matches the ACL but falls outside the security-policy range never gets there at all.
FIXKeep the IPSec ACL's permit rule and the security-policy rule's source/destination addresses defined from the same source of truth, and re-verify both together any time either one changes — not just the one that was edited.
An established IKE SA is necessary but not sufficient — confirm the security-policy rules are the ones actually being hit, not just present.
<FW1> display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase
---------------------------------------------------------------
151003222 2.1.1.1:500 RD|ST|A v1:2
151003215 2.1.1.1:500 RD|ST|A v1:1
Number of IKE SA : 2
<FW1> display firewall session table verbose
udp VPN: public --> public ID: a68f5bd4603f01f756c5ab54663
Zone: local --> untrust TTL: 00:02:00 Left: 00:01:58
1.1.1.1:500 --> 2.1.1.1:500 PolicyName: ike-esp-out
<FW1> display current-configuration configuration policy-security
security-policy
rule name ike-esp-out
source-zone local
destination-zone untrust
action permit
rule name private-out
source-zone trust
destination-zone untrust
action permitThis note is based on one worked configuration: two Huawei USG-series firewalls, ACL-based IKEv1 IPSec, one protected subnet pair each side, security-policy rules covering the tunnel and the private traffic. It doesn't cover IKEv2-specific configuration nuances, VTI (route-based) IPSec on a firewall, NAT coexisting with this same IPSec policy on the same interface, virtual-system (vsys) specific policy separation, or high-availability/dual-active firewall pairs — those each change enough of the configuration to need their own treatment.
Pulled from the same configuration cases this note is built on.
Yes, always both. The IKE/ESP rule permits the tunnel's own negotiation and encrypted payload to reach the device (local zone); the private-traffic rule permits the actual business traffic to cross from trust to untrust so IPSec has something to encrypt in the first place. Either one missing produces a tunnel that looks fine in display ike sa and still doesn't do anything useful.
Local — because it's destined to the firewall's own public IP address, not routed through it. This is true regardless of which physical interface or which zone that interface was assigned to; a rule written with trust or untrust as the destination zone for this traffic will never match it.
Technically the traffic would pass either way, but a broad default permit is not the production-safe posture this note assumes, and it makes troubleshooting far harder later — display security-policy rule's hit counts become meaningless when everything matches one catch-all rule. Configure the specific rule pairs regardless, and move to default action deny once they're confirmed working.
The IKE and IPSec parameters themselves — proposal, peer, policy, ACL — are essentially the same concepts on both platforms. What a router doesn't have is the security-policy layer sitting in front of IPSec: on a router, once the ACL and interface configuration are correct, traffic reaches IPSec directly. On this firewall, the security policy has to separately permit both the tunnel's own traffic and the protected traffic before IPSec gets a chance to act on either. See our Huawei-to-Fortinet configuration guide and our IPSec tunnel troubleshooting flowchart for the router-side version of this same tunnel logic.
Yes, but the same rule that governs routers applies here too: NAT is evaluated before IPSec in the forwarding order, so the NAT policy's matching ACL must explicitly exclude the traffic destined for the tunnel's protected subnets, or that traffic gets translated and sent to the internet instead of encrypted into the tunnel — with no error to point at except a stuck encryption counter.
Tell us your zone layout and which subnets need to cross the tunnel, and we'll help you get the security-policy rules right the first time.