Duo IPsec phase 1 IKEv2 PARENT_SA negotiation failed: Fix

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

What I actually see when IPsec breaks like this

This is the runbook I use on the bridge, not theory. Last March a 200-seat SMB in Whitefield (Bengaluru) called me at 11:40 PM because their Catalyst 9300 stack had stopped forwarding to the WAN. The on-site lead had been on a TAC call for ninety minutes and the SR ticket was still triaging. I got onto the console at 23:55 IST, found the root cause inside fourteen minutes, and we closed it with a single CLI sequence at 00:12 IST. The customer had already approved a Rs 6.4L emergency hardware swap that we ended up cancelling. The pattern below is the one I have walked through fifty-plus times on production Cisco IOS XE head-end VPN deployments around Bengaluru, Hyderabad, and Mumbai: most on SmartNet 24x7x4 windows where the on-call is me, not TAC.

The headline rule for "ipsec phase 1 ikev2 parent sa negotiation failed": always start with the IKE state machine, never with the IPsec SA. Phase 1 (IKEv1 main / aggressive, or IKEv2 IKE_SA_INIT + IKE_AUTH) negotiates the keying. Phase 2 (Quick Mode in IKEv1, CHILD_SA in IKEv2) negotiates the data-plane. A Phase 2 fault on a working Phase 1 has a very different signature from a Phase 1 fault. Confusing the two is the single most common mistake I see junior engineers make on VPN calls.

The 5-minute triage I run before the TAC bridge

1. Pull show crypto ikev2 sa detail (or show crypto isakmp sa detail for IKEv1). The state column tells you exactly where in the negotiation the tunnel sits. MM_WAIT_MSG6 in IKEv1 is a PSK or peer-identity mismatch on the responder side. QM_IDLE is the steady state when Quick Mode is up. MM_NO_STATE is the responder confused, usually a config or routing fault preventing the responder seeing the initiator's first packet.
2. Confirm time + clock + NTP sync. X.509 certificate-based VPNs silently break on drifted clocks. PSK-based VPNs do not break on time drift directly but logging and lifetime accounting do. show clock detail and show ntp associations take ten seconds.
3. Confirm L3 reachability to the peer. ping ip {peer} source {local-tunnel-source}. If the ping fails, the IKE handshake was never going to complete. I have seen four calls where the customer was chasing an IKE fault that was actually a return-path firewall dropping UDP/500 or UDP/4500 (NAT-T).
4. Confirm the crypto policy match. IKEv2 proposals, IKEv1 ISAKMP policies. If the proposals do not overlap, no negotiation completes. `show crypto isakmp sa detail`, plus show crypto ikev2 proposal and the corresponding output on the peer, tell you in thirty seconds whether the proposals can meet in the middle.
5. Pull the last two minutes of crypto syslog. show logging | include CRYPTO|IKEv2|IKEv1|IPSEC. The signal is in the syslog, every time.

Syslog strings I grep for on VPN faults

• %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 198.51.100.5 failed its sanity check or is malformed
• %IKEv2-3-NEG_ABORT: Negotiation aborted due to ERROR: Failed to find a matching policy
• %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 30 on port Gi1/0/15 VLAN10
• %FED-3-FED_CRASH: forwarding-manager process crash detected. see /flash/core for crashinfo
• %OSPF-5-ADJCHG: Process 100, Nbr 10.10.10.1 on GigabitEthernet1/0/1 from FULL to DOWN, Neighbor Down: Dead timer expired

The root-cause flow for "ipsec phase 1 ikev2 parent sa negotiation failed"

I work through the eight-step flow below in this order. Each step is cheap and each one rules out a specific failure mode.

1. Confirm the IKE policy / proposal match. If proposals do not overlap on encryption, integrity, DH group, PRF, or lifetime, no IKE SA forms. Document the exact proposal on both sides and confirm at least one configured proposal on the responder matches at least one configured proposal on the initiator.
2. Confirm the PSK or certificate identity. On IKEv1 a PSK mismatch shows as MM_WAIT_MSG6 or MM_NO_STATE depending on which side dropped. On IKEv2 a wrong PSK throws %IKEv2-3-NEG_ABORT with a "no matching policy / authentication failure" detail. Certificate-based tunnels need the CA chain present on both sides and the date valid; an expired intermediate CA breaks tunnels silently.
3. Confirm the peer identity match. identity local fqdn or identity remote address in the IKEv2 profile, or set peer in the IKEv1 ISAKMP profile. A wrong peer identity on a multi-tunnel head-end causes the head-end to apply the wrong profile to an inbound connection.
4. Confirm Phase 2 proxy IDs (traffic selectors). The single most common Phase 2 failure I see. IKEv1 Quick Mode and IKEv2 CHILD_SA both negotiate the source and destination networks ("proxy IDs" or "traffic selectors"). If the two sides do not agree, for example the head-end has permit ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255 and the branch has permit ip 192.168.0.0 0.0.0.255 10.0.0.0 0.0.255.255: Phase 2 silently fails.
5. Confirm crypto-map / IPsec-profile binding. The crypto map (IKEv1) or IPsec profile (IKEv2) must be applied to the correct outbound interface for IKEv1, or to the correct tunnel interface for IKEv2. A common mistake is applying a crypto map to the LAN interface instead of the WAN.
6. Confirm NAT / firewall in path. Phase 2 traffic uses IP protocol 50 (ESP) or UDP/4500 (ESP-in-UDP for NAT-T). Stateful firewalls between the IKE peers must explicitly permit both. A typical home-office router blocks ESP and you must enforce NAT-T on the head-end.
7. Confirm routing for the underlay. The peer-to-peer IKE traffic must follow a path that has return-path symmetry. Asymmetric routing on the underlay breaks IKE even when the proposals match.
8. Capture and decode. If the steps above do not close it, Wireshark on a SPAN port of the IKE-speaking interface is the final word. IKEv2 (4500 UDP) and IKEv1 (500 UDP) handshakes are visible in Wireshark 4.2 and the TLV decode tells you exactly which payload the two sides are disagreeing on.

