Posts Tagged ‘Strongswan’

— looking forward to playing with it 🙂

via Andreas Steffen


we are proud to announce the first release candidate of our major new
strongSwan 5.x branch which is offering a single monolithic charon
daemon combining both IKEv1 and IKEv2 functionalities in a consistent
way. Since the old pluto daemon which goes far back to the FreeS/WAN
project will not be needed any more, all pluto code has been completely
removed. The strongSwan 4.x branch will now go into maintenance mode
but support will still be available.

For further details please refer to my blog entry:

Please test the release candidate and report any bugs, IKEv1
interoperability problems with other vendors and missing features.
ETA for the stable 5.0.0 release is end of June 2012.

Best regards

Tobias Brunner, Martin Willi, Andreas Steffen

The strongSwan Team

Andreas Steffen               
strongSwan – the Linux VPN Solution!      
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)


It occurred to me today…how ’bout trying an IPcomp scenario? Of course, looking at RFC 3173, I was very excited about running a test and actually viewing Next Header / Protocol = 108, as the IETF guys say.

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: 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 and as Responder 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 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:

config setup
# Add connections here.
conn %default
conn network1
# ipsec status
000 “network1”:[]…[]; erouted; eroute owner: #3
000 “network1”:   newest ISAKMP SA: #2; newest IPsec SA: #3;
000 #3: “network1” STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 2488s; newest IPSEC; eroute owner
000 #3: “network1” esp.525b0b48@ (0 bytes) esp.5511d8c2@ (0 bytes) comp.1169@ comp.527e@; transport
000 #2: “network1” STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 2488s; newest ISAKMP

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 ). Ciscoon 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 🙂