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’ve strived to implement the crankiest drafts that ever appeared from IETF. Running this on the company I work for, interop even with this device worked well (so buy Ixia products if  you want IPsec testing ), but trying to make it work with Strongswan I’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…

Read the rest of this entry »

Tags: checkpoint, cisco, clavister, DPD, HybridInitRSA, IETF draft, IKEv1, ipsec, mode-config, NAT-T, netscreen, NGX R65, office mode, PKI, Remote-Access, sonicwall, stoke, techie, X.509, xauth

Astazi s-a produs inevitabilul: a trebuit sa invat sa configurez IPsec pe CheckPoint.

Concluzia: it SUCKS!

Un GUI incalcit cu foaaaarte multe optiuni puse neintuitiv (dupa parerea mea de om care a mai configurat si NetScreen, Cisco, Sonicwall, Clavister si Stoke) – si foarte multe chestii proprietare.

Interesant e ca suporta niste feature-uri pe care le vad rar de tot, cum ar fi autentificare asimetrica sau hybrid XAuth sau lipsa unui model clar (afaik at the moment) de configurare al Identification type-ului, ceea ce mi-a placut la nebunie, dar mi-a pus probleme de interop cu alte device-uri. – probleme pe care inca nu le-am rezolvat in totalitate.

Una peste alta, daca nu era monsieur sa ma salveze, ma manca CheckPoint-ul mare si rau.

Tags: checkpoint, draci, passion, techie