IPsec IKEv2 Troubleshooting: SA_INIT and IKE_AUTH Debugs

IKEv2 debugs look intimidating because they print every packet of two interleaved exchanges. In practice one rule organises all of it: SA_INIT is IKEv1 main mode in two messages, IKE_AUTH covers authentication plus the first child SA. Find out which of the two failed and the fault class narrows immediately. This article explains the message flow, the log lines that identify each failure, and the checks that resolve them.

The Exchange in Four Messages

1. SA_INIT request (initiator to responder): proposes crypto suites, DH group, nonce.
2. SA_INIT response: the responder picks a proposal and sends its DH material.
3. IKE_AUTH request: identities, authentication material (PSK or certificate), traffic selectors and the first child SA proposal.
4. IKE_AUTH response: responder authenticates, confirms the child SA. The tunnel exists after this message.

Rekeying and additional selectors later use CREATE_CHILD_SA, which is why a tunnel that works for one subnet pair and not another fails at that stage rather than at startup.

IKEv2 Versus IKEv1 in the Logs

Most engineers learn IPsec on IKEv1 and then read IKEv2 debugs expecting the same shape. They are not the same shape. IKEv1 main mode is a six-message exchange with a separate aggressive mode, a separate quick mode for Phase 2, and an explicit phase boundary that the logs mark clearly. IKEv2 collapses the same work into two exchanges of two messages each, does away with aggressive mode entirely, and folds the first child SA into the IKE_AUTH exchange rather than giving it a phase of its own.

What that means in practice:

• "Phase 1" and "Phase 2" are conventions, not protocol terms. In IKEv2, SA_INIT plus IKE_AUTH together are what people call Phase 1, and the child SA negotiated inside IKE_AUTH is Phase 2. The logs do not label them that way, so you map the message name to the phase yourself.
• There is no aggressive mode. If a peer is configured for aggressive mode and the other expects IKEv2, the failure looks like a proposal or version mismatch, not a mode mismatch.
• Fewer round trips means less to read, but also less isolation. A child-SA failure surfaces inside the same exchange as the authentication failure, which is precisely why identifying which message failed is the whole diagnostic method.

Capturing the Right Debug

diagnose vpn ike log-filter clear
diagnose vpn ike log-filter dst-addr4 203.0.113.10
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable
! reproduce the failure, then:
diagnose debug disable
diagnose debug reset

Filter first, otherwise the console fills with unrelated peers. On Cisco IOS-XE the equivalents are debug crypto ikev2 packet plus debug crypto ikev2 internal, and on Junos set security ike traceoptions with a matching file name.

Two habits make a debug readable. First, enable timestamps before you enable the debug stream, not after - a debug without timestamps cannot be matched against a packet capture. Second, keep the capture window short. Ten seconds of IKE debug from a single peer is usually enough to see the four messages; ten minutes is a wall of text nobody will parse during an incident.

! Junos
set security ike traceoptions file ike-trace.log size 10m files 3
set security ike traceoptions flag packet detail
set security ike traceoptions flag ike detail
file show /var/log/ike-trace.log

Reading a Debug Line by Line

A single line of IKEv2 debug carries more information than it appears to. Take a typical responder-side line:

ike 0:HQ-to-Branch:42: responder received SA_INIT msg
ike 0:HQ-to-Branch:42: received cookie, errno 0

The pieces are: the daemon name, the Phase 1 name, a connection/SA counter, and then the event. The counter is the key to following a single negotiation through interleaved traffic - if two peers are negotiating at once, the counters tell you which lines belong together. The event name tells you which stage you are at, and that maps directly onto the four-message model above.

The same structure holds for failures, which is why the failure messages later in this article are quoted with their full prefix rather than just the error text.

Failure A - No Proposal Chosen

ike 0:HQ-to-Branch: responder received SA_INIT msg
ike 0:HQ-to-Branch: negotiation failure
ike 0:HQ-to-Branch: no SA proposal chosen

