When configuring a site-to-site IPsec VPN on Cisco routers, it’s common to hit snags during tunnel establishment. Using debug crypto isakmp is one of the best tools to pinpoint where negotiations are failing. This post guides you through real debug outputs, highlights what to look for, and provides guidance to resolve common issues in IKE Phase 1 and Phase 2.
Endless Retransmissions in Phase 1
If you see debug logs that keep stating that ISAKMP is retransmitting:
ISAKMP:(0): retransmitting phase 1 MM_NO_STATE…
ISAKMP:(0): incrementing error counter on sa, attempt 2 of 5
Example debug output:
…and it continues repeating up to 5 times, the router is stuck in the Main Mode negotiation and not getting the expected response. Scroll further in the logs, and you may find something like:
ISAKMP:(0): Authentication method offered does not match policy!
ISAKMP:(0): No offers accepted!
Example debug output:
The fix: Double-check your authentication method. For example, if one side is using pre-share and the other rsa-sig, Phase 1 will never complete.
Mismatch in Encryption Algorithms
If you see:
ISAKMP:(0): Checking ISAKMP transform 1 against priority 1 policy
encryption AES-CBC
hash SHA
default group 5
ISAKMP:(0): No offers accepted!
This usually means there’s no shared encryption method between peers.
The fix: Ensure both peers have matching ISAKMP policy values for:
- Encryption (e.g., AES, 3DES)
- Hashing (e.g., SHA, MD5)
- DH group (e.g., group 1, 2, or 5)
- Lifetime (optional mismatch)
Hash Algorithm Mismatch
Another clear failure example:
ISAKMP:(0): Hash algorithm offered does not match policy!
ISAKMP:(0): No offers accepted!
Example debug output:
The fix: Align the hash setting in your ISAKMP policy (hash sha vs hash md5).
Diffie-Hellman Group Doesn’t Match
Another failure example:
ISAKMP:(0): Diffie-Hellman group offered does not match policy!
ISAKMP:(0): No offers accepted!
Example debug output:
The fix: Match the group setting in the ISAKMP policy (e.g., group 1, 2, or 5).
Missing or Incorrect Pre-shared Key
Another failure example:
ISAKMP:(0): No pre-shared key with 101.1.1.100!
or
Preshared authentication offered but does not match policy!
or
When you see the attributes are matching, but you see Main Mode packets retransmitting with incrementing errors on the SA.
Example debug outputs:
The fix: Re-enter the pre-shared key on both routers:
crypto isakmp key your_key_here address peer_ip
Phase 1 Completes, but Phase 2 Fails
You may see this message even after a successful key exchange:
ISAKMP:(0): IPSEC policy invalidated proposal with error 32
ISAKMP:(0): Phase 2 SA policy not acceptable
Example debug output:
The fix:
- Check your transform set for Phase 2 (must match on both sides):
crypto ipsec transform-set tset esp-aes esp-md5-hmac
mode tunnel - Check the ACL used in the crypto map. It defines “interesting traffic” and must be a mirror-image on both sides:
access-list 102 permit ip 192.168.101.0 0.0.0.255 192.168.102.0 0.0.0.255
When You Only See Logs on One Side
If only one router shows debug logs and the other is completely silent, verify:
- Routing is correct
- Interfaces are up
- Peer IP is correct
- Crypto map is applied to the interface
- ISAKMP is enabled on the interface:
crypto isakmp enable
Using debug crypto isakmp effectively comes down to understanding each line of the output. Most errors stem from mismatched policies (encryption, hash, group), wrong or missing pre-shared keys, and inconsistent ACLs or transform sets. Once you get familiar with interpreting these logs, resolving VPN issues becomes far more efficient.
Other Useful Troubleshooting Commands
- show crypto isakmp sa – Verify phase 1 information on the router, One can also see the ISAKMP states – if the state is QM_IDLE, this means Quick Mode Idle and that everything is fine and the tunnel is waiting for the next key change.
- show crypto isakmp sa detail – Gives a bit more information including the encryption type, hash, group, authentication type, and lifetime
- show crypto ipsec sa – Verify phase 2 information on the router, verify the interface of the crypto map, local address of the interface, proxy IDs from the local perspective (protocol and port – if 0, that means everything), current peer, packets encapsulated, MTU, PFS enabled/disabled, inbound/outbound SPI, SPI number which is in the ESP header, lifetime, transform set, status, tunnel mode, tunnel endpoint and source, whether GRE is being allowed, amount of packets being encrypted or decrypted, etc
- show crypto ipsec sa | inc ident|encry|decry – To see just what the local and remote endpoints are and the amount of packets that are being encrypted or decrypted
- show run | sec crypto isak – View the configuration for phase 1
- show run | sec crypto ipsec – View the configuration for phase 2
- show run | sec crypto – See all the crypto configuration
- show crypto map – Taken from the configuration. It won’t show whether the tunnel is up or not based on this output but one can see the configuration here. By default, the SA lifetime is either 4GB of data through the tunnel or 1 hour – whichever comes first. This output will also show if PFS is configured, what the transform-set is, what interface is configured with the crypto map, etc
- show crypto session – Shows the active IPSec SA, the flow that’s permitted, and how many SAs are active
- show crypto isakmp policy – View the existing IPSec policy and if there is a default policy
- show udp – See the ports that the router is listening on UDP-wise
- debug crypto isakmp – This is the most useful debug to troubleshoot IPSec setup. This is only for the negotiation of the tunnel. If the tunnel is already set up and flowing, there won’t be any output from this
- show debug – To view all debugs turned on
- clear crypto sa – to clear the tunnel
- clear crypto session – To clear the crypto session for troubleshooting purposes
