Screen OS

 View Only
last person joined: 9 months ago 

This is a legacy community with limited Juniper monitoring.
Expand all | Collapse all

IPsec tunnel received a packet with bad SPI

  • 1.  IPsec tunnel received a packet with bad SPI

    Posted 11-08-2007 18:45
    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


  • 2.  RE: IPsec tunnel received a packet with bad SPI

    Posted 11-08-2007 23:51
    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


  • 3.  RE: IPsec tunnel received a packet with bad SPI

    Posted 11-11-2007 14:39
    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.


  • 4.  RE: IPsec tunnel received a packet with bad SPI

    Posted 11-11-2007 19:29
    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.


  • 5.  RE: IPsec tunnel received a packet with bad SPI

    Posted 02-07-2008 07:09
    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


  • 6.  RE: IPsec tunnel received a packet with bad SPI

    Posted 09-29-2008 08:22

    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

    #Bad
    #SPI
    #lost
    #Tunnel


  • 7.  RE: IPsec tunnel received a packet with bad SPI

    Posted 09-29-2008 14:07

    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


  • 8.  RE: IPsec tunnel received a packet with bad SPI

    Posted 09-30-2008 01:59

    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

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


  • 9.  RE: IPsec tunnel received a packet with bad SPI

    Posted 05-19-2009 08:53

    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. 



  • 10.  RE: IPsec tunnel received a packet with bad SPI

    Posted 05-28-2009 05:45


  • 11.  RE: IPsec tunnel received a packet with bad SPI

    Posted 06-10-2009 07:24

    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.

     

     



  • 12.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-16-2009 13:47
    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)


  • 13.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-16-2009 13:51
    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.


  • 14.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-19-2009 12:28

    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 

     



  • 15.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-22-2009 10:46

    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.



  • 16.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-24-2009 08:35

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

     

    Thanks Everyone..



  • 17.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-24-2009 11:21

    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..



  • 18.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-24-2009 11:25

    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.



  • 19.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-24-2009 11:34

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

     

    Thanks

    Atif



  • 20.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-24-2009 11:36

    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



  • 21.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-24-2009 12:40

    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.

    Message Edited by Clayton on 07-24-2009 12:42 PM


  • 22.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-24-2009 15:31

    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 



  • 23.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-27-2009 08:12

    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.

    Message Edited by Clayton on 07-27-2009 08:15 AM


  • 24.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-28-2009 14:32

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

     

    Thanks

    Atif

     



  • 25.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-31-2009 07:27

    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....

     

     



  • 26.  RE: IPsec tunnel received a packet with bad SPI

    Posted 07-31-2009 16:16

    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



  • 27.  RE: IPsec tunnel received a packet with bad SPI

    Posted 10-22-2009 11:19

    I have a case open, no luck so far.



  • 28.  RE: IPsec tunnel received a packet with bad SPI

    Posted 12-21-2009 11:05

    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.



  • 29.  RE: IPsec tunnel received a packet with bad SPI

    Posted 01-08-2010 23:25

    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



  • 30.  RE: IPsec tunnel received a packet with bad SPI

    Posted 01-28-2010 19:09

    For the command :

     

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

    name_str

    ]

     

    what is the difference betweens these difference? thanks for advise



  • 31.  RE: IPsec tunnel received a packet with bad SPI

    Posted 05-21-2010 13:23

    Clayton,

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

    -Joshua

     



  • 32.  RE: IPsec tunnel received a packet with bad SPI

    Posted 04-06-2011 10:55

    I would like to see an update on this also.



  • 33.  RE: IPsec tunnel received a packet with bad SPI

    Posted 04-15-2011 09:32

    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.



  • 34.  RE: IPsec tunnel received a packet with bad SPI

    Posted 09-07-2011 01:20

    Hey everyone,

    I know this post is very old, but maybe it's still interesting for someone 🙂 I got the same alert:

    [00001] 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.

     

    Florian