The trust-point is defined as for any Cisco switch.

If for IKEv1, I would configure RSA-SIG auth like this:

crypto ikev1 enable untrusted
crypto ikev1 policy 1
 authentication rsa-sig
 encryption aes-256
 hash sha
 group 5
 lifetime 3600

- Usually this is enough for the Phase 1 – authentication to take place. We have RSA, we need to use RSA for authentication.

But for IKEv2, trying to be CONSISTENT, a basic requirement for any equipment on the market, is done like this:

crypto ikev2 enable untrusted

crypto ikev2 policy 1
 encryption aes-256
 integrity sha
 group 5
 prf sha
 lifetime seconds 3600

tunnel-group myIPsecGroup ipsec-attributes
 peer-id-validate cert
 chain
 ikev2 remote-authentication certificate
 ikev2 local-authentication certificate myTrustPointCA

I would sadly add: don’t you find it naturally that in IKEv2, the authentication has no place in the Phase 1 definition, but rather somewhere below, where I define the transform-sets (which, by the way, in IKEv2 are called differently) for the Phase 2 ??!!!

Not mentioning the fact that Cisco is the latest guy to arrive at the finish line with IKEv2 (heey, we are in 2011!!), they proved us again what a professional company it is. I would expect a no-name company from China not to be able to accomplish one of the most important requirements of professional software design: Consistency, but…Cisco?

ref: http://secret-epedemiology-statistic.org.ua/1587052091/ch17lev1sec5.html

After the latest IPsec adventure with Cisco’s Customer Support (CCIE Security) which advised me to run commands that were not even available on my IOS (yes, I had previously given them my config and IOS version), I said that whenever I have Cisco-related issues I go straight to my team lead, the guy being able to fix no matter issue I encountered on Cisco – at least on the IPsec side…

Now, I’ve had the honor of having to move an EoU/WebAuth config from a 3750 to a 6500. While I was feeling pretty good about myself being able to configure and understand the way to configure EoU and WebAuth on Cisco (EoU is NAC L2, I am using L2 interfaces in a L2 vlan in mode access and use the “ip admission” command on the L2 interface, while WebAuth gets configured as a fallback to 802.1x using the “dot1x fallback dot1x-www” on the L2 interface), I have now realized that I am FAR FAR AWAY from the truth. I’ve woken up on this twisted 6500, where I have the possibily of configuring:

1. 802.1x – fair enough, I am not using 802.1x here anyways

2. NAC Layer 2 IP / LAN Port IP – which can be configured this way (as per Cisco’s KB)

3. LAN Port IP – which, ignoring their own definition from some KBs, now appears as a “Web-Based Authentication” and gets configured…nowhere says _how_

4. NAC Layer 3 IP / NAC Gateway IP – which should be enabled on L3 interfaces

Router(config)# ip admission name webauth1 proxy http

Router(config)# interface fastethernet 5/1

Router(config-if)# ip admission webauth1

Router(config-if)# authentication order webauth

Router(config-if)# exit

Router(config)# ip device tracking

Router(config)# ip admission proxy http login page file disk1:login.htm

Router(config)# ip admission proxy http success page file disk1:success.htm

Router(config)# ip admission proxy http fail page file disk1:fail.htm

Router(config)# ip admission proxy http login expired page file disk1:expired.htm

5. NAC Gateway IP – which is configured as auth-proxy, this way:

Router(config)# ip auth-proxy name webauth http inactivity-time 60

Router(config)#interface GigabitEthernet3/15

Router(config-if)# description WEBAUTH

Router(config-if)# switchport

Router(config-if)# switchport access vlan 502

Router(config-if)# switchport mode access

Router(config-if)# ip access-group www in

Router(config-if)# spanning-tree portfast edge

Router(config-if)# ip auth-proxy webauth

Router(config)# ip access-list extended www

Router(config)# permit tcp any any eq www

Router(config)# deny   ip any any

The “aaa authentication login default radius” is on. The “ip http server” is on. The “aaa authorization auth-proxy default group radius ” is on also.

Now, I am no EoU, WebAuth, and by far no Cisco guru, but, what gives? Why so many auth methods? And, specially, why the method I use to configure one way on a 3750 (WebAuth using the “auth-proxy” set of commands) is configured some other way on 6500 (WebAuth using the “ip admission <name> proxy http” set of commands) – while keeping the “auth-proxy” set of commands – which here do something else. Why is it so hard to be consistent all over your own set of devices?

I have done 802.1x on Summit (netlogin called in there), WebAuth on Summit and WebAuth on HP switches. None of them seemed so damn confusing I am lost.

Basically, the “Compression” part of this IPsec traffic is negotiated just as  any other protocol: AH, ESP, EAP…via IKE, or manually configured on a device. Now…as I’ve got to devices….good question: _what_ device could I use if I want IPsec IPCompression?

Look at this: http://www.vpnc.org/vpnc-ipsec-features-chart.html. Scroll down to “Features (HTML table). The vendors that actually implement this, as per VPN Consortium (and for some of them I could tell you from direct experience), are CheckPoint, Cisco, McAfee, SafeNet, StoneSF and TeamF1. A bit disappointed that I didn’t have the opportunity of working on all of these devices, I am redirecting my attention to what I do have: a big, shiny and fluffy Debian, with Strongswan installed and xfrm module also on.

