Screen OS

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

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.

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.
#SPI
#Bad

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 

#Bad
#SPI
#lost
#Tunnel

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. 

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

#netscreen
#ADSL
#no
#lost
#Jupiter
#Unreliable
#recovery.
#vpn
#interruption

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. 

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

 

 

Just tried this, changed it to 40

Hi any ideas on this from anyone.. ?

 

Nothing seems to resolve this issue. it only happens to us on one of our 14 tunnels. the rest are fine. All the other tunnels go to an SSG5 the same model and firmware revision as the problem tunnel.The Central appliance is a SSG140.

 

 

I've seen this occur in two different fashions.  One, where Rekey was turned on at the remote and local sites. And the second where NO-PFS was set in the local Ike and G2 set at the remote (How it ever established Phase II in the first place is beyond me)

I did have rekey on at both home and remote sites, I just turned it off at the remote. Will see what happens and post back. As far as how the other established P2, it's beyond me as well. Thanks.

First remove the monitor rekey from any one firewall  and please apply the below command on both Peer devices:

 

"set ike soft-lifetime-buffer 40" on one firewall

"set ike soft-lifetime-buffer 10" on other firewall

 

It may possible , applying  only on one firewall it may not works.

After applying the above cmds , please disconnect the VPN and then reconnect it back.

 

IF you still see the issue , please upgrade the firewall to 5.4r11 ( or above ) 6.0r7 ( or above) or 6.1r4 ( or above).

This might be the same issue of the Bug Id is 254631.

Please find this Bug ID in the following link :

http://www.juniper.net/techpubs/software/screenos/screenos5.4.0/rn_540r11.pdf

 

IF the issue still persist , please provide the "get event"

 

Thanks

Atif 

 

I removed the monitor "rekey" from the remote devices. There are now substancially less SPI entries in the log now but they are still occuring. However it's only occuring from 1 of the 14 locations. The "set ike soft-lifetime-buffer" on one firewall was set to forty, the other to 50. I rest them as suggested to 10 and 40. will wait a few days and post back the results.

 

Thanks for your replies.

So far all is well, no bad packets. Unless I post back consider this resolved.

 

Thanks Everyone..

Still getting them..

 

2009-07-24 13:22:34  alert IPSec tunnel on interface ethernet0/2 with tunnel ID 0x49 received a packet with a bad SPI. 69.74.x.x->65.51.x.x/104, ESP, SPI 0xfae14d47, SEQ 0x1

 

 

Not sure what to do next. It's not causing the tunnel to renegotiate though..

Get Event:

 

2009-07-24 14:21:55 system alert 00026 IPSec tunnel on interface ethernet0/2
                                       with tunnel ID 0x49 received a packet
                                       with a bad SPI.
                                       69.74.x.x->65.51.x.x/256, ESP,
                                       SPI 0xfae14d56, SEQ 0x1.

Can you please confirm that monitor rekey is only on one device when you have applied the soft-lifetime-buffer key ?

 

Thanks

Atif

Can you please confirm that monitor rekey is only on one device when you have applied the soft-lifetime-buffer key ?

 

Also please provide the "get event"

 

Thanks

Atif

Hi,

 

Yes, monitor rekey is only on "checked" on the SSG140 at the datacenter, all the ssg5's have that box "unchecked". 

 

Here's the get event:

 

2009-07-24 14:21:55 system info  00536 IKE 69.74..x.x Phase 2 msg ID
                                       8956d279: Completed negotiations with
                                       SPI fae14d56, tunnel ID 73, and
                                       lifetime 3600 seconds/0 KB.
2009-07-24 14:21:55 system alert 00026 IPSec tunnel on interface ethernet0/2
                                       with tunnel ID 0x49 received a packet
                                       with a bad SPI.
                                       69.74..x.x ->65.51..x.x /256, ESP,
                                       SPI 0xfae14d56, SEQ 0x1.
2009-07-24 14:21:55 system info  00536 IKE 69.74..x.x: Received a
                                       notification message for DOI 1 40001
                                       NOTIFY_NS_NHTB_INFORM.
2009-07-24 14:21:55 system info  00536 IKE 69.74..x.x Phase 2 msg ID
                                       8956d279: Responded to the peer's
                                       first message.

Can you pleasea provide the complete get event or atleast for that 1 hours period.

The reason I am asking , I need to check the Bad SPI is coming at the time of rekey or it is coming randomly.

 

Thanks

Atif 

Ok, here's the latest one below, this one does seem to correlate with rekeys.. not everyone does however. I will track this and let you know.

 

 

What are your thoughts ? 

 

 

2009-07-27 10:26:40 system info  00536 IKE 69.74.x.x Phase 2 msg ID
                                       f9aa75d9: Completed negotiations with
                                       SPI fae151b2, tunnel ID 73, and
                                       lifetime 3600 seconds/0 KB.
2009-07-27 10:26:40 system alert 00026 IPSec tunnel on interface ethernet0/2
                                       with tunnel ID 0x49 received a packet
                                       with a bad SPI.
                                       69.74.x.x->65.51.x.x10/256, ESP,
                                       SPI 0xfae151b2, SEQ 0x1.
2009-07-27 10:26:40 system info  00536 IKE 69.74.x.x: Received a
                                       notification message for DOI 1 40001
                                       NOTIFY_NS_NHTB_INFORM.
2009-07-27 10:26:40 system info  00536 IKE 69.74.x.x Phase 2 msg ID
                                       f9aa75d9: Responded to the peer's
                                       first message.
2009-07-27 10:26:40 system info  00536 IKE 69.74.x.x Phase 1: Completed
                                       Main mode negotiations with a
                                       28800-second lifetime.
2009-07-27 10:26:39 system info  00536 IKE 69.74.x.x Phase 1: Responder
                                       starts MAIN mode negotiations.

Is it happen everytime at the time of rekey ? if not How often does it happen ?

 

Thanks

Atif

 

After reviewing the logs I've determined it happens 95% of the time at reykey but occasionly does it wit no other entries in the logs at the same time.

 

Out of now 16 locations it only happens at the one location with any regularity, when it happens, it happens for the most part at rekey. The config is identical to the others other then the interface addresses.

 

I'm not loosing the tunnel but we do run IP Phones over this unit and it's a key location as it's a call center.

 

I'm hoping to avoid a problem by solving this now.

 

I appeciate the replies....

 

 

Hi,

 

Please open a case with JTAC. JTAC engineer will help you out to collect the debug data which could help us to find the clue of the issue.

 

Thanks

Atif

I have a case open, no luck so far.

Hi,

 

I have had a case open for a long time on this. Still no luck. The techs have had me make lots of changes and collect lots of data from the firewalls but still no resolution.

 

If any of you Juniper guys want to look at the case notes:

2009-1020-0223 is the case number.

 

We could use the help. It's still a very live case.

If both sides are ScreenOS boxes. Try turning on responder and initiator commit bit on both sides. The issue should be fixed. I guess problem is one side completes the rekey and starts encrypting the packets; where as other side is still trying to finish the rekey. Hopefully it helps.

 

set ike initiator-set-commit

set ike responder-set-commit

For the command :

 

set ike initial-contact [ all-peers | single-gateway

name_str

]

 

what is the difference betweens these difference? thanks for advise

Clayton,

   Did this ever get resolved?  I'm experiencing the same issue on a NS5GT.

-Joshua

 

I would like to see an update on this also.

I wish I could say there was a resolution but everything Juniper support had me try did not work.  I was checking here just today to see if anyone came up with a solution.