Today, access to the internet is practically everywhere. Private communication across it is often taken for granted. There is an entire industry around secure communication and a lot of the equipment used for securing network boundaries, VPNs specifically, relies on the IPsec protocol to keep data transmissions across an unclassified computer network secure. VPN equipment in general, comes in a wide variety of different shapes and sizes, and not all speak the IPsec protocol but a lot of them do. IPsec is an open standard published by the IETF in RFC6071. The funny thing with IPsec is, is that IPsec connections often only work well if there is an (almost) identical twin in terms of equipment and firmware at the other end of the line. With some exceptions of course. But shouldn’t this be the other way around – that is: working always, with some exotic exceptions – especially because it’s an open standard? I’ll bet that any network equipment vendor has at least one IPsec capable device to offer, but none of them seem to bother if, or how, they work with other similar equipment from a competitor. This post is about life with IPsec on Linux and how this led to an IPsec configuration generator.
IPsec and interoperability issues. Fortunately, there is open source. Yes, that is what I thought initially. Open source software and open standards often go hand in hand. But in the case of IPsec, upon closer inspection, is actually worse since IPsec has been revised, updated and extended over time. And interoperability between versions is, well, very difficult at best. Where as a vendor is likely to test its own equipment between different versions. To make matters even worse: Once you’ve chosen an IPsec implementation and have an identical twin at the other end, you will find yourself confronted with a hideous amount of configuration work to do to get an IPsec connection between the systems up and running. There have been attempts to make life easier for the administrator, mostly by providing documentation and configuration examples.
Meet IPsec-tools’ Racoon. Racoon is no different. Racoon can be regarded as proven technology as it came from KAME, somewhere around the beginning of this century. As said there are plenty others, but since it’s installed on my Mac, I figured it’s still in use, which would probably mean that it works well enough for most cases. Racoon implements an older version of IKE, a protocol used for Internet Key Exchange which is part of the IPsec protocol suite. It still is available in Debian Linux, but the BSD’s have moved on and have their own implementation along with borrowed bits and pieces here and there or so it seems.
Configuring IPsec-tools/Racoon is spread out across 4 configuration files. Which took the better part of a morning to get it to work for a resonably straight forward site-2-site VPN on Debian Linux. It appears that I’m not the only one that finds IPsec horrible to configure, but it does seem that a IPsec configuration generator has not been built yet, which is why I wrote one (here).
The trustworthiness of IPsec using Raccoon that implements IKEv1/ISAKMP/Oakley is questionable as it was allegedly broken by the NSA. If that is true, then you can assume that the NSA is able to decrypt your traffic. On the other hand; it is the NSA itself that does recommend using IKEv1 *and* pre-shared keys as an interim solution to secure classified traffic (up to top secret!), before migrating to quantum resistant algorithms. Furthermore: Racoon itself is linked to OpenSSL, which had quite a few security problems recently.
If you ever plan on using IPsec: since IPsec encapsulates the original IP packet in tunnel mode, it may not fit a single IP packet if it becomes larger than the MTU minus sizeof(IPsecHeader), and thus leading to fragmentation. Fragmentation and cryptographic functions do not mix very well and may cause dropped packets. In general, but not specific to IPsec: IP fragmentation causes packet-reassembly and(!) ICMP errors if the DF bit is set anywhere along the line, leading to performance issues. This may seem obvious to some, but is an almost perfect scenario for really effective DDoS attacks. This sort of attack can have really sneaky side effects if you’ve configured your VPN to simply terminate the secure connection, for example when a time-out occurs, and allow plain unencrypted IP routing to take over. If that happens, you’re effectively leaking all data to an unclassified network(!) The big problem here is that you won’t notice that it’s happening, until it is too late.
IPsec VPN-land is indeed riddled with alphabet soup. I find it unbelievable that IPsec is shrouded in obscure configuration files, when it should be a killer feature of any modern operating system. FreeBSD requires you to recompile your kernel before you can even begin to use IPsec! I haven’t done that in a LONG time, and can imagine that it would deter many of its users to attempt to use IPsec. It stopped me from using FreeBSD this time. On the other hand: IPsec has been with us for quite some time, and its age is showing. DTLS – basically TLS over UDP – may be on the horizon for VPN-alike features (OpenVPN 3.0?)
Not all VPNs are IPsec VPNs. OpenVPN is one of those. It may solve some of the problems of IPsec but may also introduce some of its own. It’s not an open standard, but it is open source software and available for most platforms (iPad, Android, Mac OS X, Windows, Linux). There are comparisons between the two, and generally works well enough for me to keep around where IPsec simply is too cumbersome.
Please do note that a VPN was never intended to guard your anonymity, but to guarantee the secrecy/exclusiveness of information transported by it. Meaning that encrypted traffic between the notorious Alice and Bob will still be noted (Alice spoke with Bob), albeit unreadable for any observing party (Can’t figure out what they said, but they did speak). A brief observation of such 1-on-1 encrypted traffic (tcpdump/wireshark) can – to some extent – be compared with listening to two people speaking a foreign language; Even if you don’t speak it or understand a word they are saying, you can deduce information from a conversation between the two, especially if you are able to influence the speakers. Beware that with IPSec, the amount of extra bytes needed for encryption will be minimal, which means that the length of unencrypted traffic is almost the same as the encrypted traffic. And although I’m by far no cryptanalyst, I can imagine that this is potentially interesting to investigators. A bandwidth eating traffic-generator may help in such a scenario to thwart this kind of analysis.