ā07-26-2010 05:45 PM - edited ā02-21-2020 04:45 PM
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.
ā07-26-2010 06:33 PM
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
ā07-26-2010 10:22 PM
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
ā06-07-2018 01:27 AM
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
ā02-03-2014 11:49 PM
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
ā06-10-2016 01:15 PM
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.
ā08-23-2017 12:39 PM
ā06-07-2018 01:38 AM
ā07-12-2016 08:26 PM
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.
ā10-10-2018 12:51 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide