Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
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 0x450005482008-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 0x450000c02008-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 0x450005482008-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 0x450000982008-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 0x450005482008-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 0x450000c8the 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?
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.
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.
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.
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).
Please find this Bug ID in the following link :
IF the issue still persist , please provide the "get event"
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.
Still getting them..
Not sure what to do next. It's not causing the tunnel to renegotiate though..
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 ?
Also please provide the "get event"
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.
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 ?
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....
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.
I have a case open, no luck so far.
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
what is the difference betweens these difference? thanks for advise
Did this ever get resolved? I'm experiencing the same issue on a NS5GT.
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.
Hey everyone,I know this post is very old, but maybe it's still interesting for someone 🙂 I got the same alert: 2011-09-07 00:02:05 [Root]system-alert-00026: IPSec tunnel on interface ethernet0/0 with tunnel ID 0xe received a packet with a bad SPI. 108.xxx.xxx.xxx->212.xxx.xxx.xxx/xx, ESP, SPI 0xaba9519d, SEQ 0x1.After comparing the settings on both sides, it turned out that the lifetime (phase 2 proposal) of the encryption key was set to different values - 3600 seconds on the remote side (108.xxx.xxx.xxx), 28800 seconds here on my side (212.xxx.xxx.xxx). So I modified the settings, set them to the same value and - what a surprise - it works, the alerts disappeared.
I hope I could help someone with this post.