CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


Tim Hall has done it again! He has just released the 2nd edition of "Max Power".
Rather than get into details here, I urge you to check out this announcement post.
It's a massive upgrade, and well worth checking out. -E

 

Results 1 to 9 of 9

Thread: IPSec VPN - Unknown SPI for IPSec packet

  1. #1
    Join Date
    2017-10-05
    Posts
    3
    Rep Power
    0

    Default IPSec VPN - Unknown SPI for IPSec packet

    Hey Guys,

    I am hoping you might be able to assist with an issue I am having. I am in the process of upgrading our existing UTM1 appliance (running on R71) to a new Checkpoint 5200 (Running R77) security appliance we recently purchased. The existing UTM appliance has been working without issue for the last 6 years with our IPSec runnings having no issues. This is a fairly basic setup, we have a number of external sites which all have a /28 network sitting behind a gateway. Each site is managed separately with a variety of different gateways (ASAs, Checkpoints, etc).

    Click image for larger version. 

Name:	Basic Network.png 
Views:	25 
Size:	15.4 KB 
ID:	1330

    I deployed the CP5200 identically to the existing UTM1. The encryption and authentication have been setup the same (3DES, MD5, we know these arenít ideal, we are just trying to get the new device in before we make changes). We tried to cut across to the new Checkpoint 5200 and we are receiving some error messages

    Click image for larger version. 

Name:	unknown spi.png 
Views:	33 
Size:	60.3 KB 
ID:	1327Click image for larger version. 

Name:	ipsec sa.png 
Views:	38 
Size:	58.8 KB 
ID:	1328

    I have had a look through the IKE.ELG log files. I have noticed constant failure during phase1. You can see using the IKEView application the failures.

    Click image for larger version. 

Name:	IKEView logs.jpg 
Views:	37 
Size:	82.6 KB 
ID:	1329

    Below you can see some logs from our VPN diagnostics. I have attached a larger section from the VPN diagnostics that may help.

    [ 7606][29 Sep 5:32:44][] UDPConnection::~UDPConnection: enter
    [ 7606][29 Sep 5:32:44][] ~Association: a6cac48
    [ 7606][29 Sep 5:32:44][] Neg's end
    [ 7606][29 Sep 5:32:44][] WakeNegotiation: waking negotiation (a6cd4b8)
    [ 7606][29 Sep 5:32:44][] RequestBySPI: entering
    [ 7606][29 Sep 5:32:44][] GetEntryIsakmpObjectsHash: received ipaddr: 10.51.3.18 as key, found fwobj: Telstra_GW
    [ 7606][29 Sep 5:32:44][] fwipsechost_from_ipxaddr: calling GetEntryXIsakmpObjectsHash for 10.51.3.18 returned obj: 0xa6490d0
    [ 7606][29 Sep 5:32:44][] GetEntryCommunityHashX: received ipaddr: 18.3.51.10 as key, found community: Telstra
    [ 7606][29 Sep 5:32:44][] FindCommonCommunity: Found common community (IPv4 addr=18.3.51.10) (Telstra) for Telstra_GW
    [ 7606][29 Sep 5:32:44][ikev2] getIKEVersionForCommunity: Community configured to use IKEv1 only.
    [ 7606][29 Sep 5:32:44][] RequestBySPI: IKE version id is 0. IKEv2 id is 1
    [ 7606][29 Sep 5:32:44][] NegotiationTable::MatchMySPI: No Negotiation found for SPI: f494affa
    [ 7606][29 Sep 5:32:44][] UDPConnection_v4::UDPConnection_v4: peer: 10.51.3.18
    [ 7606][29 Sep 5:32:44][] RequestBySPI: will send Delete PL
    [ 7606][29 Sep 5:32:44][] NegotiationTable::MatchPeerP1Neg: Found match:
    [ 7606][29 Sep 5:32:44][] neg ptr: a6ccc68 ass: a683048 wait4: 00
    msgId: 00 method: 00 00 cookie: e09d23d52e9142f2
    req type: 0 SPIs: 00
    [ 7606][29 Sep 5:32:44][] RequestBySPI: negotiating phase 1 - delay request (a6ccc68 9db7ef8)
    [ 7606][29 Sep 5:32:44][] WaitingNegotiations::AddNegotiation: Added Negotiaton, new count: 13.
    [ 7606][29 Sep 5:32:44][] neg ptr: 9db7ef8 ass: a6af868 wait4: a6ccc68
    msgId: 5de1be83 method: 00 00 cookie: 0000
    req type: 2 SPIs: f494affa
    [ 7606][29 Sep 5:32:44][] KillNegotiation: Killing negotiation with no context (0xa6cd4b8)
    [ 7606][29 Sep 5:32:44][] WaitingNegotiations::DeleteNegotiation: Deleted negotiation from list:
    [ 7606][29 Sep 5:32:44][] neg ptr: a6cd4b8 ass: a6c3470 wait4: 00
    msgId: 6f42cff method: 00 00 cookie: 0000
    req type: 2 SPIs: f494affa
    [ 7606][29 Sep 5:32:44][] WaitingNegotiations::WakeNegotiations: called for: a6cd4b8, there are 12 waiting negs
    [ 7606][29 Sep 5:32:44][] Wakeup: Me: 9db7ef8 waiting for: a6ccc68 wake for: a6cd4b8
    [ 7606][29 Sep 5:32:44][] Wakeup: Me: a6cd1e8 waiting for: a6ccc68 wake for: a6cd4b8
    [ 7606][29 Sep 5:32:44][] Wakeup: Me: 9d8a8b8 waiting for: a6ccc68 wake for: a6cd4b8
    [ 7606][29 Sep 5:32:44][] Wakeup: Me: 9da94c8 waiting for: a6ccc68 wake for: a6cd4b8
    [ 7606][29 Sep 5:32:44][] KillNegotiation: Negotiation 0xa6cd4b8 dead.
    [ 7606][29 Sep 5:32:44][] ~Negotiation: a6cd4b8 a6c3470
    VPN diagnostics.txt


    Is anyone able to tell me what might have changed between R71 and R77 which might be causing this?

  2. #2
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,102
    Rep Power
    12

    Default Re: IPSec VPN - Unknown SPI for IPSec packet

    Please highlight tran1_key_ike in IKEView (this will show a breakdown of the transform set in the right-hand window) and take a screenshot for both packet 1 and packet 2.

    If you are failing between packet 1 and packet 2 some setting doesn't match. It is also possible there were some user.def file modifications under the hood that haven't made it into R77, but that shouldn't cause a failure this early in IKE.
    --
    Second Edition of my "Max Power" Firewall Book
    Now Available at http://www.maxpowerfirewalls.com

  3. #3
    Join Date
    2017-10-05
    Posts
    3
    Rep Power
    0

    Default Re: IPSec VPN - Unknown SPI for IPSec packet

    Main Mode packet 1
    Click image for larger version. 

Name:	mm packet 1.png 
Views:	26 
Size:	18.6 KB 
ID:	1334

    Main Mode packet 2
    Click image for larger version. 

