Troubleshooting IPsec: Phase 1 Up, Phase 2 Down, and Other Classics

Every error message in this article came off a real router. Not a textbook, not a vendor doc, not a forum post from 2011. We built a live IPsec lab in CML (two cat8000v edge routers, an ISP router, a PAT device in the middle), got the tunnel working, and then deliberately broke it five different ways so we could capture exactly what IOS XE says when each thing goes wrong. This is the troubleshooting article for the IPsec VPN cluster, and it is the one worth bookmarking, because the output below is what you will actually see on your screen at 2am.

IPsec troubleshooting has a reputation for being black magic. It is not. It is a two-phase protocol, and almost every fault you will ever hit lands cleanly on one side or the other of that line. The whole skill is knowing which side you are on before you start typing.

Part 1: A Method, Not a Guess

There is exactly one question that halves the problem, and it should be the first command you run every single time:

EDGE1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
198.51.100.2    203.0.113.1     QM_IDLE           1001 ACTIVE

That single state field tells you which half of the protocol to interrogate. Do not skip it and go straight to debugs, or you will drown in output you have no context for.

QM_IDLE confuses people because it looks like an idle state, as if something is waiting. It is not. QM_IDLE means Quick Mode is not currently running because it has already finished. It is the healthy steady state of an IKEv1 Phase 1 SA. If you see QM_IDLE and traffic still is not flowing, you have just eliminated half the protocol. That is a win.

The Second Question: Are Packets Actually Moving?

Once you know Phase 1 is up, the next command tells you whether Phase 2 built and whether packets are traversing it in both directions:

EDGE1#show crypto ipsec sa
   local  ident (addr/mask/prot/port): (10.20.10.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.30.10.0/255.255.255.0/0/0)
   current_peer 198.51.100.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
    #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9
    #send errors 0, #recv errors 0

Two counters matter more than everything else on that screen: #pkts encaps and #pkts decaps. Read them as a pair.

• encaps climbing, decaps stuck at 0. Your packets are being encrypted and sent. Nothing is coming back. The tunnel is not the problem, the return path is. Check the remote crypto ACL (is it a mirror image of yours?), check the return route on the far side, and check whether something between you is dropping ESP (IP protocol 50 has no port number, so a lot of middleboxes quietly eat it).
• both 0. Phase 2 never came up at all. No SA was ever installed, so no packet was ever encapsulated. Go find the Quick Mode rejection. Parts 2 and 3 of this article are entirely about reading those.
• both climbing. IPsec is working. Your problem is somewhere else: routing, an ACL on an inside interface, or the application itself.

Those two commands, in that order, resolve the vast majority of real-world IPsec cases before you type a single debug.

Part 2: Five Faults, Broken For Real

Each of the following was configured, broken, and captured on a live IOS XE 17.18.02 router. The output is verbatim.

Fault A: Pre-Shared Key Mismatch

The classic. Somebody typed the PSK from memory on one side. Here is what it looks like:

EDGE2#show crypto isakmp sa
dst             src             state          conn-id status
203.0.113.1     198.51.100.2    MM_KEY_EXCH       1014 ACTIVE

EDGE2#show logging
%CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 203.0.113.1 failed its sanity check or is malformed

Two symptoms, and the second one trips people up. The ISAKMP SA parks in MM_KEY_EXCH and never advances, and the log fills with complaints about a "malformed" message from the peer.

Nothing is actually malformed. In IKEv1 Main Mode, once the Diffie-Hellman exchange completes, both sides derive keying material from the DH shared secret plus the pre-shared key, and from message 5 onward the payloads are encrypted with a key that includes the PSK. If your PSK does not match the peer's, you decrypt their payload with the wrong key and get random bytes. The router tries to parse an ISAKMP payload header out of those bytes, finds nonsense, and reports the only thing it honestly can: this message failed its sanity check.

So IKMP_BAD_MESSAGE is not a corruption problem or an MTU problem. It is a decryption failure wearing a costume. When you see it alongside MM_KEY_EXCH, check the key on both sides, and check the address it is bound to:

crypto isakmp key PingLabz-L2L-PSK-01 address 198.51.100.2

Fault B: Transform Set Mismatch (error 256)

Phase 1 comes up perfectly. show crypto isakmp sa shows QM_IDLE and you feel good about yourself. Then no traffic passes and the logs say this:

