Duo IPsec phase 1 ISAKMP MM_NO_STATE pre-shared key: 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. Two winters ago in Electronic City Phase 1 I deployed a four-node Catalyst 9300 StackWise-Virtual pair to a fintech who had been running on a tired pair of 3850s. The TCO model the sales engineer brought said the StackWise upgrade would pay back in twenty-six months on power, MTBF, and SmartNet alone. It actually paid back in nineteen months because the 3850s were burning a Rs 14,000 a month opex on emergency-tier TAC support that the new boxes wiped out. 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 isakmp mm no state pre shared key": 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 platform hardware fed switch active fwd-asic resource tcam utilization`, 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

• %OSPF-5-ADJCHG: Process 100, Nbr 10.10.10.1 on GigabitEthernet1/0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
• %PLATFORM-1-SOFT_PARITY: A soft parity error was detected at FED L3-FIB region, recovery action triggered
• %WNCD-3-WCM_ACL_RULE_DOWNLOAD_FAILED: Failed to download ACL rules to data plane
• %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/24, changed state to up
• %CLIENT_ORCH_LOG-5-CLIENT_DELETED: Client 7c:8a:e1:22:33:44 deleted reason: IP Learn Timeout

The root-cause flow for "ipsec phase 1 isakmp mm no state pre shared key"

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 platform hardware fed switch active fwd-asic resource tcam utilization`
• `show logging | include FED|PLATFORM|WNCD`
• `show ip ospf neighbor detail`
• `show license usage`
• `show bgp ipv4 unicast neighbors 203.0.113.1 advertised-routes`
• `show ip ospf database router`
• `show ip eigrp neighbors detail`
• `show license summary`

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

• Cisco Bug Search Tool (free with a CCO account; the only canonical source for caveat IDs).
• PuTTY 0.78 (free; preferred for ad-hoc console work).
• Fluke MicroScanner2 cable tester (around Rs 38,000 / about USD 455) for the L1 questions the CLI cannot answer.
• 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).

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

Last quarter I was rebuilding a 38-site SD-Access fabric and one branch in Mysuru would not bring its fabric-edge node online. The other thirty-seven came up clean. The Mysuru node turned out to be on IOS XE 17.6.3 while the rest were on 17.9.4a. The 17.6 caveat CSCvy53024 was open and biting it. One staged upgrade to 17.9.4a (with a fallback image on bootflash) cleared the fabric-edge join inside an hour. 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 ISAKMP MM_NO_STATE pre-shared key: Fix
• ASR 1000 IPsec phase 1 ISAKMP MM_NO_STATE pre-shared key: Fix
• Catalyst 8300/8500 IPsec phase 1 ISAKMP MM_NO_STATE pre-shared key: Fix
• Catalyst 9200 IPSEC Phase 1 Isakmp MM No State Pre Shared Key: Fix
• Catalyst 9300 IPsec phase 1 ISAKMP MM_NO_STATE pre-shared key: Fix
• Catalyst 9400 IPsec phase 1 ISAKMP MM_NO_STATE pre-shared key: Fix