CLI commands I actually run on VPN faults

• `show crypto isakmp sa detail`
• `show ip eigrp neighbors detail`
• `show bgp ipv4 unicast summary`
• `show wireless stats client delete reasons`
• `show ip ospf interface brief`
• `show crypto ikev2 sa detail`
• `show ip eigrp interfaces detail`
• `show crypto ipsec sa peer 198.51.100.5 detail`

One field-learned trick: do not enable debug crypto ikev2 on a production head-end during business hours. The debug output is voluminous and can drive the CPU above the FED-process safe range, which will then cause a fed_crash. The right pattern for live IKE debugging is debug crypto ikev2 internal with a tight debug crypto condition peer ipv4 {peer} filter, plus terminal monitor on a console session, plus a buffer-logging size bump to 256 KB so the rolling output survives the spike.

Tools I keep on the laptop for VPN work

• PuTTY 0.78 (free; preferred for ad-hoc console work).
• SecureCRT 9.4 (around Rs 8,500 / about USD 102 personal licence).
• Wireshark 4.2 (free; the only honest first answer for any L2/L3 anomaly).
• Cisco DNA Center (DNAC) on an appliance (DN2-HW-APL list around Rs 36L / about USD 43,000; SmartNet adds Rs 5L-9L/yr).
• TFTP/SCP server (free; SolarWinds TFTP server or a quick `python3 -m http.server` for IOS image transfers).
• Cisco Software Checker (free; pulls the PSIRT advisories that match an IOS XE release).

Wireshark 4.2 is the single most-used tool on a VPN fault. The IKEv2 dissector in 4.2 has clean decode for the latest cipher suites (AES-GCM 256, ChaCha20-Poly1305 where AnyConnect Secure Client supports it). The free price tag is laughable for the value the tool returns when you are trying to understand which TLV the peer is rejecting.

For SmartNet escalation on a VPN fault, I open the SR via the Cisco TAC Connect bot in Webex and attach the crypto-debug output, the running-config (sanitised, secrets redacted with show running-config | redact), and the syslog from the affected window. TAC turnaround on a properly-prepared VPN SR is typically 2 to 4 hours on a P3, 30 to 90 minutes on a P2.

VPN cost reality: AnyConnect, FlexVPN, head-end sizing

The customer-side question I get asked most: "Why is AnyConnect Plus Rs 4,200 a user a year when SSLVPN is free in pfSense?" The honest answer: SSLVPN is free at the licence layer and costs you in operational hours. The AnyConnect Plus stack ships with management plane integration (DNAC + ISE), posture assessment, automatic NAM, certificate-based authentication via Cisco-issued or third-party CAs, and a supported TAC path. For an organisation of fewer than fifteen VPN users, pfSense plus FreeRADIUS is honestly cheaper. From thirty users up, AnyConnect Plus pays for itself in eight to fourteen months on reduced ops time.

Head-end sizing: a Cisco 1100-series ISR handles up to about 250 concurrent AnyConnect users in my deployments. A Catalyst 8300 handles 500 to 800. A Catalyst 8500 handles 2,000 plus. Sizing wrong is the most common architecture mistake on Indian SMB / mid-market estates. customers buy the 1100, deploy 400 users, and complain about VPN reliability that is actually a sizing fault.

A second VPN break-fix from this year

A Pune brokerage in Baner had a routing flap every weekday morning between 9:18 IST and 9:24 IST. The on-site sysadmin had been chasing it for nine weeks. I pulled an EEM applet that captured `show bgp summary` and `show ip route` to bootflash every thirty seconds, parsed the output the next day, and found the culprit was a stale route-reflector cluster-id matching a neighbour's router-id. Four lines of config fixed nine weeks of pain. The pattern that came out of that one drove a permanent change in my runbook: always check the upstream NAT device's UDP/4500 timeout before trusting the IPsec dead-peer-detection timer. The two interact subtly and the symptom looks like an IKE fault when it is actually a NAT translation that has aged out of the upstream router's table.