EDGE1#show logging
ISAKMP-ERROR: (1015):IPSec policy invalidated proposal with error 256
ISAKMP-ERROR: (1015):phase 2 SA policy not acceptable! (local 203.0.113.1 remote 198.51.100.2)
ISAKMP-ERROR: (1015):deleting node 1723779313 error TRUE reason "QM rejected"

This is the textbook shape of a Phase 2 failure. Phase 1 succeeded, so the peers agree on who each other is. They just cannot agree on how to protect the data. One side is offering, say, esp-aes 256 esp-sha256-hmac and the other will only accept something else, so the proposal is invalidated and Quick Mode is torn down. QM rejected is IOS telling you plainly that Phase 2, not Phase 1, is what died. Compare the transform sets first:

crypto ipsec transform-set PLZ-TS-AES256 esp-aes 256 esp-sha256-hmac
 mode tunnel

Both sides need a matching encryption algorithm, a matching hash, and a matching mode. If you are running PFS (set pfs group14), the DH group has to match too, or Quick Mode will fail for the same reason with the same error code. Full crypto map syntax lives in the site-to-site IPsec crypto map walkthrough.

Fault C: Crypto ACL / Proxy-ID Mismatch (error 32)

This is the one that eats the most hours, and it has two completely different symptoms depending on which router you are logged into.

On the responder, you get one of the most useful debug blocks IOS produces:

EDGE2#show logging
Crypto mapdb : proxy_match
map_db_find_best did not find matching map
crypto_mapdb_find_map Fail to find matching policy ivrf 0, fvrf 0, flags 129,
  ike_profile NULL, local_proxy 10.30.10.0, remote_proxy 10.20.10.0,
  km_local 198.51.100.2, km_remote 203.0.113.1
ISAKMP-ERROR: (1018):IPSec policy invalidated proposal with error 32
ISAKMP-ERROR: (1018):phase 2 SA policy not acceptable! (local 198.51.100.2 remote 203.0.113.1)
ISAKMP-ERROR: (1018):deleting node 1949939457 error TRUE reason "QM rejected"

Read that literally, because it is telling you exactly what it wants. The peer proposed a pair of proxy identities (local_proxy 10.30.10.0, remote_proxy 10.20.10.0), IOS went looking through its crypto map database for a policy that permits that exact pair, and did not find matching map. Error 32 is the code for that. The debug even hands you the two subnets it could not match, which means you can go straight to the crypto ACL and compare.

Crypto ACLs must be exact mirror images. Not overlapping. Not supersets. Mirror images. If your side permits 10.20.10.0/24 -> 10.30.10.0/24, their side must permit 10.30.10.0/24 -> 10.20.10.0/24. IKEv1 negotiates the proxy IDs as part of Quick Mode, and if they do not line up, the SA does not build.

Now the second symptom, and this is the one that gets misdiagnosed. On the initiator whose ACL no longer matches, there is no debug output at all. No error. No ISAKMP SA. The tunnel does not fail, because the tunnel is never attempted.

A crypto map is just an outbound classifier bolted to a physical interface. A packet leaves the router, hits the crypto map, and the map asks one question: does this match the crypto ACL? If yes, encrypt it (building the tunnel first if necessary). If no, forward it normally, in the clear. That is the entire logic. So if you fat-finger the crypto ACL such that your interesting traffic no longer matches, the router does not consider that an error. It does exactly what you told it to do: it forwards those packets in the clear, straight at the internet, where the first upstream router with no route to your private subnet drops them silently.

From the operator's chair this looks exactly like a reachability problem. Pings fail, no SA exists, nothing in the logs, and people spend an afternoon checking routes and firewall rules. The tell is this: "the tunnel never even tries to come up" is a crypto ACL symptom, and you should treat it as one until proven otherwise. Our lab makes the point cleanly, because the ISP router in the middle genuinely cannot reach the private LANs:

ISP1#ping 10.30.10.1 repeat 3
...
Success rate is 0 percent (0/3)
ISP1#ping 192.168.99.100 repeat 3
...
Success rate is 0 percent (0/3)

Those subnets are reachable only through the tunnel. Send them in the clear and they die at the first hop. This entire class of fault, incidentally, is impossible with a route-based VTI, because a VTI has no crypto ACL to get wrong. Its proxy IDs are always any/any. That is not a stylistic preference, it is a real argument for VTIs, and we make it in full in crypto maps vs VTI.

Fault D: Wrong Peer Address

The simplest fault, and worth including precisely because its signature is so bare:

EDGE2#show crypto session
Session status: DOWN
Peer: 203.0.113.9 port 500

