Troubleshoot Cisco ASA IPsec VPN Phase 1 and Phase 2

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 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 first; if you are troubleshooting AnyConnect specifically, see Troubleshoot AnyConnect Login and Certificate Problems on ASA for the application-layer failures.

What Phase 1 and Phase 2 Actually Negotiate

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):

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 <peer> 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:

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 <peer-IP> 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 <peer> 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

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. 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; for ACL-related failures on the path to and from the tunnel, Cisco ASA ACL Troubleshooting with packet-tracer covers the ACL-phase drops you will see in packet-tracer output.