Posts Tagged ‘stoke’

One of the best IPsec devices I have worked with so far is Stoke. And when I am saying best I mean it in a sense of compliance, flexibility, stability and performance.

Although it has its minuses, like any device on earth, the pretty SSX-3000 solution I’ve got my hands on knew most of the Remote-Access scenarios I could think of and EAP authentication on top. Besides that, I could do my work undisturbed, while my colleagues were experimenting on their own. Why? Because of the contexts: each one of these “virtual” routers minds its own business, permitting me to play around with my stuff, while the others could work very well, without having to worry about Cristina’s ideas. Now, 240k IPsec tunnels in remote-access with EAP authentication versus Radius and support for digital certificates sounds pretty good if you were to ask me. Mwell…not good enough for the Stoke guys…it seems. So they came up with an even more interesting idea: LAN-to-LAN. Now..hmm..this powerful machine, able of doing so much on RA…could it also be doing site-to-site? So, I’ve contacted my favorite Japanese techie and asked for instructions.

This is the way it works:

Let’s assume there are 2 security gateways, Tokyo (10.1.1.2) and Bucharest (10.1.1.1). Tokyo gateway protects a network (5.1.1.0/24), while in Bucharest we have another network (6.1.1.0/24). Stoke has the concept of “tunnel-enabled interface”, which is a only /32 IP address of an interface type “tunnel”. The following services are not allowed on a tunnel-enabled interface: static IP hosts, ARP, and routing protocols.

So, in our case, let’s assume the tunnel interface for Tokyo is 9.9.9.1/32 and for Bucharest it is 9.9.9.2/32.

As everything on an SSX is done via a context, let’s assume that Tokyo has a context called TB1 and Bucharest has a context called BT1, on which they have this LAN-to-LAN configuration. The configuration on Tokyo would look something like this:

context TB1

interface Tokyo-LAN

arp arpa

ip address 5.1.1.0/24

exit

interface Tokyo-Bucharest

arp arpa

ip address 10.1.1.2/24

exit

interface Tokyo-Tunnel tunnel

ip address 9.9.9.1/32

exit

ipsec policy ikev2 phase1 name si_p1

suite3

gw-authentication psk open_sesame

peer-authentication psk

exit

exit

ipsec policy ikev2 phase2 name si_p2

suite4

exit

exit

exit

tunnel Tokyo-Bucharest-TUN type ipsec protcol ip44 context TB1

enable

ip local 10.1.1.2 remote 10.1.1.1

bind interface Tokyo-Tunnel TB1

ip route 6.1.1.0/24

ip route 9.9.9.2/32

exit

ipsec policy ikev2 phase1 name si_p1

exit

ipsec policy ikev2 phase2 name si_p2

exit

port ethernet 1/1

bind interface Tokyo-LAN TB1

exit

enable

exit

port ethernet 1/0

bind interface Tokyo-Bucharest TB1

exit

service ipsec

enable

exit

While the Bucharest config should be like this:

context BT1

interface Bucharest-LAN

arp arpa

ip address 6.1.1.0/24

exit

interface Bucharest-Tokyo

arp arpa

ip address 10.1.1.1/24

exit

interface Bucharest-Tunnel tunnel

ip address 9.9.9.2/32

exit

ipsec policy ikev2 phase1 name si_p1

suite3

gw-authentication psk open_sesame

peer-authentication psk

exit

exit

ipsec policy ikev2 phase2 name si_p2

suite4

exit

exit

exit

tunnel Bucharest-Tokyo-TUN type ipsec protcol ip44 context BT1

enable

ip local 10.1.1.1 remote 10.1.1.2

bind interface Tokyo-Tunnel TB1

ip route 5.1.1.0/24

ip route 9.9.9.1/32

exit

ipsec policy ikev2 phase1 name si_p1

exit

ipsec policy ikev2 phase2 name si_p2

exit

port ethernet 2/1

bind interface Bucharest-LAN BT1

exit

enable

exit

port ethernet 2/0

bind interface Bucharest-Tokyo BT1

exit

service ipsec

enable

exit

To verify the config, run:

Stoke [TB1]# sh ike-session list

—————————————————————————-

SLOT : 1
Session Handle : f4100214
IKE Version : 2 <LAN<->LAN>
Remote IP : 10.1.1.1
IKE-SA ID : 10.1.1.1
Session State : IPSEC-ESTABLISHED, IKE-SA DONE, CHILD-SA MATURE
——————————————————————————-
While
Stoke[TB1]#sh ike-session detail handle f4100214
displays a lot of details about this session, like ports, type of authentication, lifetime values and algorithms.

Stoke[local]#sh tun
Name CctHdl Type Admin State
—————————— ——– ———- ——- ———–
Tokyo-Bucharest-TUN ce000013 ipsec:ip44 enable up
Bucharest-Tokyo-TUN ce000014 ipsec:ip44 enable up
2 objects displayed.
Stoke[local]#sh tun name Tokyo-Bucharest-TUN
will display the details of this particular tunnel.
For the moment, afaik, this is only IPv4-over-IPv4, but I can’t hardly wait to have another e-mail from these guys saying that I can also play with mixed transport on one of their new StokeOSes. 😀

Advertisements

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…

(more…)