No ISAKMP SA to the configured peer. No Phase 1, no Phase 2, no errors, nothing. Just DOWN, forever. The router is dutifully firing IKE packets at 203.0.113.9, and 203.0.113.9 is not answering, because 203.0.113.9 is not a VPN endpoint. It might not even exist.

Its symptom (nothing happens) is easy to confuse with a routing problem or a firewall eating UDP 500. Before you go chasing the transit path, read the peer address in show crypto session and compare it digit by digit to what the far end actually terminates on, and confirm the ISAKMP key is bound to that same address.

Fault E: A Static Crypto Map Shadowing a Dynamic One (error 64)

We found this one by accident while moving a router behind PAT, and it is the subtlest fault in the set. It will bite you on any hub that carries both static site-to-site peers and a dynamic crypto map for remote sites.

The setup: EDGE2 moved behind a NAT device, so its source address changed. The hub, EDGE1, had a dynamic crypto map entry to catch it. But EDGE1 also still had a static crypto map entry whose ACL matched the same proxy pair, pointing at EDGE2's old public address. Here is what came out:

EDGE1#show logging
IPSEC(validate_proposal_request): proposal part #1,
    local_proxy= 192.168.99.0/255.255.255.0/256/0,
    remote_proxy= 10.30.10.0/255.255.255.0/256/0,
Crypto mapdb : proxy_match
IPSEC(ipsec_process_proposal): peer address 198.51.100.6 not found
ISAKMP-ERROR: (1011):IPSec policy invalidated proposal with error 64
ISAKMP-ERROR: (1011):phase 2 SA policy not acceptable! (local 203.0.113.1 remote 198.51.100.6)
ISAKMP-ERROR: (1011):deleting node 2945058899 error TRUE reason "QM rejected"

peer address 198.51.100.6 not found. That is EDGE2's new post-NAT address, and EDGE1 says it cannot find it. But EDGE1 had a dynamic crypto map entry that exists precisely to accept peers whose address it does not know in advance. Why did that not catch it?

Because of the order in which IOS evaluates the crypto map database. When a Quick Mode proposal arrives, IOS walks the crypto map entries and matches on the proxy identities first. The static entry's ACL matched the proposed proxy pair, so IOS selected that entry. It then checked the peer address in that entry, found it did not match the address the proposal actually came from, and rejected the proposal outright. It never fell through to the dynamic entry. A match on the proxy pair is a commitment, not a suggestion.

The practical rule: on a hub carrying both static peers and a dynamic catch-all, make sure no static entry's crypto ACL overlaps traffic that is supposed to land on the dynamic entry. If it does, the static entry wins the match and then fails the peer check, and you get error 64 instead of a working tunnel. Delete or narrow the stale static entry.

Part 3: The IPsec Error Code Map

Cisco's Quick Mode rejection messages carry a numeric error code, and that code is a precise diagnosis if you know how to read it. We could not find this documented anywhere in one place, so we derived it from our own lab captures. Every number below was produced by a fault we broke on purpose and captured on a live IOS XE router.

All three arrive with the same two companion lines, phase 2 SA policy not acceptable! and reason "QM rejected", which is why they all look identical if you skim. The number is the whole message. Read the number.

Part 4: The NAT Trap

There is a specific failure that fits none of the above and fools almost everyone the first time. Phase 1 is up. There is no Quick Mode error in the logs. And yet nothing passes:

EDGE2#ping 192.168.99.100 source Loopback10 repeat 5
.....
Success rate is 0 percent (0/5)

EDGE2#show crypto isakmp sa
dst             src             state          conn-id status
203.0.113.1     10.30.99.2      QM_IDLE           1008 ACTIVE

EDGE2#show crypto ipsec sa | include #pkts
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

QM_IDLE with zero encaps and zero decaps. The reason is beautiful in its simplicity. IKE runs over UDP 500, and UDP has port numbers, so a PAT device can happily translate it. Phase 1 sails through. But ESP is IP protocol 50. It is not TCP, it is not UDP, and it has no port field at all. A PAT device has nothing to build a translation entry on, so the encrypted data has no way home.

The fix is NAT Traversal, which wraps ESP inside UDP 4500 so PAT has a port to work with. When it is on, you can prove it from two places in show crypto session detail and show crypto ipsec sa:

EDGE2#show crypto session detail
Session status: UP-ACTIVE
Peer: 203.0.113.1 port 4500 fvrf: (none) ivrf: (none)
          Capabilities:N connid:1011 lifetime:00:57:40

