cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
64859
Views
51
Helpful
7
Replies

"rec'd IPSEC packet has invalid spi" errors in VPN connections

Stephan90
Level 1
Level 1

I have a simple network of a few Cisco routers. Once in a while I'm seeing a "%CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi" error, even though my VPN connection works well.

What can cause these messages?

1 Accepted Solution

Accepted Solutions

Andrew_Larson
Level 1
Level 1

The meaning of the message is that one side of the IPSEC tunnel received a packet with an invalid SPI. The SPI (Security Parameter Index) is used to identify the SA (Security Association) of the packet - which contains the information needed to handle the encrypted traffic. Usually, this message indicates that the SAs of the the peers are out of sync, which happens sometimes when the SA ages out and is reestablished.

To manually force the SAs to sync, issue the "clear crypto isakmp" and "clear crypto sa" commands. In addition, you can add the command "crypto isakmp invalid-spi-recovery" to the global configuration of the routes. This will make the routers notify one another when receiving this error - which should start the syncing process automatically.

View solution in original post

7 Replies 7

Hi,

Sometimes IPsec SAs can become out of sync between the peer devices. This link may help provide some back and hopefully a resolution.

 

HTH

Andrew_Larson
Level 1
Level 1

The meaning of the message is that one side of the IPSEC tunnel received a packet with an invalid SPI. The SPI (Security Parameter Index) is used to identify the SA (Security Association) of the packet - which contains the information needed to handle the encrypted traffic. Usually, this message indicates that the SAs of the the peers are out of sync, which happens sometimes when the SA ages out and is reestablished.

To manually force the SAs to sync, issue the "clear crypto isakmp" and "clear crypto sa" commands. In addition, you can add the command "crypto isakmp invalid-spi-recovery" to the global configuration of the routes. This will make the routers notify one another when receiving this error - which should start the syncing process automatically.

Great answer. Thank you!

Hi Andrew,

does this have to be enabled both ends. Also if i enable it will have any affect on live VPN's 

Logged in just to upvote this response. Solved my issue right away

I HAD THIS SAME PROBLEM AFTER THE TUNNEL´S PHYSICAL INTERFACE WAS DOWN, HERE WHAT I SAW:

H1#SH DMVPN
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:1,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
2 192.168.0.12 172.21.1.12 UP 00:00:44 D
0 UNKNOWN 172.21.1.13 NHRP never IX

*Aug 13 18:49:00.775: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=192.168.0.11, prot=50, spi=0x2ABA425E(716849758), srcaddr=192.168.0.14, input interface=Ethernet0/0
i issued the command crypto isakmp invalid-spi-recovery in both hub and spoke router but that doesnt raised the tunnel.

the solution that was succeful was clearing the crypto sessions in spokes routers. after this i saw:

*Aug 13 18:49:58.608: %CRYPTO-4-IKMP_NO_SA: IKE message from 192.168.0.14 has no SA and is not an initialization offer
H1#sh dmvpn
==========================================================================

Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:3,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 192.168.0.12 172.21.1.12 UP 00:03:30 D
1 192.168.0.13 172.21.1.13 UP 00:01:28 D
1 192.168.0.14 172.21.1.14 UP 00:00:03 D

 

but is there any solution for coming up the tunnels whithout clearing crypto sessions, that´s why i have a flapping fiber connection in the hub, and it is not going to be troubleshooting yet. any suggestion?

jasonhawaii1
Level 1
Level 1

We recently had this issue where customer reported that they had intermittently VPN interruptions. The mismatch lifetime parameters will cause intermittent issue because it will tear down the tunnel when the lifetime time is up, then re-negotiate, but out of sync. They must match and re-negotiate at the same time and sync'ed up to avoid disruption and error should go away.

Apr 18 2025 16:53:54.102 EDT: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=x.x.x.x, prot=50, spi=0xDF1C2212(3743162898), srcaddr=y.y.y.y, input interface=Port-channel2.xxx

x.x.x.x = local side
y.y.y.y = remote side.

This means Phase1 or Phase 2 lifetime parameter mismatch.

Cisco default Phase 1 lifetime is: 86400
Cisco default Phase 2 lifetime is: 3600

Command to check Phase 1 lifetime:

sh crypto isakmp default policy or
sh crypto isakmp policy
Default IKE policy
Default protection suite of priority 65507
encryption algorithm: AES - Advanced Encryption Standard (128 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #5 (1536 bit)
lifetime: 86400 seconds, no volume limit

Command to check Phase 2 lifetime:
show crypto ipsec security-association lifetime
Security association lifetime: 4608000 kilobytes/3600 seconds