Courseiva
DebugPrivileged EXEC

debug crypto ipsec

Use this command to enable real-time debugging of IPsec security association (SA) negotiations and packet processing, typically for troubleshooting VPN connectivity issues.

Definition: debug crypto ipsec is a Cisco IOS privileged exec command. Use this command to enable real-time debugging of IPsec security association (SA) negotiations and packet processing, typically for troubleshooting VPN connectivity issues.

Overview

The `debug crypto ipsec` command is a powerful diagnostic tool used in Cisco IOS to monitor and troubleshoot IPsec VPN operations in real time. IPsec (Internet Protocol Security) is a suite of protocols that provides confidentiality, integrity, and authentication for IP packets, commonly used to secure site-to-site and remote-access VPNs. This command enables detailed logging of IPsec security association (SA) negotiations, including Internet Key Exchange (IKE) phase 2 quick mode exchanges, and the encryption/decryption of individual packets.

It is invaluable when VPN tunnels fail to establish, traffic is not encrypted as expected, or performance issues arise due to IPsec processing. Unlike `show crypto ipsec sa` which displays static SA information, `debug crypto ipsec` provides dynamic, real-time insight into the negotiation process and packet-level operations, allowing engineers to pinpoint where failures occur—such as mismatched transform sets, incorrect peer addresses, or anti-replay window errors. This command is typically used after initial configuration or when troubleshooting connectivity issues, often in conjunction with `debug crypto isakmp` for IKE phase 1 debugging.

It is important to note that debug commands can generate a high volume of output, especially on busy routers, which can impact CPU performance and cause console buffer overflows. Therefore, it is recommended to use `terminal monitor` to view output on a remote session and to disable debugging with `undebug all` when finished. The command requires privileged EXEC mode (enable) and does not affect the running configuration—it only enables logging.

Output is sent to the console or logging buffer depending on the logging configuration. For production networks, it is advisable to use conditional debugging (e.g., `debug crypto ipsec peer <ip>`) to limit output to specific peers. Understanding the output of this command is essential for CCNA and CCNP candidates as it demonstrates deep knowledge of IPsec operation and troubleshooting methodology.

Syntax·Privileged EXEC
debug crypto ipsec

When to Use This Command

  • Troubleshooting why an IPsec tunnel fails to establish between two routers.
  • Verifying the correct IPsec SA parameters (encryption, authentication, etc.) during tunnel setup.
  • Diagnosing packet drops due to mismatched IPsec policies or expired SAs.
  • Monitoring the progress of IKE phase 2 quick mode exchanges.

Parameters

ParameterSyntaxDescription
peerpeer <ip-address>Limits debugging to IPsec events involving a specific peer IP address. This is useful to reduce output on busy routers. The IP address must be the peer's public interface IP. Common mistake: using the wrong IP address (e.g., the tunnel endpoint instead of the peer's external interface).
conditioncondition <condition-name>Applies a pre-defined debug condition to filter output. Conditions are set using the `debug condition` command. This allows more granular control, such as filtering by interface or access-list. Common mistake: forgetting to define the condition before using it.
packetpacketEnables debugging of IPsec packet processing, including encryption and decryption. This generates a high volume of output and should be used with caution. It is useful for verifying that traffic is being encrypted/decrypted correctly. Common mistake: enabling this on a production router without filtering, causing CPU spikes.
detaildetailProvides more detailed information about IPsec SA negotiations, including proposal details and keying material. This is helpful when standard output does not reveal the cause of a failure. Common mistake: assuming detail is always needed; it can overwhelm with unnecessary information.

Command Examples

Basic IPsec debug output during tunnel establishment