EDGE2#show crypto ipsec sa
        transform: esp-256-aes esp-sha256-hmac ,
        in use settings ={Tunnel UDP-Encaps, }

Two things to look for. Capabilities:N is the N-for-NAT flag, meaning NAT was detected during IKE. And in use settings ={Tunnel UDP-Encaps, } is the proof that the SA is actually UDP-encapsulating. If your peer is behind PAT and you do not see both, that is your fault right there. The full mechanism, including the NAT device's translation table, is in IPsec NAT traversal (NAT-T).

Part 5: Two Gotchas Worth Knowing

The First Packet Always Drops

Watch this, from a genuinely working configuration:

EDGE1#ping 10.30.10.1 source Loopback10 repeat 5
.....
Success rate is 0 percent (0/5)

Zero percent. Now the very next attempt, with nothing changed:

EDGE1#ping 10.30.10.1 source Loopback10 repeat 10
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 10/21/48 ms

Crypto map tunnels are built on demand. The first interesting packet is what triggers IKE, and while IKE runs (Main Mode, then Quick Mode, with a Diffie-Hellman exchange in there) there is no SA to encrypt with, so those packets are consumed and dropped. All five of them, in this case.

Do not chase this. It is not a fault. If your first ping fails and your second succeeds, the tunnel is working correctly and you have just watched it negotiate. It is also why "it works if I ping twice" is such a common and confusing user report.

IOS XE Will Not Let You Edit an In-Use Crypto ACL

You have found the ACL problem, you are ready to fix it, and IOS stops you:

EDGE2(config)#ip access-list extended PLZ-CRYPTO-ACL
%ACL PLZ-CRYPTO-ACL can not be modified/deleted, as it is used in crypto-map PLZ-CMAP
%Please first remove the ACL from crypto map or remove the crypto map from the interface
% Cannot modify this ACL.

This is a real guardrail on IOS XE, and it surprises people who learned crypto maps on older code. You cannot modify a crypto ACL while it is bound to a crypto map that is applied to an interface. As the error says, you have to break the binding first: either remove the match address from the crypto map, or pull the crypto map off the interface, make the edit, and put it back.

Plan for that on a production box, because pulling the crypto map off the interface drops every tunnel it is carrying, not just the one you are fixing.

Part 6: The Command Toolkit

Seven commands. Know what each one is actually for, and you will never need to guess.

One workflow note that saves more time than any single command: after you change anything, clear crypto session, then generate traffic, then look. Half of all "my fix did not work" moments are actually "my fix worked but the old SA was still installed".

Key Takeaways

• Run show crypto isakmp sa first, every time. No SA means reachability, peer address, or IKE policy. Stuck in MM_KEY_EXCH means the pre-shared key. QM_IDLE means Phase 1 is fine and you should stop looking at it.
• #pkts encaps and #pkts decaps are the two counters that matter. Encaps climbing with decaps at zero is a return-path problem, not a tunnel problem. Both at zero means Phase 2 never built.
• A "malformed" IKE message means a bad pre-shared key. The peer decrypted your Main Mode payload with the wrong key and got garbage. Nothing is actually malformed.
• Learn the error codes: 32 is proxy identities, 64 is peer address not found, 256 is transform set. All three print the same QM rejected line, so the number is the entire diagnosis.
• Error 64 on a hub usually means a static crypto map entry shadowed the dynamic one. IOS matches on the proxy pair first, then checks the peer, and rejects outright rather than falling through.
• If the tunnel never even tries to come up, suspect the crypto ACL. Non-matching traffic is forwarded in the clear and dropped upstream, which looks exactly like a reachability problem and is not.
• Phase 1 up plus zero encaps behind a PAT device is NAT-T. Look for Capabilities:N and in use settings ={Tunnel UDP-Encaps, }.
• The first packet always drops. Crypto map tunnels build on demand. A failed first ping followed by a successful second one is the tunnel working, not failing.
• Clear the session after every change. Stale SAs make good fixes look like bad ones.

Almost everything in this article, other than the transform set and PSK faults, is a symptom of policy-based VPN mechanics: crypto ACLs, proxy IDs, and crypto map match order. A route-based VTI has none of that, which is why error 32 simply cannot happen on one. If you are building something new, read crypto maps vs VTI before you commit to a design, and start from the site-to-site crypto map guide if you have inherited one. The full set of IPsec deep-dives, from IKE negotiation to NAT traversal to tunnel protection, is indexed on the IPsec VPN pillar.