11-08-2007 06:44 PM
11-08-2007 11:50 PM
11-11-2007 02:38 PM
11-11-2007 07:28 PM
02-07-2008 07:09 AM
09-29-2008 08:22 AM - edited 09-29-2008 09:35 AM
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?
09-29-2008 02:07 PM - edited 09-29-2008 02:13 PM
We have been getting similar alerts.
IPSec tunnel on int ethernet3 with tunnel ID 0x23
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.
09-30-2008 01:59 AM - edited 09-30-2008 02:01 AM
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.
05-19-2009 08:52 AM
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.
06-10-2009 07:24 AM
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.
07-16-2009 01:46 PM
07-16-2009 01:50 PM
07-19-2009 12:28 PM
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 :
IF the issue still persist , please provide the "get event"
07-22-2009 10:45 AM
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.