This is a Phase 1 mismatch: encryption, integrity, PRF, DH group or the IKE version itself. A proposal set is all-or-nothing - one complete bundle must match on both ends, and additional unused proposals on either side are harmless. Put both configurations in one table and compare field by field.

The usual culprits, in rough order of frequency:

• DH group. One side on group 14, the other on group 19 or 20. Modern defaults are not universal, and a device that silently prefers a stronger group will fail against a peer that was never updated.
• Encryption. AES-CBC versus AES-GCM. GCM is an AEAD cipher and does not take a separate integrity algorithm, so a configuration that pairs GCM with an integrity hash will not match a peer that expects a classic cipher plus hash.
• PRF. A field that is easy to leave at default on one end and set explicitly on the other.
• Version. One end set to IKEv1, the other to IKEv2, or v2-only against v1-any.

Because the proposal is negotiated as a bundle, the fix is not to add more proposals to one side but to make the two ends agree on one. Extra proposals on both sides are harmless; a missing match is fatal.

Failure B - Authentication Fails After SA_INIT

ike 0:HQ-to-Branch: AUTHENTICATION_FAILED
ike 0:HQ-to-Branch: PSK mismatch

Here the proposal matched and the PSK did not. Check for whitespace in the key, a wrong local or remote ID, or a certificate that expired. A PSK mismatch is deliberately indistinguishable from many other auth failures in the peer's view - it will not tell an attacker which side was wrong.

Where a PSK is genuinely identical on both ends, the failure is almost always the identity rather than the key:

• Local and remote IDs. One end is configured with an IP address as its ID and the other with an FQDN. The PSK is right; the identity that selects which PSK to use is not.
• Whitespace or a trailing newline pasted into one end of the key and not the other, which is invisible in both GUIs and fatal in both.
• Wildcard versus explicit peer IDs when several tunnels terminate on the same gateway, causing the wrong PSK to be selected for the correct peer.

For certificate-based authentication the failure text differs, and the causes are different: an expired certificate, a chain the peer cannot build because an intermediate is missing, a clock skew large enough to reject a valid certificate, or a subject/alternative-name that does not match the configured remote ID.

ike 0:HQ-to-Branch: failed to verify peer certificate
ike 0:HQ-to-Branch: received AUTHENTICATION_FAILED notify error

Failure C - Phase 1 Up, No Child SA

ike 0:HQ-to-Branch: no matching IPsec SA / selectors
ike 0:HQ-to-Branch: no SA proposal chosen (quick mode)

Phase 2 problems: ESP encryption or integrity differ, perfect forward secrecy is enabled on one side only, or the traffic selectors do not overlap. A one-sided PFS configuration is the classic Phase 2 killer; confirm both ends have the same PFS group or both have it disabled. Also verify the proxy IDs or subnet pairs match exactly, and that the routing or policy on each side actually sends interesting traffic.

A quick way to reason about this class: the IKE SA exists, so the two ends can talk IKE. Anything that fails after that is either a mismatch in how the data tunnel is built (ESP parameters, PFS) or a mismatch in what the data tunnel is asked to carry (selectors, proxy IDs). Separating those two questions usually finds the fault within a couple of configuration reads.

Failure Classification Table

The last row is the one people misdiagnose most often. A debug that shows repeated retransmissions of SA_INIT and nothing else is not a crypto problem at all - it is a reachability problem, and no amount of proposal comparison will fix it.

NAT-T and How It Changes the Exchange

When a NAT device sits between the peers, IKEv2 detects it during SA_INIT and switches to UDP port 4500 with the Non-ESP marker. That detection happens through the NAT_DETECTION_SOURCE and NAT_DETECTION_DESTINATION payloads, and it changes what a healthy debug looks like.

ike 0:HQ-to-Branch: detected NAT-T, switching to port 4500
ike 0:HQ-to-Branch: NAT-D payload mismatch, peer behind NAT

Consequences worth knowing: the debug will show the port switch mid-exchange and that is normal; a tunnel that negotiates but carries no traffic often has UDP 4500 blocked in one direction even though UDP 500 is open; and aggressively disabling NAT-T on a path that actually NATs produces an exchange that completes and then silently fails to carry ESP. If you see the SA_INIT exchange succeed and the tunnel come up but no traffic flow, check whether NAT became involved.

Post-Tunnel Checks

show crypto ikev2 sa
show crypto ipsec sa
show vpn ike gateway
diagnose vpn tunnel list

The tunnel being up does not mean traffic flows. Check the encaps and decaps counters on both ends, verify return routing, and remember MTU: an IKEv2/IPsec tunnel adds overhead, so TCP sessions that stall on large packets need MSS clamping. Working baseline configurations for the common platforms are in FortiGate site-to-site IPsec, Cisco ASA IPsec and Junos SRX route-based IPsec.

The classic "tunnel up, traffic dead" signature is an encaps counter climbing on one end and a decaps counter that does not move on the other. That is nearly always a routing or policy asymmetry rather than a crypto fault: the packets leave, arrive, and are dropped before they reach the tunnel on the far side.

DPD, Liveness and Tunnels That Drop After Working

A tunnel that establishes cleanly and then dies after thirty or sixty seconds has a different fault class again. Dead Peer Detection probes the peer for liveness; if the probe gets no reply, the SA is torn down and rebuilt. Reading the debug across the teardown is what tells you whether the failure is the peer going quiet or the DPD settings disagreeing.

ike 0:HQ-to-Branch: sending DPD probe
ike 0:HQ-to-Branch: DPD timeout, deleting IKE SA
ike 0:HQ-to-Branch: renegotiation initiated

If the SA is torn down and immediately rebuilt, and the cycle repeats on a timer, suspect a DPD interval shorter than the peer's response time, asymmetric routing that sends DPD probes down a path that never replies, or an idle timeout on an intermediate device. The negotiation itself is fine, and every proposal comparison you perform will come back clean.

Diagnosing From Both Ends

IKE debugs are only half a picture, because each side logs its own view and the two views deliberately do not agree. The initiator logs what it sent and what it received; the responder logs what it accepted and what it rejected. When one side says "no proposal chosen" and the other says "sent proposal", the disagreement is the diagnosis.

• Capture the same negotiation on both ends, with timestamps, before changing anything.
• Align by the SA counter and by time, then read the two columns side by side.
• Note which side generated the first rejection - that is the enforcing end, and its configuration is the one to compare against the proposal.

Enabling a debug is not a fix, and neither is clearing the SA. A tunnel that only works after clear crypto ikev2 sa has a rekeying problem, not a negotiation problem, and it will fail again on the next lifetime expiry.

FAQ

Why does the debug show proposals being sent but never answered? Usually reachability: UDP 500 or 4500 is blocked, or the responder is not listening on the address you are sending to. Rule out the network path before comparing crypto parameters.

Can a PSK be correct and authentication still fail? Yes. The identity determines which PSK is used, so a correct key with a mismatched local or remote ID fails identically to a wrong key.

What does a one-sided PFS setting look like in the log? The IKE SA comes up, IKE_AUTH completes far enough to negotiate selectors, and the child SA proposal fails with a no-proposal message on the responder. One end offers PFS and the other does not, so no child-SA bundle is ever matched.

Should I disable NAT-T to simplify debugging? No. If there is a NAT on the path, disabling NAT-T produces an exchange that completes and then does not pass traffic - a much harder symptom to diagnose than the port switch you were trying to avoid.

More IKEv2 baselines and platform specifics: FortiGate IPsec site-to-site, Cisco ASA site-to-site IPsec CLI, Palo Alto site-to-site IPsec VPN, Junos SRX route-based IPsec and MTU, MSS and PMTUD troubleshooting.

原文链接：https://community.fortinet.com/t5/FortiGate/Technical-Tip-Understanding-the-ikev2-debugs/ta-p/274643