Why am I seeing this message?

Unanswered Question
Jul 12th, 2010

I am routing OSPF routing protocol through an GRE/IPSec tunnel.  Everything is identical configured on both sides.  Yet, everything couple of hours, I am seeing this message:

Jul 13 00:13:03.807: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps:
rec'd IPSEC packet has invalid spi for destaddr=4.1.1.1,
prot=50, spi=0xDF2B3F63(3744153443), srcaddr=4.2.2.2.

I can understand that if my cisco router is establishing with another non-cisco device, I can see this message but since both VPN devices are cisco, why am I seeing this message?

R1 is running IOS version 12.3(11)YZ2 and R2 is running 12.4(15)T8.

Anyone know why?  Thanks in advance.

-----
R1:

ip access-list extented vpn
  permit gre host 4.1.1.1 host 4.2.2.2

crypto isakmp policy 1
encr aes 256
authentication pre-share
group 5
lifetime 60
crypto isakmp key 123456 address 4.2.2.2 no-xauth

crypto ipsec transform-set tset esp-aes 256 esp-sha-hmac
!
crypto map vpn 10 ipsec-isakmp
set peer 4.2.2.2
set security-association lifetime seconds 120
set transform-set tset
set pfs group5
match address vpn

interface lo0
  ip address 10.1.1.1 255.255.255.00

interface tun0
  ip address 1.1.1.1
  tun source f0/0
  tun dest 1.1.1.1
  tun key 123456

interface f0/0
  ip address 4.1.1.1
  crypto map vpn

ip route 0.0.0.0 0.0.0.0 4.1.1.254

router ofps 100
  no auto
  network 1.1.1.0 0.0.0.255 area 0
  network 10.1.1.0 0.0.0.255 area 0


-----

R2:

ip access-list extented vpn
  permit gre host 4.2.2.2 host 4.1.1.1

crypto isakmp policy 1
encr aes 256
authentication pre-share
group 5
lifetime 60
crypto isakmp key 123456 address 4.1.1.1 no-xauth

crypto ipsec transform-set tset esp-aes 256 esp-sha-hmac
!
crypto map vpn 10 ipsec-isakmp
set peer 4.1.1.1
set security-association lifetime seconds 120
set transform-set tset
set pfs group5
match address vpn

interface lo0
  ip address 10.2.1.1 255.255.255.00

interface tun0
  ip address 1.1.1.2
  tun source f0/0
  tun dest 1.1.1.1
  tun key 123456

interface f0/0
  ip address 4.2.2.2
  crypto map vpn

ip route 0.0.0.0 0.0.0.0 4.2.2.254

router ofps 100
  no auto
  network 1.1.1.0 0.0.0.255 area 0
  network 10.2.1.0 0.0.0.255 area 0

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Marcin Latosiewicz Tue, 07/13/2010 - 12:07

This message has nothing to do with Cisco or non-Cisco peers.

It just means (that for one reason or another) this peer received a IPsec encapsulated packet that doesn't match an SPI we have installed for this particular connection.

If after this message pops up you do not have connectvity this is most likely telling you that IKE FSM on both sides are not in sync, maybe some delete notifications get lost? Hard to say, this is usually caused by packet loss or much more rare by bugs in FSM.

What I woudl suggest is to enable inavlid SPI recovery, it might not be availble in 12.3.

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gt_ispir.html

HTH,

Marcin

cciesec2011 Wed, 07/14/2010 - 03:06

"this is usually caused by packet loss or much more rare by bugs in FSM".

I think the bug is much frequent than you think.  How do you explain the fact if downgraded to an older version, the issue goes away?

Marcin Latosiewicz Wed, 07/14/2010 - 03:10

Well if you're going to give me facts in pieces what do expect me to say, next time you'll tell me that the issue only appears on Fridays j/k.

It can be a bug, I'm just saying it's a rare situation comparing to packet loss. Again, invalid SPI recovery should alleviate the situation.

Which side IOS version did you change?

Marcin

cciesec2011 Wed, 07/14/2010 - 03:21

You're a funny person.  Perhaps you should try comedian j/k

I downgraded the IOS in R2.  I dont' think packet loss is an issue in my network because the two router is connected into a Catalyst 3750 running layer-3 in the lab and everything is 100/full hard code set on all sides.  There is not much traffics going between the two routers except ospf routing protocol hellos and GRE exchange, along with IPSec.

Marcin Latosiewicz Wed, 07/14/2010 - 03:32

OK, let's talk facts.

1. if the two routers establish IPsec successfully. How long does it take to see the problem?

2. When you see the problem are you able to push traffic via tunnel? (Are OSPF neigh status still up?)

3. Does the problem go away on it's own after some time? If so how long.

Based on this we can debug one way or another.

I'm inclinced to think that 12.3 is old an upgrade could be an intersting excercise :-)

Actions

This Discussion