Name:	mm packet 2.png 
Views:	21 
Size:	19.4 KB 
ID:	1333


    I had a look through $FWDIR/lib/user.def


    #ifndef __user_def__
    #define __user_def__

    //
    // User defined INSPECT code
    //



    #endif /* __user_def__ */

  4. #4
    Join Date
    2013-09-25
    Location
    Bucharest
    Posts
    645
    Rep Power
    5

    Default Re: IPSec VPN - Unknown SPI for IPSec packet

    Quote Originally Posted by ShadowPeak.com View Post
    Please highlight tran1_key_ike in IKEView (this will show a breakdown of the transform set in the right-hand window) and take a screenshot for both packet 1 and packet 2.

    If you are failing between packet 1 and packet 2 some setting doesn't match. It is also possible there were some user.def file modifications under the hood that haven't made it into R77, but that shouldn't cause a failure this early in IKE.
    I would check Smartview Tracker to see what's the exact proposal each equipment sends/receives. As mentioned this is about ENC/HASHING parameters.

  5. #5
    Join Date
    2017-10-05
    Posts
    3
    Rep Power
    0

    Default Re: IPSec VPN - Unknown SPI for IPSec packet

    I noticed one difference between our working R71 install and our failing R77 install, which is SecureXL / fwaccel. fwaccel is persistently disabled on R71, while this is active on R77. Could this cause IPSec connection issues?

  6. #6
    Join Date
    2013-09-25
    Location
    Bucharest
    Posts
    645
    Rep Power
    5

    Default Re: IPSec VPN - Unknown SPI for IPSec packet

    Quote Originally Posted by BradleyE View Post
    I noticed one difference between our working R71 install and our failing R77 install, which is SecureXL / fwaccel. fwaccel is persistently disabled on R71, while this is active on R77. Could this cause IPSec connection issues?
    fwaccel off - and see how this goes? What's your current load on the FW?

  7. #7
    Join Date
    2006-09-26
    Posts
    3,068
    Rep Power
    15

    Default Re: IPSec VPN - Unknown SPI for IPSec packet

    Quote Originally Posted by ShadowPeak.com View Post
    Please highlight tran1_key_ike in IKEView (this will show a breakdown of the transform set in the right-hand window) and take a screenshot for both packet 1 and packet 2.

    If you are failing between packet 1 and packet 2 some setting doesn't match. It is also possible there were some user.def file modifications under the hood that haven't made it into R77, but that shouldn't cause a failure this early in IKE.
    This does not explain the fact that it works in R71 and failed in R77. If it works in R71 and fails in R77 with no change in the configuration, it suggests that it is a "bug" in checkpoint somewhere. Anyways, questions:

    1- Which version of R77?
    2- are you running the latest JHFA? Checkpoint will ask you that.

    Can you test this in your lab environment and reproduce the issue?

  8. #8
    Join Date
    2011-08-02
    Location
    http://spikefishsolutions.com
    Posts
    1,508
    Rep Power
    8

    Default Re: IPSec VPN - Unknown SPI for IPSec packet

    Have you tried clearing phase I and Phase 2 on the remote firewall (Telstra_gw?). Im' guessing its not a checkpoint and that its still got reference to the old vpn tunnel and checkpoint / 3rd party aren't figuring this out. A reboot of the telstra_gw would clear the vpn tunnel for sure.

    I don't know if it would help but maybe enabling DPD (dead peer detection) would help?

  9. #9
    Join Date
    2007-03-30
    Location
    DFW, TX
    Posts
    121
    Rep Power
    11

    Default Re: IPSec VPN - Unknown SPI for IPSec packet

    Failures in main mode packet 1 or 2 with no associated IKE notification are always some kind of reachability issue. In the two negotiations you had originally expanded, I see these circumstances:

    1. You send MM 1 and do not get MM 2.
    2. You receive MM 1, send MM 2, and do not get MM 3.

    Taken together, these mean there is some kind of issue getting traffic from you to the remote side. Additionally, item 2 means your gateway is okay with the parameters the other side is proposing, otherwise you would send an IKE notification NO-PROPOSAL-CHOSEN instead of MM 2.

    I would check your routing table and run an fw monitor on your side to be sure your traffic is going out the right interface. I would then use tcpdump to be sure it's going to the right destination MAC address for the upstream router.
    Zimmie

Similar Threads

  1. IPSEC Phase1 MM packet 1
    By laf_c in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 9
    Last Post: 2017-06-16, 18:38
  2. encryption failure: Unknown SPI: 0xc00b9443 for IPsec packet.
    By ASHISH SYAL in forum Check Point IP Appliances and IPSO (Formerly Sold By Nokia)
    Replies: 5
    Last Post: 2009-12-24, 02:49
  3. GRE over IPSec
    By pawelz in forum Check Point IP Appliances and IPSO (Formerly Sold By Nokia)
    Replies: 6
    Last Post: 2007-10-27, 20:28
  4. Ipsec Vpn
    By snapper in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 2
    Last Post: 2006-03-01, 16:07
  5. TCP Packet out of state / unknown established TCP packet
    By roadrunner in forum Miscellaneous
    Replies: 0
    Last Post: 2005-08-13, 15:19

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •