Recently I’ve had the opportunity of playing a bit with a CheckPoint UTM NGX R65 – ze mighty solution from the CheckPoint guys. Ignoring the obvious impediments (Romanian posts) I had when configuring the device from GUI, it left me a nice impression.

These guys are not quite the interop gurus ever, but they strive to implement the crankiest drafts that ever appeared from IETF. Running this on my own, the interop even with this device worked well, but trying to make it work with StrongswanI’ve got into big trouble.

Why? Well, let’s take a look at the most common IPsec – IKEv1 implementations. They usually pick one/more of the following standards:

– RFC 2407

– RFC 2408

– RFC 2409

– RFC 3706 – should you like DPD – Dead Peer Detection

– RFC 3947 and RFC 3948 for NAT-T

mode-cfg-02 draft – for the most common Mode-Configuration operations (perfectly inter-operable by Cisco, Juniper’s ScreenOS, Strongswan, Sonicwall, Stoke and Clavister) – as you may have guessed, NO, NOT with CheckPoint

draft-beaulieu-ike-xauth-02 – for xAuth authentication of clients – inter-operable on Cisco, NetScreen, Stoke and Sonicwall (not sure about Clavister – haven’t tried it yet) – and, yes, not on CheckPoint

As a nice old guy would say: “Security through obscurity” , not quite my favorite idea of _security_. Still, a good to follow idea for CheckPoint. Why? Because, even though they implement the RFC 2407, 2408 and 2409, they have decided not to implement the most common xAuth draft (presented above), feeling that symmetrical authentication is just too lame, so they have implemented draft-zegman-ike-hybrid-auth-01, which defines how to do uni-directional independent authentication on the remote-access scenarios – procedure enforced by the CheckPoint VPN Client (only, if you ask me, though I haven’t tried too many others).

Once you bypass this authentication procedure, configuring the UTM to authenticate the clients using X.509 certificates, you end up in yet another dead-end: the so-called Office-Mode, which is the CheckPoint way of saying “Mode-Configuration”, with a significant difference: the actual packet exchange is not standard. We have tried, me and my programmer fellows (by the way: thanks for enduring this by my side), to “reverse-engineer” this mighty exchange, but even with the CheckPoint debug and hacking into our friend pluto, we didn’t manage to get it right.

I have talked to a tech-support guy from CKP, a very nice person, still incapable of saying anything about their solution without first asking for permission from his PM/Management/whatever. So, up until today, I haven’t been able to pull this through. This is why the things I’m going to describe below are only ALMOST CheckPoint IPsec…

So, once you have installed NGX R65 (of course, I only  had a trial version), define a main interface, generate a self-signed certificate for the UTM, and allow GUI clients to administer the device via SmartDashboard:

1. Open SmartDashboard > Network Objects > CheckPoint > double-click the name you gave to the current UTM (mine is CKP-R65) > General Properties > check the VPN box under “Check Point Products”

still on CKP-R65- > under Topology tab, Edit the networks there as to identify as “This network” the main IP address, the one you bound to the RSA, and put the secondary one (of course, you’ve defined a secondary one) as “External”

still on CKP-R65- > under VPN tab, Add “Remote Access” to the upper Area, stating that “This module participates in the following VPN Communities”

still on CKP-R65- > under Remote Access > under Office Mode I have checked the “Do not offer Office Mode” option

Hit OK, then go to Menu > Policy > Install Database… and install it on the UTM.

2. In the main Dashboard window > Network Objects > right-click on Networks > Create new network, give it a name and then configure it. This shall be the Remote-Access pool for Office Mode (which we won’t do, cuz we don’t get till there with pluto)

3. In the main Dashboard window > (fifth tab) Users > right-click Users Group, create a new group, then right-click on Users and create a new user, assigning it to the previously created Remote-Access group

4. Now would be a good moment to save everything on the UTM > Install Policies.

5 – version 1. What I’ve done next is to create a new (external) CA (which is a 2003 Server CA I had at hand), enroll the CheckPoint to this CA and try to create a user certificate for my CheckPoint user. I thought of exporting this user certificate on my Strongswan and authenticate it to the gateway. Unfortunately, I’ve seen no way of indicating to which CA the user certificate gets enrolled – the user certificate I have created from the user page always got enrolled to the CheckPoint’s self-signed CA – not exactly what I had in mind

5 – version 2. I have done some more reading on the Internet, and found a procedure of actually exporting the CheckPoint’s self-signed cert from the UTM, to a p12 file. God-like! I have exported the CKP-R65’s certificate, then put it under the …/ipsec.d/cacerts directory on debian. This way, it seems that strongswan passes the authentication stage – still not hybrid, but still authentication 🙂

1 2 3 4 5 6

 

My Strongswan machine has an IP address (20.0.0.2) and tries to do Remote-Access to the CheckPoint. The Strongswan config looks like this:

conn %default
keyingtries=1
keyexchange=ikev1
mobike=no
pfs=no
type=tunnel
auto=add
ike=aes256-sha1-modp1024
esp=aes256-sha1
leftfirewall=yes
authby=rsasig
conn ra1
left=20.0.0.2
right=20.0.0.1
rightsubnet=10.205.17.0/24
leftcert=user1.pem
rightcert=CKP-R65.pem
leftrsasigkey=user1_key.pem
leftid=user1
rightid=10.205.17.251

having ipsec.secrets:

: RSA /usr/local/etc/ipsec.d/private/user1_key.pem “password”

And when I do
ipsec up ra1
I get this:
/usr/local/etc# ipsec up ra1
002 “ra1” #1: initiating Main Mode
104 “ra1” #1: STATE_MAIN_I1: initiate
106 “ra1” #1: STATE_MAIN_I2: sent MI2, expecting MR2
002 “ra1” #1: we have a cert and are sending it upon request
108 “ra1” #1: STATE_MAIN_I3: sent MI3, expecting MR3
002 “ra1” #1: Peer ID is ID_IPV4_ADDR: ‘10.205.17.251’
002 “ra1” #1: crl not found
002 “ra1” #1: certificate status unknown
003 “ra1” #1: no public key known for ‘10.205.17.251’
217 “ra1” #1: STATE_MAIN_I3: INVALID_KEY_INFORMATION
002 “ra1” #1: sending encrypted notification INVALID_KEY_INFORMATION to 20.0.0.1:500

Now, the solution may seem simple, BUUUT:

a. CheckPoint does not want to use its DNS name as Identification Payload for IKEv1 for the Remote-Access scenarios

b. Also, the certificate cannot be generated for external networks, so there has to be 10.205.17.251.

c. ALSO, although not recommended for security purposes, even if I configure Strongswan to identify the DUT per its 10.205.17.251 IP address, still I get the INVALID_KEY_INFORMATION error.

*** Now, should any one of you nice readers have solved this scenario and actually get a CheckPoint device to work with another solution (not necessarily open-source), please have mercy on my poor soul and let me know 🙂

Advertisements
Comments
  1. riccardo says:

    I’ve succesfully followed the guide at http://www.fw-1.de/aerasec/ng/vpn-racoon/CP-VPN1-NG-Linux-racoon-roadwarrior.html
    with only minor changes. On my setup I had to disable server cert verification, because CP hands you conflicting informations.
    So my remote config on client is

    remote x.x.x.x {
    exchange_mode_main;
    certificate_type x509 “server.pem” “serverkey.pem”;
    my_identifier asn1dn;
    peers_identifier asn1dn;
    verify_cert off;
    proposal {
    encryption_algorithm 3des;
    hash_algorithm sha1;
    authentication_method rsasig;
    dh_group modp1024;
    }
    }

  2. joe says:

    Hey, I was just wondering: did you ever manage to solve this problem?

  3. @joe: hmm, not really. Not for RemoteAccess anyway – PSK and not with Office Mode (as they call the ModeCfg).

    I managed to run Site-to-Site very well – both PSK and RSA, and also RemoteAccess – RSA only without Office Mode.

  4. kltxfm says:

    This is fairly old, but in case anyone else wants to try this: you get passed the INVALID_ID by setting the local ID type to ‘userfqdn’ (either left=’userfqdn:…’ or left=’@@…’ even if ID is empty).

    But then you will probably fail with modeconfig (office mode).

    XAUTH will fail because of Chkpts proprietary message IDs (hard to fix – they collide with internal strongswan IDs).

    You can use Shrew Softs ikec instead.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s