debug crypto ipsec
00:11:22: %CRYPTO-4-RECV_PKT: IPSEC receive packet from 192.168.1.1 to 10.0.0.1 prot=50
00:11:22: IPSEC(sa_request): , (key eng. msg.) src=192.168.1.1, dest=10.0.0.1, src_proxy=192.168.1.0/255.255.255.0/0/0, dest_proxy=10.0.0.0/255.255.255.0/0/0, 
00:11:22:   inbound SA to 10.0.0.1 (proxy 10.0.0.0 to 192.168.1.0)
00:11:22:   has spi 0x12345678 and conn_id 2000, keysize 128, flags 0x200C
00:11:22: IPSEC(validate_proposal_request): proposal part #1,
00:11:22:   (transform esp-aes 128 esp-sha-hmac,)
00:11:22:   (life expiry: 3600 seconds and 4608000 kilobytes)
00:11:22: IPSEC(process_sa_request): SA request accepted
00:11:22: IPSEC(create_sa): sa created,
00:11:22:   (sa) sa_dest=10.0.0.1, sa_prot=50, sa_spi=0x12345678, sa_trans=esp-aes 128 esp-sha-hmac, sa_conn_id=2000, sa_lifetime=3600/4608000

Line 1: Indicates receipt of an IPsec packet (protocol 50 = ESP) from 192.168.1.1 to 10.0.0.1. Line 2: SA request message showing source/destination proxies (subnets). Line 3: Inbound SA details with SPI (Security Parameter Index) and connection ID. Line 4-5: Proposal validation showing transform set (AES 128, SHA-HMAC) and lifetime. Line 6: SA request accepted. Line 7-8: SA created with all parameters.

Debug output showing IPsec packet drop due to anti-replay

debug crypto ipsec
00:12:34: IPSEC(anti_replay): packet dropped, seq# 12345, expected seq# 12346
00:12:34: %CRYPTO-4-PKT_REPLAY: IPsec anti-replay check failed, dropped packet from 192.168.1.1 to 10.0.0.1

Line 1: Anti-replay check failed; received sequence number 12345 but expected 12346, indicating a possible replay attack or out-of-order delivery. Line 2: Syslog message summarizing the drop.

Understanding the Output

The output of 'debug crypto ipsec' provides real-time information about IPsec SA creation, deletion, and packet processing. Key fields include: 'src' and 'dest' (source/destination IPs of the tunnel endpoints), 'src_proxy' and 'dest_proxy' (subnets protected by the tunnel), 'spi' (Security Parameter Index, a unique identifier for the SA), 'conn_id' (internal connection ID), 'keysize' (encryption key length), 'transform' (encryption and authentication algorithms), 'life expiry' (SA lifetime in seconds/kilobytes). Good values: SA creation messages with matching transforms and proxies.

Bad values: 'SA request rejected', 'no matching proposal', 'anti-replay dropped', or 'packet dropped' messages. Watch for mismatched transform sets, incorrect proxy IDs, or expired SAs.

Configuration Scenarios

Troubleshooting IPsec VPN Tunnel Failure Between Two Branch Routers

Two branch routers (R1 and R2) are configured for a site-to-site IPsec VPN, but the tunnel does not come up. The goal is to use `debug crypto ipsec` to identify why the IPsec SA negotiation fails.

Topology

R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2 R1 Loopback0: 192.168.1.1/24 R2 Loopback0: 192.168.2.1/24

Steps

  1. 1.Step 1: On R1, enter privileged EXEC mode: enable
  2. 2.Step 2: Enable IPsec debugging for the specific peer: debug crypto ipsec peer 10.0.12.2
  3. 3.Step 3: Initiate traffic from R1 to R2's loopback to trigger the VPN: ping 192.168.2.1 source 192.168.1.1
  4. 4.Step 4: Observe the debug output. Look for messages like 'IPsec SA negotiation failed' or 'no matching crypto map'. Identify the cause (e.g., mismatched transform set).
  5. 5.Step 5: After troubleshooting, disable debugging: undebug all
Configuration
! On R1:
interface GigabitEthernet0/0
 ip address 10.0.12.1 255.255.255.252
 crypto map MYMAP
!
crypto isakmp policy 10
 encryption aes 256
 authentication pre-share
 group 14
!
crypto isakmp key cisco123 address 10.0.12.2
!
crypto ipsec transform-set AES256-SHA esp-aes 256 esp-sha-hmac
 mode tunnel
!
crypto map MYMAP 10 ipsec-isakmp
 set peer 10.0.12.2
 set transform-set AES256-SHA
 match address 100
!
access-list 100 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Verify: After fixing the configuration, use `show crypto ipsec sa` to verify that the SA is active. Expected output shows 'pkts encaps: 5, pkts decaps: 5' and 'local crypto endpt.: 10.0.12.1, remote crypto endpt.: 10.0.12.2'.

Watch out: A common mistake is forgetting to apply the crypto map to the outgoing interface. Without `crypto map MYMAP` under the interface, IPsec will not process traffic.

Verifying IPsec Packet Encryption for a Specific Traffic Flow

After a VPN tunnel is established, an administrator wants to confirm that specific traffic (e.g., HTTP from a particular subnet) is being encrypted. The `debug crypto ipsec packet` command can show whether packets are being encrypted or dropped.

Topology

R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2 R1 Gi0/1: 172.16.1.1/24 (internal) R2 Gi0/1: 172.16.2.1/24 (internal)

Steps

  1. 1.Step 1: On R1, enable packet debugging with a condition to limit output: debug crypto ipsec packet condition peer 10.0.12.2
  2. 2.Step 2: Generate traffic from the internal network: ping 172.16.2.1 source 172.16.1.1
  3. 3.Step 3: Observe debug output. Look for 'IPsec: encrypt' or 'IPsec: decrypt' messages. If packets are not encrypted, check the crypto map match address.
  4. 4.Step 4: Disable debugging: undebug all
Configuration
! On R1:
interface GigabitEthernet0/0
 ip address 10.0.12.1 255.255.255.252
 crypto map MYMAP
!
interface GigabitEthernet0/1
 ip address 172.16.1.1 255.255.255.0
!
crypto isakmp policy 10
 encryption aes 256
 authentication pre-share
 group 14
!
crypto isakmp key cisco123 address 10.0.12.2
!
crypto ipsec transform-set AES256-SHA esp-aes 256 esp-sha-hmac
 mode tunnel
!
crypto map MYMAP 10 ipsec-isakmp
 set peer 10.0.12.2
 set transform-set AES256-SHA
 match address 100
!
access-list 100 permit ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255

Verify: Use `show crypto ipsec sa peer 10.0.12.2` to see packet counters. Expected: 'encaps: 5, decaps: 5' indicating successful encryption/decryption.

Watch out: Enabling `debug crypto ipsec packet` without a condition can flood the console with output, especially if there is background traffic. Always use the `peer` or `condition` keyword to filter.

Troubleshooting with This Command

When troubleshooting IPsec VPN issues, `debug crypto ipsec` is a primary tool for diagnosing phase 2 (IPsec SA) problems. Healthy output during a successful negotiation shows messages like 'IPsec: validate proposal', 'IPsec: created inbound SA', and 'IPsec: created outbound SA' with details of the SPI, transform set, and lifetime. Problem indicators include 'IPsec: SA negotiation failed', 'no matching crypto map', 'transform set mismatch', or 'peer address mismatch'.

Key fields to focus on are the SPI values (to correlate with `show crypto ipsec sa`), the transform set proposed vs. accepted, and the identity (proxy) information. Common symptoms: if you see 'IPsec: no matching crypto map', it means the traffic does not match any access-list in the crypto map; check the ACL and ensure it is applied correctly. If you see 'transform set mismatch', compare the transform sets on both peers.

If you see 'peer address mismatch', verify the peer IP in the crypto map. A step-by-step diagnostic flow: 1) Ensure IKE phase 1 is complete (`show crypto isakmp sa`). 2) Enable `debug crypto ipsec` with the peer filter. 3) Generate interesting traffic (e.g., ping across the tunnel). 4) Observe the output for failure messages. 5) If negotiation fails, check the crypto map configuration, ACL, and transform sets. 6) If negotiation succeeds but traffic is not encrypted, use `debug crypto ipsec packet` to see if packets are being processed. Correlate with `show crypto ipsec sa` to verify SA counters increment.

Also, use `show crypto map` to verify the crypto map is applied to the correct interface. For complex issues, combine with `debug crypto isakmp` for phase 1 details. Remember that debug output is CPU-intensive; use conditional debugging and disable when done.

