A tunnel that refuses to form, or comes up and still won't pass traffic, is one of the most common problems in site-to-site IPSec. This is the diagnostic order that finds the fault fastest — where to look at each stage, the display commands to run, and the root causes that account for most of these tickets.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
I keep coming back to the same short sequence of checks — not because IPSec is simple, but because the ways it breaks repeat.
An IPSec tunnel that won't come up, or comes up and still won't pass traffic, is one of the most common problems in site-to-site connectivity. The instinct is to start changing settings on both ends at once — but it's much faster to work through the negotiation stages in order: whether IKE negotiation is even triggered, whether phase 1 (the IKE SA) completes, whether phase 2 (the IPSec SA) completes, and only then whether the protected traffic itself is actually flowing.
What follows is the fault tree this is built on, the checks for each stage with the exact commands to run, the root causes that show up again and again once you're past the first few checks, and a handful of real FAQ answers pulled from actual field cases.
IPSec failures split into exactly two shapes: the tunnel never comes up, or it comes up and something's still wrong.
Placing the symptom on this tree first saves a lot of backtracking later — it tells you which of the sections below actually applies to what you're looking at.
Diagram labels are kept in English for engineering clarity.
IKE SA or IPSec SA negotiation failure is the core of most IPSec faults, and worth analyzing against the negotiation process directly. Almost everything else on this tree — an interface, a route, an ACL, a NAT rule — is a plain misconfiguration in a different feature that has to be chased down in its own context, not in the IPSec process itself.
Four stages, four different sets of things to look at — and the command that tells you which stage you're actually stuck in.
If display ike sa shows nothing at all, don't assume phase 1 failed — check whether negotiation was ever triggered in the first place.
<Huawei> display ipsec policy
===========================================
IPSec policy group: "10"
Using interface: GigabitEthernet1/0/0
===========================================
Sequence number: 10
Security data flow: 3100/IPv4
SA trigger mode: Traffic-based // default trigger mode
<Huawei> display ipsec statistics
negotiate about packet statistics:
IKE ctrl packet inbound ok: 0, outbound ok: 0
trigger ok: 0, switch sa: 0, sync sa: 0
// outbound ok = 0 -> no IKE packet has left this router yet
<Huawei> display ipsec interface brief
------------------------------------------------
IPSec policy : policy1
Using interface : GigabitEthernet1/0/0
------------------------------------------------
<Huawei> display acl 3100
Advanced ACL 3100, 1 rule
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 (0 times matched)Three different counter combinations on display ipsec statistics point to three different places to look — worth checking before anything else.
<Router1> display ipsec statistics
negotiate about packet statistics:
IKE ctrl packet inbound ok: 0, outbound ok: 4
// outbound ok not 0 but the peer's inbound stays 0 -> peer never received it
<Router> display ike peer name 1
------------------------------------------
Remote IP : 1.1.1.1(www.huawei.com)
IKE version : v1
Exchange mode : main on phase 1
Local ID type : IP
Remote ID type : any
NAT-traversal : Enable
<Router> display ike proposal number 10
-------------------------------------------
Authentication Method : PRE_SHARED
Authentication Algorithm : SHA2-256
Encryption Algorithm : AES-256
Diffie-Hellman Group : MODP-2048
Prf Algorithm : HMAC-SHA2-256
-------------------------------------------Phase 1 succeeds, display ike sa shows an established SA, but there's still no IPSec SA — this is almost always the ACL or the proposal.
<Huawei> display acl 3100
Advanced ACL 3100, 1 rule
rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
// the peer's rule should mirror this: source 10.1.1.0/24 destination 10.1.2.0/24
<Huawei> display ipsec proposal
IPSec proposal name: p1
Encapsulation mode: Tunnel
Transform : ah-esp-new
ESP protocol : Authentication SHA2-HMAC-256
Encryption AES-256
<Huawei> display ipsec policy brief
Policy name Mode ACL Peer name
policy1-100 isakmp 3002/IPv4 peer1
// Perfect forward secrecy: DH group 14 -- must match on both ends if configureddisplay ipsec sa shows an established SA on both ends — that confirms the tunnel exists, not that traffic is using it.
<Huawei> display ipsec sa
-----------------------------
Flow source : 10.1.0.0/255.255.0.0 0/0
Flow destination : 10.2.0.0/255.255.0.0 0/0
// compare this against the real business subnets, not just "tunnel is up"
<Huawei> display ike peer
NAT-traversal : Enable
<Huawei> display ipsec proposal
Transform : esp-new // must be ESP, not AH, when NAT-T is in play
<Huawei> display ipsec statistics
dropped security packet detail:
authentication: 33, replay: 0
// non-zero authentication drops with SHA-2 in the proposal -> compat mode needed
[Huawei] ipsec authentication sha2 compatible enableOnce the four stages above have told you where the problem sits, these six account for most of what's actually wrong.
SYMPTOMIKE SA never forms — display ike sa stays empty or shows the connection stuck negotiating, and this is the only phase-1 parameter that still looks unconfirmed.
CAUSEWith pre-shared key authentication, both ends' keys have to be identical, character for character. Because the configured key is stored and displayed in cipher form, a typo on either end isn't something you can catch by reading the running configuration back — the two ends can each look "configured" and still not match.
FIXRe-enter the same plaintext key on both ends deliberately, rather than trusting that a previously copied value is still correct on both sides.
[Router] ike peer huawei
[Router-ike-peer-huawei] pre-shared-key cipher <same-key-on-both-ends>SYMPTOMdisplay ike error-info reports phase1 proposal mismatch.
CAUSEIn one real case on this exact fault code, one router's IKE proposal used AES-128 while the peer (a different vendor's device) used AES-256 — a single differing parameter is enough to fail the whole phase-1 negotiation.
FIXCompare display ike proposal side by side; when the peer is a different vendor and you can't get its configuration directly, debugging ikev1 all (or debugging ikev2 all) on your own router shows you the proposal attributes the other side actually sent.
<AR1> display ike error-info
peer port error-reason version error-time
2.1.1.1 500 phase1 proposal mismatch v1 2017-09-05 15:22:32
// debugging ikev1 all on AR1 showed what the peer actually sent:
Attribute ENCRYPTION_ALGORITHM value AES_CBC
Attribute KEY_LENGTH value 256
Attribute HASH_ALGORITHM value SHA2-256
Attribute AUTHENTICATION_METHOD value PRE_SHARED
Attribute GROUP_DESCRIPTION value MODP_2048
// AR1 was configured for AES-128; the peer proposed AES-256 -- align the two
[AR1] ike proposal 10
[AR1-ike-proposal-10] encryption-algorithm aes-256SYMPTOMIPSec SA fails to negotiate at all, or — in a hub with several branches — only one branch's traffic won't pass while the others are fine.
CAUSEThe two ends' ACLs should be mirror images of each other (source and destination swapped); when they're not, negotiation only succeeds if the initiator's range is a subset of the responder's. Separately, when a hub has several branch tunnels, overlapping address ranges across different ACLs in the same policy group cause one branch's traffic to be silently claimed by another branch's tunnel.
FIXMirror the ACL source/destination on both ends, and make sure no two ACLs referenced by the same IPSec policy group have overlapping rule ranges.
SYMPTOMTunnel shows established on both ends, but the outbound encapsulation counter never moves — no encrypted packets are actually being sent.
CAUSEOn a router that's also doing NAT, NAT is applied before IPSec in the forwarding order. If the NAT ACL still matches the traffic meant for the tunnel, that traffic gets translated and routed out to the internet instead of into the tunnel — no error, no log, nothing to look for except a stuck packet counter. Separately, when there's a NAT device between the two peers, both ends need NAT traversal explicitly enabled, and the security protocol has to be ESP — AH doesn't survive address translation.
FIXAdd a deny rule for the tunnel's protected addresses at the top of the NAT ACL so that traffic never gets translated in the first place; enable nat traversal on both IKE peers when a NAT device sits in the path; and use ESP, not AH, whenever NAT-T is involved.
acl number 3300
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
[Router-ike-peer-huawei] nat traversalSYMPTOMThe tunnel isn't down for any obvious reason, but it flaps — drops and rebuilds — even though the link and both routers are fine.
CAUSEDead Peer Detection has to agree on the payload sequence used in its own keepalive packets. When the two ends' DPD message order doesn't match, DPD silently fails to confirm the peer is alive, and the tunnel gets torn down and rebuilt on a false alarm.
FIXConfigure identical DPD parameters on both ends — message sequence, detection mode, idle time, retransmit interval, retry limit.
[Router-ike-peer-huawei] dpd msg seq-hash-notify
[Router-ike-peer-huawei] dpd type periodic
[Router-ike-peer-huawei] dpd idle-time 20
[Router-ike-peer-huawei] dpd retransmit-interval 10
[Router-ike-peer-huawei] dpd retry-limit 4SYMPTOMLogs show repeated phase1 hard expiry or phase2 hard expiry events, and the tunnel seems to renegotiate more often — or less symmetrically — than you'd expect.
CAUSEThe IKE SA and IPSec SA both carry a configured lifetime (sa duration, or the global ipsec sa global-duration). If the two ends aren't configured with the same value, one side ages its SA out and starts renegotiating while the other is still holding the old one, which shows up as unnecessary churn rather than a clean, simultaneous renewal.
FIXCompare the SA Duration field from display ike proposal and the equivalent IPSec SA duration on both ends, and set them equal with sa duration or ipsec sa global-duration.
<sysname> display ike proposal number 10
SA Duration(Seconds) : 86400
<sysname> display ipsec global config
IPSec sa global-duration time-based(seconds) : 3600Pulled straight from the field — the ones worth having an answer ready for.
AH (Authentication Header) gives you data-origin authentication, integrity checking and anti-replay, but it doesn't encrypt the payload at all — it's for traffic where confidentiality doesn't matter but tampering does. ESP (Encapsulating Security Payload) does everything AH does, plus it can encrypt the payload, and can be configured for encryption only, authentication only, or both. The two can be combined on the same tunnel; when they are, ESP is applied first, then AH, for extra assurance.
Ping to confirm public-network reachability first. If the tunnel is IKE-negotiated, check display ike sa — if phase 1 hasn't even established, that's your answer. If phase 1 looks fine, wait roughly ten seconds and check again; SA installation isn't always instant. Then confirm the interface carrying the IPSec policy is actually Up, and only then start reviewing the IPSec configuration itself.
Yes. The fixed-IP end configures a policy-template-based IPSec policy that doesn't require knowing the peer's address in advance, and its IKE peer entry simply omits remote-address. The dynamic-IP end configures normally, pointing remote-address at the fixed peer. Whichever end has the unpredictable address has to be the one that initiates.
This usually means a new branch is trying to protect traffic that overlaps with a data flow an existing tunnel at the hub is already protecting. The conflict blocks the new negotiation outright, and only clears once the old tunnel is torn down — which a restart forces. ipsec remote traffic-identical accept lets a new peer with an identical protected-flow definition take over quickly, aging out the old SA instead of being blocked by it.
Four usual suspects: CPU load from other features (attack-defense, other SAs) running alongside IPSec; a DPD payload-order mismatch causing the tunnel to flap on false dead-peer alarms; ordinary internet path loss upstream of the tunnel; and IP fragmentation — IPSec's own encapsulation overhead pushes packets over the path MTU, and both fragmenting and reassembling encrypted traffic cost CPU that a busy router doesn't always have to spare. Testing with different ping sizes to find the breakpoint, then adjusting the interface MTU and tcp adjust-mss, is the standard fix for the last one.
This note is built around the Huawei AR-series router's IPSec fault-classification model and its display ike sa / ipsec sa / ipsec statistics commands, plus the field cases behind them. If your gateway is a different vendor, the exact commands change, but the underlying negotiation logic — trigger, phase 1, phase 2, ACL matching, NAT interaction, DPD, SA lifetime — carries over directly. It doesn't cover IKEv2-specific edge cases like EAP or digital-envelope authentication in depth, or SD-WAN overlay scenarios.
Tell us which stage it's stuck at — phase 1, phase 2, or up-but-not-passing-traffic — plus the display ike sa / display ipsec sa output, and we'll help you read it.