So, lets get down to business. I have taken the simplest scenario I could think of at the moment, a transport mode scenario, having as Initiator 192.168.0.10 and as Responder 192.168.0.1. These two hosts negotiate 3des-md5-dh2 algorithms, doing PSK authentication. No PFS, no other kinky stuff. Just basic IKEv2 negotiation. The Strongswan config is as simple as possible.

*Note 1 : on strongswan.org people say that IKEv2 does not support compression – I have run a test with IKEv2 and compression and it works very well But, in order to humor the strongswan guys, I have used IKEv1 in the following scenario

*Note 2 : in order to actually _see_ the encapsulated packets, I have used ESP-NULL Encryption for data encapsulation. Yes, I could have used a NetCocoon analyzer, but that – in the next episode

So: IKEv1, Transport mode, Main Mode, Null Encryption, ESP only, IP Comp:

# ipsec status

000 “network1″: 192.168.0.1[192.168.0.1]…192.168.0.10[192.168.0.10]; erouted; eroute owner: #3

000 “network1″:   newest ISAKMP SA: #2; newest IPsec SA: #3;

000

000 #3: “network1″ STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 2488s; newest IPSEC; eroute owner

000 #3: “network1″ esp.525b0b48@192.168.0.10 (0 bytes) esp.5511d8c2@192.168.0.1 (0 bytes) comp.1169@192.168.0.10 comp.527e@192.168.0.1; transport

000 #2: “network1″ STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 2488s; newest ISAKMP

000

Yes, it worked.

Now…I am not sure what exact compression algorithms this Strongswan daemon has, but I can tell you for sure it uses at least DEFLATE (  RFC 2394 ). Cisco on the other hand, uses only LZS (RFC 2395 ) – as far as I have seen – to be updated if anybody else tested it versus DEFLATE.

The process of actually obtaining this cute ESP packets is the following:

a. get the Data from the upper layers of the TCP stack – doh, we need data

b. compress the Data above using the chosen algorithm – you will notice the CPI – Compression Parameter Index – which has well know identifiers for the well known compression algorithms

c. set the Next Header value of the IPComp header to the layer 4 protocol (in this case, TCP)

d. encapsulate everything in ESP, put on the corresponding SPI, set the Next Header value of the ESP header to 108 (0x6c)

e. wrap it up in IP and… we are all set

— You can admire the ESP of IKEv1 in the screenshot attached

Now, what happens differently with IKEv2? I was telling you before the on Strongswan, IKEv2 and AH is a no-no for the moment, ESP with null encryption does a weird thinggie that vmp was so kind to point it out for me (while I was feeling actually quite happy about myself being able to do an IPComp test via IKEv1).

The thing is that, unlike the (correct) way of doing IPComp in IKEv1 (see the aboe a. to e. steps), IKEv2 implementation of Strongswan does a weird thing:

a. get the Data ..blah-blah

b. compress the Data with whatever compression algorithm and put on the IPComp header with CPI value and all

* c. put on another IP header (the internal one, in case of a tunnel mode scenario)

d. put on the ESP header

e. wrap everything up

— Unfortunately, you CANNOT admire the ESP of IKEV2 in a screenshot, because my current wireshark has no idea on how to do decompression of this type of packet. Once it does, I will update

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

[Show as slideshow]

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:

having ipsec.secrets:

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

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

Agenda evenimentului e pe site-ul Cisco Expo 2008. Mi-a placut prezentarea, companiile – numeroase si nu prea si multa lume cunoscuta din domeniu. Din pacate, nu am ajuns la niciunul dintre workshop-uri, insa am avut ocazia sa vorbesc cu oameni interesanti. Cei mai multi au venit sa intrebe ce facem noi, ce e cu solutiile de mentenanta care impanzesc harta Norvegiei IxRAVE, colegii de la layer 2-3 le-au prezentat solutiile noastre de testare de Routing, Acces si VPN – IxNetwork, iar pe partea de layer 4-7 am prezentat solutia de SIP si RTP din IxLoad. Am observat ca suntem prea putin cunoscuti sau populari in Romania, probabil si din cauza inaccesibilitatii preturilor pe piata aceasta.

Un amanunt care mi-a colorat putin cele 6 ore petrecute la stand a fost vizita a doi reporteri atrasi de graficele colorate displayate pentru traficul de SIP si RTP QoS. Au venit sa ma intrebe despre ce este vorba in acest produs. Am inceput imediat sa explic, sa arat, sa demonstrez, sa prezint cum integram noi VoIP cu security, cum facem noi 15000 de endpointi de SIP peste tot atatea tunele IPsec…si tot asa. Dupa 5 minute in care oamenii aia se uitau dragut la mine, unul din ei imi spune politicos: “Domnisoara, noi nu cunoastem detalii tehnice, lucram pentru o televiziune, si ne-au placut graficele dumneavoastra colorate. Am putea, va rugam, sa filmam putin demo-ul acesta?”…Cred ca trebuie sa mai lucrez putin la people skills. Eh, cel putin nu au plecat, si au fost draguti sa asculte tot mambo–jumbo-ul meu imbibat cu acronime care de care mai haioase

Overall, un eveniment dragut, poate putin cam prea slab tehnic pentru gustul meu, dar o ocazie frumoasa de schimbat carti de vizita si de prezentat compania persoanelor din bransa. Pentru a doua zi, cautati feedback in alta parte, ca eu am prestat numai in prima.