IPSEC packet has invalid spi

cciesec2011 · ‎07-26-2010

I have a very simple LAN-2-LAN between two cisco routers running IOS version 12.4(15)T8 as follows:

RouterA:

crypto isakmp key test123 address 4.2.97.15 no-xauth

crypto isakmp policy 1
encr aes 256
hash sha
authentication pre-share
group 5
lifetime 86400

no crypto ipsec nat-transparency udp-encapsulation
crypto ipsec transform-set tset esp-aes 256 esp-sha-hmac

crypto map vpn 10 ipsec-isakmp
set peer 4.2.97.15
set security-association lifetime seconds 3600
set transform-set tset
set pfs group5
match address vpn

interface FastEthernet0/0
ip address 207.15.205.15 255.255.255.0
speed 100
full-duplex
crypto map vpn

ip access-list extended vpn
permit ip 129.174.15.0 0.0.0.255 129.174.16.0 0.0.0.255

RouterB:
crypto isakmp key test123 address 207.15.205.15 no-xauth

crypto isakmp policy 1
encr aes 256
hash sha
authentication pre-share
group 5
lifetime 86400

no crypto ipsec nat-transparency udp-encapsulation
crypto ipsec transform-set tset esp-aes 256 esp-sha-hmac

crypto map vpn 10 ipsec-isakmp
set peer 207.15.205.15
set security-association lifetime seconds 3600
set transform-set tset
set pfs group5
match address vpn

interface FastEthernet0/0
ip address 4.2.97.15 255.255.255.0
speed 100
full-duplex
crypto map vpn

ip access-list extended vpn
permit ip 129.174.16.0 0.0.0.255 129.174.15.0 0.0.0.255

Every now and then I am seeing this message in the log file:

Jul 27 00:25:20.603: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd
IPSEC packet has invalid spi for destaddr=207.15.205.15, prot=50,
spi=0x681E0955(1746798933), srcaddr=4.2.97.15.

Why am I seeing this message? The VPN peer between two router is very stable without any errors.

I've asked several ccie consultant folks and none of them is able to provide me with a satifactory answer regarding this message.

Anyone know why? Thanks in advance.

manish arora · ‎07-26-2010

This generaly happens when the peer recieves an IPSEC packet that specifies an SPI that does not exist in the Security association database, which means that keys that were generated by IKE to encrypt the ipsec packets is not known or has expired at the peer that recieved the packet. This could be because of slight aging difference between the SA's on the ipsec peers or because the local SA was cleared or an invalid packet was sent by the peer.

If this activity is happening a lot then it could be considered as an hostile event.

thanks

Manish

Jitendriya Athavale · ‎07-26-2010

if everything is working fine, then seeing such message could only mean one thing

when your SA lifetime is about to expire ipsec will do a rekey and generate new SA's, now during this transistion peroid which is briefly around a second 2 SA's are active so that there is no loss of traffic due to rekey

however what happens is sometimes during this rekey there is a possibility that one peer has generated the new SA but the other one is still in the process of doing it, thats when you will see these messages

we can confirm this by a simple experiment - inc/dec of lifetime should affect the frequecy of these messages

please mark this thread as answered for benifit of others if you are satisfied with our explanation

justinchen168 · ‎06-07-2018

Hi,

Cisco ASA unable renew to new SPI when after ipsec tunnel went down. This only happen when cisco ASA be a responder.

Firmware using asa904-38-k8.bin.

May i know this is a buy or wat?

Please advice.

Regards,

Justin

bule.msowoya · ‎02-03-2014

I know its been a while since this was asked but to help anyone who may still want to know here is the reason from Cisco:

It simply means IPsec Security Associations are out of sync between the peer devices. As a result, an encrypting device will encrypt traffic with SAs that its peer does not know about. These packets are dropped on the peer with the above message logged to the syslog

Read more here: http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a0080bf6100.shtml

One of the most common IPsec issues is that SAs can become out of sync between the peer devices. As a result, an encrypting device will encrypt traffic with SAs that its peer does not know about. These packets are dropped on the peer with this message logged to the syslog:

Sep  2 13:27:57.707: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet
   has invalid spi for destaddr=20.1.1.2, prot=50, spi=0xB761863E(3076621886), 
   srcaddr=10.1.1.1

babsoncisco27 · ‎06-10-2016

just issue a "clear crypto isakmp" and "clear crypto sa" on the spoke(s). That will clear up the security association and resync with the new one with the hub. Moving forward, add the "crypto isakmp invalid-spi-recovery" command in your config.

M Badrawy · ‎08-23-2017

thank you, this fixed my problem

justinchen168 · ‎06-07-2018

Firmware using asa904-38-k8.bin.
"crypto isakmp invalid-spi-recovery" command is not there.

Any others way to solve the invalid spi issue?

regards

plavine · ‎07-12-2016

I found that this may occur when the ACLs defining interesting traffic are one-sided.

Make sure that the ACL mirror each other especially when building IPSEC tunnels between an ASA and an IOS based device.

dfrye4 · ‎10-10-2018

I had this on a secure tunnel I was trying to get working. One router had this error and the others were in a routing loop, turns out the issue was in the newly deployed router missing the IP route command for the vrf tunnel. Just wanted to through that out there for anyone troubleshooting a similar issue.