In production, consider using `logging buffered` to capture output without overwhelming the console.

CCNA Exam Tips

1.

CCNA exam tip: Remember that 'debug crypto ipsec' is used for IPsec SA-level debugging, while 'debug crypto isakmp' is for IKE phase 1. The exam may ask which debug to use for phase 2 issues.

2.

CCNA exam tip: Anti-replay drops can occur due to packet reordering; the exam might test that the default window is 64 packets.

3.

CCNA exam tip: The SPI value is a key identifier for an SA; exam questions may ask what SPI represents.

4.

CCNA exam tip: Always use 'undebug all' or 'no debug crypto ipsec' after troubleshooting to avoid CPU overload.

Common Mistakes

Mistake 1: Leaving debug enabled on a production router, causing high CPU usage and potential crashes.

Mistake 2: Confusing 'debug crypto ipsec' with 'debug crypto isakmp' — using the wrong debug for the phase being troubleshot.

Mistake 3: Not filtering debug output with 'debug crypto ipsec 192.168.1.1' to limit noise, leading to overwhelming logs.

debug crypto ipsec vs debug crypto isakmp

Both 'debug crypto ipsec' and 'debug crypto isakmp' are used for troubleshooting IPsec VPNs, but they target different phases of the IPsec process, which often causes confusion. 'debug crypto ipsec' focuses on IPsec security associations (Phase 2), while 'debug crypto isakmp' monitors ISAKMP/IKE Phase 1 negotiations.

Aspectdebug crypto ipsecdebug crypto isakmp
ScopeIPsec Phase 2 (SA, encryption/decryption)IKE Phase 1 (ISAKMP SA, authentication, key exchange)
FunctionDebugs IPsec packet processing and SA establishmentDebugs ISAKMP exchange messages and policy negotiation
ProtocolESP and AHISAKMP (UDP 500/4500)
Typical OutputShows 'ipsec ipsec_sa_create', 'ipsec_add_sa', packet drop reasonsShows 'ISAKMP (0): processing SA payload', 'START_AGGRESSIVE'
RiskLower volume, but can impact CPU with high trafficMay generate large output during negotiation, affecting terminal

Use debug crypto ipsec when troubleshooting IPsec SA negotiation failures, packet encryption/decryption errors, or connectivity after Phase 1 completes.

Use debug crypto isakmp when troubleshooting IKE Phase 1 failures, authentication issues, or mismatched pre-shared keys and policies.

Platform Notes

In IOS-XE (e.g., 16.x), the `debug crypto ipsec` command syntax and output are largely the same as classic IOS, but the output may include additional details like 'Crypto Engine' information. The command is available in IOS-XE without changes. In NX-OS (Cisco Nexus switches), the equivalent command is `debug crypto ipsec` as well, but the output format differs significantly; NX-OS uses a more structured output with timestamps and different verbosity levels.

For example, `debug crypto ipsec level 7` provides detailed debugging. On Cisco ASA firewalls, the equivalent is `debug crypto ipsec` (or `debug crypto ipsec 255` for maximum detail), but the ASA uses a different codebase and the output is tailored to ASA-specific features like site-to-site and remote-access VPN. In IOS-XR (Cisco routers running IOS-XR), the command is not directly available; instead, use `debug crypto ipsec` under the XR debug framework, but the syntax is `debug crypto ipsec [level]` and the output is more concise.

For IOS versions 12.x, 15.x, and 16.x, the command behavior is consistent, but 12.x may lack some filtering options like `peer`. Always check the specific platform documentation for exact syntax. On all platforms, remember to disable debugging with `undebug all` or `no debug all` to prevent performance degradation.

Related Commands

debug crypto isakmp

Enables debugging of ISAKMP (Internet Security Association and Key Management Protocol) packets to troubleshoot IKE phase 1 issues in IPsec VPNs.

show crypto ipsec sa

Displays the current state and statistics of IPsec security associations (SAs) to verify VPN tunnel establishment and monitor encrypted traffic.

show crypto map

Displays the configured crypto map entries, including their match criteria, peer addresses, and transform sets, used to verify IPsec VPN policy configuration.

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions