IPsec tunnel received a packet with bad SPI

[pacmagsjfw]

Anyone can help me to explain this alert please? [00001] 2007-11-09 12:52:23 [Root]system-alert-00026: IPSec tunnel on interface ethernet3/2 with tunnel ID 0x30 received a packet with a bad SPI. 139.130.*.*->202.122.*.*/128, ESP, SPI 0x4a6471e9, SEQ 0x1. What does it mean by bad SPI? It seems like the VPN tunnel is working fine even this alert appears

[rkim]

Are you seeing these messages about once every hour on the hour?  If so then this could mean that both peers attempted to rekey at the same time due to phase 2 lifetime default of 1 hour.  During this time there could be a very brief moment where both peers may be sending different SPI values.  Once phase 2 rekey completes then the messages go away.  One way to prevent this is to adjust IKE soft lifetime buffer on one peer so that both peers don't try to simultaneously rekey at the same time.  Set this on only 1 peer, not both.

set ike soft-lifetime-buffer 90

[pacmagsjfw]

Thanks, it's acceptable if the two side are negotiating. But the time it happened is unpredictable

Date / Time Level Description
2007-11-11 03:15:57 alert IPSec tunnel on interface ethernet3/2 with tunnel ID 0x1a received a packet with a bad SPI.
139.130.*.*->202.122.*.*/136, ESP, SPI 0xc57971e9, SEQ 0x1.
2007-11-09 12:52:23 alert IPSec tunnel on interface ethernet3/2 with tunnel ID 0x30 received a packet with a bad SPI.
139.130.*.*->202.122.*.*/128, ESP, SPI 0x4a6471e9, SEQ 0x1.
2007-11-05 12:21:12 alert IPSec tunnel on interface ethernet3/2 with tunnel ID 0x17 received a packet with a bad SPI.
139.130.*.*->202.122.*.*/112, ESP, SPI 0xa42a71e9, SEQ 0x132.
2007-11-05 12:21:01 alert IPSec tunnel on interface ethernet3/2 with tunnel ID 0x17 received a packet with a bad SPI.
139.130.*.*->202.122.*.*/112, ESP, SPI 0xa42a71e9, SEQ 0x130.
... ... (this time it lasted for 20 minutes, alert every some seconds, i can't remember what i was doing at the moment)

But anyway, the tunnel is set up before i came and seems like it has been always working fine.

[rkim]

Is the other side a NetScreen/SSG device? If so is either side using VPN monitoring? If one side is then try enabling VPN monitoring with rekey on both sides and see if you still see the same problem. Otherwise you may need to capture via sniffer and/or snoop along with debug ike detail the failing error condition. If you still see issues or are unable to enable VPN monitoring then I'd recommend contacting JTAC and opening a support case.

[ModelCitizen]

We too receive Bad SPI messages, i.e.

2008-02-01 14:12:42 Local0.Alert 192.168.168.3 ns5gt: NetScreen device_id=ns5gt [Root]system-alert-00026: IPSec tunnel on int untrust with tunnel ID 0x3 received a packet with a bad SPI. 88.97.***.***->81.3.**.**/**, ESP, SPI 0xe7af, SEQ 0x1 (2008-02-01 14:25:28)000>

(Note: IP address replaced with *'s for security reasons).

We only one have bad SPI entry every one to three days or so.

The VPN is created by two Juniper-NS5GTs running firmware 5.3.0r4.0. The remote Netgear has an ADSL feed attached.

The VPN is used to facilitate online ordering between a web server and a booking office system and passes credit card details.

I'd like to know two things:

1) What effect the packet with the Bad SPI might have upon a person's online ordering "seesion". Might the session be destroyed?

2) How can we stop them happening and, if they don't destroy the session, does it matter if we can't get rid of them?

Thanks.

[Robbert]

same here... on different location (franchise companies in different cities in holland) towards our datacentre:

2008-09-29 16:06:11 alert IPSec tunnel on int untrust with tunnel ID 0x6 received a packet with a bad SPI. 10.0.0.138->80.101.***.***/72, ESP, SPI 0x0, SEQ 0x45000548

2008-09-29 16:05:53 alert IPSec tunnel on int untrust with tunnel ID 0x6 received a packet with a bad SPI. 10.0.0.138->80.101.***.***/72, ESP, SPI 0x0, SEQ 0x450000c0

2008-09-29 12:47:44 alert IPSec tunnel on int untrust with tunnel ID 0x6 received a packet with a bad SPI. 10.0.0.138->80.101.***.***/72, ESP, SPI 0x0, SEQ 0x45000548

2008-09-29 12:47:26 alert IPSec tunnel on int untrust with tunnel ID 0x6 received a packet with a bad SPI. 10.0.0.138->80.101.***.***/72, ESP, SPI 0x0, SEQ 0x45000098

2008-09-29 08:26:08 alert IPSec tunnel on int untrust with tunnel ID 0x6 received a packet with a bad SPI. 10.0.0.138->80.101.***.***/72, ESP, SPI 0x0, SEQ 0x45000548

2008-09-29 08:25:50 alert IPSec tunnel on int untrust with tunnel ID 0x6 received a packet with a bad SPI. 10.0.0.138->80.101.***.***/72, ESP, SPI 0x0, SEQ 0x450000c8

the result is that the tunnels are being dropped before, that is after a couple of minutes, a new connection is possible. We work with Terminal Server connections (mstsc.exe). I have now set the bufferlimit from 10 seconds to 90 seconds to see wether this will solve the issue. I have also seen that both peers have the rekeying interval of 3600 seconds, but the problem is not vacant on every location (aka netscreen at the franchise dealer). The problem only occurs on a couple of locations, not companywide.

how can i adjust the settings? more the less: should I?

anyone an idea?

thnx

Greetings 

Message Edited by Robbert on 09-29-2008 08:30 AM

Message Edited by Robbert on 09-29-2008 09:35 AM

[azi]

We have been getting similar alerts.  

IPSec tunnel on int ethernet3 with tunnel ID 0x23 received a packet with a bad SPI. 69.169.***.***->66.239.***.***/124, ESP, SPI 0x0, SEQ 0x45000060 

After going back through the logs a ways it seems we have always been getting these alerts (maybe every couple days) just more frequently as of recent (every 10-20 seconds when they happen) for our remote vpn users.  I figured such was related to the fact that some of our remote users as of last week were able to connect but with no traffic over the connection (and thus not able to access any network resources) other than establishing it and completing phase 1 and 2.  We had also experienced some other odd behavior when configuring new policies where one bi-directional policy ended up getting mismatched with another meaning for example the 1st policy's trust-untrust half was matched with the 2nd policy's untrust-trust half.  Ended up having to delete both and newly recreate to get things working correctly again.  This is what we did to remedy the issue for those certain remote vpn users - delete/remove each of their policies, gateway, vpn and user profiles and recreate anew.  I don't know what has been causing such odd behavior other than thinking perhaps the device or configuration got somewhat corrupted at some point.

I am curious to know the answers to ModelCitizen's questions as well. 

Message Edited by azi on 09-29-2008 02:12 PM

Message Edited by azi on 09-29-2008 02:13 PM

[ModelCitizen]

I'd be glad if my questions were answered too, but as it's been two months since I left them I guess there is not much chance.

The Jupiter Netscreen VPN has been so unreliable we are now replacing it. Every time there is an interruption in our ADSL feed (for instance our provider sometimes reboots it in the small hours) the VPN is lost and does not recover until at least one of the Netscreens has been rebooted. Often both Netscreens require rebooting.

We've found the devices entirely unreliable and Jupiters technical help pretty unresponsive and unhelpful.

MC

Message Edited by ModelCitizen on 09-30-2008 02:01 AM

[Michael-Kurth]

We have had no problems with VPNs re-establishing themselves automatically after a link goes down. Perhaps it is something with your local configuration, and not with the Juniper devices.

Also, I have found Juniper tech support to be far superior to Cisco, VMWare, Dell, or any other vendor I have delt with. Unless you really meant "Jupiter", in which case you are on the wrong site. 

[Clayton]

http://kb.juniper.net/index?page=content&id=KB10091&pmv=print

Just tried this, changed it to 40