> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Troubleshoot Cisco ASA IPsec VPN Phase 1 and Phase 2 - URL: https://www.pinglabz.com/cisco-asa-troubleshoot-ipsec-phases/ - Published: 2026-05-10T01:11:33.000Z - Updated: 2026-08-24T09:42:48.000Z - Description: When an ASA IPsec tunnel will not come up, first identify whether Phase 1 or Phase 2 failed. This article shows the log messages and show output that point to each common cause, with real debugs from a deliberately broken tunnel on a live ASAv 9.23(1). - Author: Jaime - Tags: ASA, #Import 2026-08-01 19:54 When an IPsec VPN tunnel on a Cisco ASA does not come up, the failure is almost always in one of two phases: Phase 1 (the IKE\_SA where the two peers prove who they are and negotiate a control-plane key) or Phase 2 (the CHILD\_SA where they negotiate the data-plane keys and which interesting traffic to encrypt). Knowing which phase failed cuts the diagnostic surface area in half. This article walks through how to identify the failing phase, the specific log messages and show output that point at each common cause, and how to use real captures from a live ASAv 9.23(1) in the [PingLabz ASA reference](https://www.pinglabz.com/cisco-asa/) lab to verify a fix. The output below is the actual debug from a deliberately broken site-to-site tunnel between two ASAs. If you are configuring (rather than troubleshooting) IPsec, see [Cisco ASA Site-to-Site IPsec VPN Configuration](https://www.pinglabz.com/cisco-asa-site-to-site-vpn/) first; if you are troubleshooting AnyConnect specifically, see [Troubleshoot AnyConnect Login and Certificate Problems on ASA](https://www.pinglabz.com/cisco-asa-anyconnect-troubleshooting/) for the application-layer failures. ## What Phase 1 and Phase 2 Actually Negotiate Phase 1 (IKEv2) Protocol exchange IKE\_SA\_INIT then IKE\_AUTH Negotiates Encryption (AES-256), integrity (SHA256), DH group (14), PRF (SHA256), authentication method (PSK / cert / EAP), peer identities Result on success An IKE\_SA used to protect Phase 2 negotiation messages. Phase 2 (IKEv2) Protocol exchangeCREATE\_CHILD\_SA Negotiates ESP cipher suite (AES-256, SHA-256), traffic selectors (which subnets), encapsulation mode (tunnel) Result on success Two IPsec SAs (one inbound, one outbound) for actual data traffic. For IKEv1 the breakdown is similar but the exchanges are named differently (Main Mode + Quick Mode). On modern ASAs you should be using IKEv2 unless you have a reason not to; the troubleshooting concepts are the same. ## The Single Decision: Which Phase Failed? The fastest way to know is `show crypto ikev2 sa` on both peers (or `show crypto isakmp sa` for IKEv1): `There are no IKEv2 SAs` Means Phase 1 never completed (or was torn down). Look at Phase 1 troubleshooting below. IKE SA in `NEGO` or `BUILDING` state Means Phase 1 in progress, hung. Look at Phase 1 troubleshooting below. IKE SA `READY` but no Child SA / no `show crypto ipsec sa` entry Means Phase 1 succeeded, Phase 2 failed. Look at Phase 2 troubleshooting below. IKE SA `READY`, Child SA present, but `encaps == 0` or `decaps == 0` Means Tunnel is up but no traffic. Probably routing or NAT problem upstream. Look atRouting / NAT review. ## Phase 1 Failure Modes The four most common Phase 1 problems and how each looks: ### PSK Mismatch (or Wrong PSK Locally) From our lab, this is what an authentication failure looks like in the ASA buffered log when the local PSK is changed to a wrong value: ``` ASA-PERIM# show logging | include 750|751|752|IKE %ASA-5-752003: Tunnel Manager dispatching a KEY_ACQUIRE message to IKEv2. Map Tag = OUTSIDE-MAP. Map Sequence Number = 10. %ASA-5-750001: Local:203.0.113.2:500 Remote:203.0.113.6:500 Username:Unknown IKEv2 Received request to establish an IPsec tunnel; local traffic selector = Address Range: 10.10.0.1-10.10.0.1 Protocol: 0 Port Range: 0-65535; remote traffic selector = Address Range: 172.20.0.1-172.20.0.1 Protocol: 0 Port Range: 0-65535 %ASA-7-713906: IKE Receiver: Packet received on 203.0.113.2:500 from 203.0.113.6:500 %ASA-7-713906: IKE Receiver: Packet received on 203.0.113.2:500 from 203.0.113.6:500 %ASA-4-750003: Local:203.0.113.2:500 Remote:203.0.113.6:500 Username:203.0.113.6 IKEv2 Negotiation aborted due to ERROR: Failed to authenticate the IKE SA %ASA-4-752012: IKEv2 was unsuccessful at setting up a tunnel. Map Tag = OUTSIDE-MAP. Map Sequence Number = 10. %ASA-3-752015: Tunnel Manager has failed to establish an L2L SA. All configured IKE versions failed to establish the tunnel. Map Tag= OUTSIDE-MAP. Map Sequence Number = 10. %ASA-7-752002: Tunnel Manager Removed entry. Map Tag = OUTSIDE-MAP. Map Sequence Number = 10. ``` The tell is `%ASA-4-750003: ... Failed to authenticate the IKE SA`. That message means the local PSK does not produce the expected MAC over the IKE\_AUTH payload from the peer. Either the local PSK is wrong, the remote PSK is wrong, or both. `show running-config tunnel-group ipsec-attributes` reveals nothing useful (the actual key is masked with `*****`), so you have to compare the configured PSK against the documented value on both sides. Other Phase-1 messages that are real bug-finders: `IKE_SA NO_PROPOSAL_CHOSEN` Phase 1 cipher suite mismatch. The encryption/integrity/DH/PRF combination one side proposed has no matching policy on the other side. `IKE_SA INVALID_KE_PAYLOAD` DH group mismatch. One side's first DH attempt does not match what the other side expects, and they cannot agree to fall back. `IKE_SA AUTHENTICATION_FAILED` Cert chain validation failed. The cert presented by the peer is not signed by a CA the local side trusts. `IKE_SA timed out` UDP/500 packets are being dropped on the path. Check intermediate firewalls and the local OUTSIDE\_IN ACL. ### Enabling Phase 1 Debugs ``` ASA-PERIM# debug crypto ikev2 protocol 5 ASA-PERIM# debug crypto ikev2 platform 5 ``` Then trigger interesting traffic to drive a new negotiation. The output is verbose; pipe through `show logging | include ` after the test. **Disable debug as soon as you have your answer:** ``` ASA-PERIM# no debug crypto ikev2 protocol 5 ASA-PERIM# no debug crypto ikev2 platform 5 ``` Forgetting to turn debug off in production is the second most common cause of an ASA falling over (the first is logging buffered to flash). Always pair the enable + disable in the same change. ## Phase 2 Failure Modes Phase 2 failures show up after Phase 1 has succeeded. `show crypto ikev2 sa` shows a READY IKE SA but `show crypto ipsec sa` is empty (or shows the ESP SAs immediately disappearing). ### Proposal Mismatch Both sides have to agree on the ESP cipher suite. From a working tunnel: ``` ASA-PERIM# show crypto ipsec sa interface: outside Crypto map tag: OUTSIDE-MAP, seq num: 10, local addr: 203.0.113.2 access-list S2S-PARTNER-CRYPTO extended permit ip 10.10.0.0 255.255.0.0 172.20.0.0 255.255.255.0 Protected vrf (ivrf): local ident (addr/mask/prot/port): (10.10.0.0/255.255.0.0/0/0) remote ident (addr/mask/prot/port): (172.20.0.0/255.255.255.0/0/0) current_peer: 203.0.113.6 #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 ... local crypto endpt.: 203.0.113.2/500, remote crypto endpt.: 203.0.113.6/500 path mtu 1500, ipsec overhead 78(44), media mtu 1500 current outbound spi: DDAE2213 current inbound spi : A0BFFEC9 inbound esp sas: spi: 0xA0BFFEC9 (2696937161) SA State: active transform: esp-aes-256 esp-sha-256-hmac no compression in use settings ={L2L, Tunnel, IKEv2, } ``` If the proposal does not match, the ESP SAs never get installed. `show crypto ipsec stats` on a freshly-failed Phase 2 attempt typically shows zero successful Phase 2 negotiations and `Inbound SA delete requests` climbing. `%ASA-5-713905: Phase 2 mismatch` appears in the buffered log. ### Traffic Selector Mismatch The two sides have to agree on which traffic the tunnel protects. The local side's `access-list ... permit ip A B` must mirror the remote side's `access-list ... permit ip B A`. If they don't, you see `TS_UNACCEPTABLE` in the IKEv2 logs and Phase 2 fails immediately even though Phase 1 was clean. Verify with `show crypto ikev2 sa detail`: ``` ASA-PERIM# show crypto ikev2 sa detail ... Child sa: local selector 10.10.0.0/0 - 10.10.255.255/65535 remote selector 172.20.0.0/0 - 172.20.0.255/65535 ESP spi in/out: 0xa0bffec9/0xddae2213 AH spi in/out: 0x0/0x0 CPI in/out: 0x0/0x0 Encr: AES-CBC, keysize: 256, esp_hmac: SHA256 ah_hmac: None, comp: IPCOMP_NONE, mode tunnel ``` The local + remote selector pair has to match what the remote ASA shows on its side, just reversed. If your side shows `local 10.10.0.0/16` but the partner side has `remote 10.10.10.0/24`, that is the problem. ### Lifetime Mismatch The two sides do not have to agree on identical lifetimes; the negotiation picks the shorter of the two. But a vastly mismatched setting (one side at 1 hour, the other at 24 hours) leads to frequent rekey churn that confuses third-party peers. Match lifetimes when crossing vendor boundaries. ## Walking a Tunnel Up: From Zero to Pings The full sequence for bringing a fresh site-to-site IPsec tunnel up: 1. **Verify routing**: each ASA can ping the other's outside interface. `ping outside ` succeeds. 2. **Match cipher suites**: `show running-config crypto ikev2` on both sides has at least one common policy. Same for `show running-config crypto ipsec`. 3. **Match PSK or cert auth**: PSK identical on both sides; or each side trusts the other's CA. 4. **Crypto map applied to interface**: `crypto map OUTSIDE-MAP interface outside`. 5. **Trigger interesting traffic**: any packet matching the crypto-map ACL fires the negotiation. Use `packet-tracer` if you do not want to wait for real traffic. Real traffic is more reliable because packet-tracer skips some of the lazy-state-init paths. 6. **Phase 1 check**: `show crypto ikev2 sa` shows READY. If not, see Phase 1 section. 7. **Phase 2 check**: `show crypto ipsec sa` shows the SA pair with non-zero `encaps` after a few packets. If `encaps` climbs but `decaps` is zero, something on the remote side or the path is dropping ESP return traffic. ## High-Value Verification Commands `show crypto ikev2 sa` Phase 1 SAs and their state. Empty = Phase 1 never came up. `show crypto ikev2 sa detail` Adds local/remote ID, selectors, mess IDs, NAT-T detection. `show crypto ipsec sa` Phase 2 SAs. Includes `#pkts encaps` / `decaps` counters. `show crypto ipsec stats` Tunnel stats by SA. Encap/decap counters, drop counters. `show crypto isakmp stats` Both IKEv1 and IKEv2 global counters: failed negotiations, auth failures, decrypt failures, retransmits. `show vpn-sessiondb l2l` Active site-to-site tunnels with bytes in/out, encryption, hashing. `show running-config crypto map` The crypto map definitions including peer, ACL match, and cipher suite reference. `show running-config tunnel-group ` The peer's PSK / cert config and any per-tunnel parameters. ## Key Takeaways IPsec VPN troubleshooting on the Cisco ASA reduces to one question first: did Phase 1 complete? If `show crypto ikev2 sa` is empty or shows a stuck NEGO state, fix Phase 1: PSK, cipher suite, DH group, peer ID, or path UDP/500 connectivity. If the IKE SA is READY but `show crypto ipsec sa` is empty or has zero counters, fix Phase 2: ESP proposal, traffic selectors, or routing on the protected subnets. The single most useful debug for both is `debug crypto ikev2 protocol 5`, but always pair it with the corresponding `no debug` when you finish. For the full Cisco ASA reference, including site-to-site IPsec, NAT, ACLs, failover, and the troubleshooting tools, see the [Cisco ASA pillar](https://www.pinglabz.com/cisco-asa/). For NAT-related VPN failures (the second-most common cause of "tunnel is up but no traffic"), see [Cisco ASA Identity NAT / NAT Exemption for VPNs](https://www.pinglabz.com/cisco-asa-identity-nat-vpn/); for ACL-related failures on the path to and from the tunnel, [Cisco ASA ACL Troubleshooting with packet-tracer](https://www.pinglabz.com/cisco-asa-acl-troubleshooting/) covers the ACL-phase drops you will see in `packet-tracer` output.