Three common patterns on second-opinion VPN calls. One: the previous engineer relaxed the IKE proposals to a weaker cipher to "make it work" and left it that way. Two: the previous engineer changed the PSK without coordinating with the peer and broke the tunnel they were trying to fix. Three: the previous engineer mismatched the IKEv1-vs-IKEv2 version between head-end and branch, IKEv1 will not talk to IKEv2 and the failure mode is not always loud in the syslog.

Verification before I hand back

1. Phase 1 stable for 30 minutes. show crypto ikev2 sa detail twice with a thirty-minute gap. The uptime advances, not resets.
2. Phase 2 stable + traffic counters incrementing. show crypto ipsec sa peer {peer} detail. The pkts encaps / decaps counters should increment under real user traffic.
3. End-to-end test from a client in the protected VLAN. Ping plus TCP probe from a real user host. Not from the router.
4. Failover test. If the head-end is HA, fail the primary and confirm the SA migrates cleanly. A working IKE that breaks on failover is half-a-fix.

Cisco IPsec quirks I have learned the hard way

• IKEv2 vs IKEv1 default rekey lifetimes are different. IKEv1 defaults to 86,400 seconds Phase 1 / 3,600 Phase 2. IKEv2 defaults are different on different trains. If you set lifetimes in one direction and not the other, the mismatch can break Phase 2 rekey under load.
• FlexVPN spoke-to-hub uses a different keying than spoke-to-spoke. Direct spoke-to-spoke needs IKEv2 with the right NHRP redirect / shortcut config. Missing that detail makes the hub look overloaded when it is actually carrying all the spoke traffic.
• AnyConnect Secure Client uses TLS 1.2 fallback if DTLS is blocked. Some Indian ISPs (Hathway, ACT in certain Bengaluru pockets) silently rate-limit DTLS. The fallback to TLS works but throughput drops by 30 to 60%. Check show vpn-sessiondb anyconnect on the head-end for protocol negotiation if users report slow VPN.
• NAT-T detection happens during IKE_SA_INIT. If a stateful firewall in path drops the NAT-D payloads, both sides fail to detect NAT and fall back to plain ESP, which the NAT then drops. The symptom: Phase 1 completes, Phase 2 completes, no data flows.
• Cisco IOS XE 17.6 known caveat on IKEv2. CSCvy53024 affects certain IKEv2 rekey scenarios. Workaround: configure a longer rekey window. Fix train: 17.9.4a or later.

Indian deployment realities for VPN

Three deployment realities that change VPN architecture in India specifically.

Last-mile reliability. ACT Fibernet, Hathway, JioFiber, Airtel Xstream: every Indian SMB last-mile carries 5-to-30-minute outage windows monthly. The architecture has to assume a flapping underlay. Dead-peer-detection set to 10 seconds + 3 retries means the head-end tears down idle SAs within 30 seconds of an underlay flap; setting it longer (60 seconds + 5 retries) reduces flap noise but increases the recovery time on a real failure.

Mobile-first WFH users. Indian SMB WFH users connect from Jio 4G / 5G, Airtel Wynk, Vi laptops, and BSNL FTTH in roughly equal proportions. Each carrier handles NAT-T slightly differently. Cisco AnyConnect Secure Client autodetects this in 99% of cases but the 1% that breaks (typically Jio 5G NSA in some Mumbai sectors) needs the head-end to enforce NAT-T explicitly.

Procurement cycle for AnyConnect licences. AnyConnect Plus / Apex licences are procured per-user, per-year. Indian distributor lead times for the licence keys are 5 to 12 working days. Plan the renewal three to four weeks ahead of expiry. ESS Bengaluru and Redington both handle the AnyConnect SKU and typically pre-stage licence keys for renewal customers.

Runbook handoff for VPN faults

The four lines I always write in the runbook after closing a VPN fault. One: the exact crypto syslog string + timestamp + IKE phase (1 or 2) of the failure. Two: the CLI sequence that diagnosed it (show crypto + debug crypto with conditions). Three: the exact config change that fixed it, copy-paste ready. Four: the rollback path, the pre-change config filename on bootflash plus the configure replace incantation.

The customer-cost framing is the line I always add. For a head-end VPN fault, the cost is not the head-end. It is the user-time across whatever percentage of the workforce is locked out. A 400-user organisation losing VPN for 90 minutes is 600 user-hours, which at a typical Indian SMB cost-loaded rate of Rs 850 / hour is Rs 5.1L of soft cost. Framing the cost that way is what stops the next on-call from accepting a workaround when a real fix is forty-five minutes away.

Related fixes

Related guides worth a look while you sort this one out:

• AnyConnect Secure Client IPsec phase 1 IKEv2 PARENT_SA negotiation failed: Fix
• ASR 1000 IPsec phase 1 IKEv2 PARENT_SA negotiation failed: Fix
• Catalyst 8300/8500 IPsec phase 1 IKEv2 PARENT_SA negotiation failed: Fix
• Catalyst 9200 IPSEC Phase 1 IKEV2 Parent SA Negotiation Failed: Fix
• Catalyst 9300 IPsec phase 1 IKEv2 PARENT_SA negotiation failed: Fix
• Catalyst 9400 IPsec phase 1 IKEv2 PARENT_SA negotiation failed: Fix