SJ cartoon avatar

Development VPN Life: StrongSwan Song

The title of this post is fitting, mostly because I’m going to (sorta) close off my short VPN Life series with this post introducing StrongSwan - but also because I’m going to take a brief hiatus from blogging, and instead use the next few weeks to close off some client work so that I can (ironically) spend MORE time blogging (and working on other cool pet projects)!

To recap: I’ve explained what VPNs are and how they work, I’ve done a first pass on hardening your server, in preparation of a VPN, and I showed how to improve your scores on a server security audit.

The last piece of the puzzle is actually setting up the VPN (or second last, if you include setting up the clients as a puzzle piece).

Picking a VPN

For the VPN solution, I’ve decided to opt against OpenVPN, mostly because it’s not natively supported on my main computing tools: Windows 10, OSX, BlackBerry - yeah, I still rock a BlackBerry, the phones are unbreakable and are built to streamline my business workflows.

Instead, I’ll be using the IPSec-based StrongSwan with IKEv2 as my key exchange protocol.


Well, once you want cross-platform and native, you’re not left with many solutions (and I keep all my software up to date, so I don’t care about old operating systems). If you’re interested in the differences between various VPN protocols - just Google “OpenVPN vs”, pick one of the auto-completes and you’ll see 20 titles like: “PPTP vs L2TP vs OpenVPN vs SSTP vs IKEv2

  • read through a few and you’ll see repeating patterns (here and here are a couple of others).

The summary you’ll see is that PPTP is bad, OpenVPN is good, L2TP/IPSec is probably good depending on how paranoid you are about the government, and SSTP is good, but also bad because it’s proprietary.

As a disclaimer, I’ll admit to having setup a PPTP VPN server when I traveled to China for work a few months ago. I did it so that I was able to access Google services (note: Bing works just fine over there - and the more I used it, the more I liked it, it’s also the default on my BlackBerry… Works perfectly fine).

In that case, I wasn’t worried about security or the government spying on me (deep packet inspection and whatnot), I just wanted to access my travel Gmail (yes, I have a separate, travel-only Gmail account, whose credentials I don’t care about being compromised - my emails are temporarily forwarded from my personal and business accounts and very quickly deleted after replies).

Setting Up StrongSwan

So, I had planned to go through the installation process of StrongSwan much as I have with all of the other server steps, however, it ended up that I followed another post (almost) verbatim - so out of respect, I’ll simply link to that one here –> This one!

In a few weeks, I hope to come back to this post with some setup tweaks and scripts to make this easier, but part of setting up a VPN is generating certificates and keys, which involve manual password interaction (that I’d rather not automate).

Random Randomness

When I was setting up my server, I was having a discussion with a colleague regarding system entropy and about how much entropy could a headless server which is unused 99% of the time generate (as most entropy generation systems rely on hardware interrupts from interactions, disk usage, CPU usage… “Hardware noise” in general).

Since I had a server which I hadn’t touched in over a week, I thought it was a great chance to figure that out.

I logged in and checked:

cat /proc/sys/kernel/random/entropy_avail

While not scientific, when I ran that, I ended up with 126… … What does that mean? Well, it’s low. I like Wikipedia’s explanation of why this matters:

The entropy pool size in Linux is viewable through the file /proc/sys/kernel/random/entropy_avail and should generally be at least 2000 bits (out of a maximum of 4096). Entropy changes frequently.

Administrators responsible for systems that have low or zero entropy should not attempt to use /dev/urandom as a substitute for /dev/random as this may cause SSL/TLS connections to have lower-grade encryption.


On servers with low entropy, a process can appear hung when it is waiting for random characters to appear in /dev/random (on Linux-based systems).

So, essentially, low entropy can slow down processes requiring the use of /dev/random (e.g. when you’re serving up anything using SSL traffic/handshaking).

Fortunately, there is an easy fix. Install ‘haveged’ and update it to keep the entropy pool topped up around 2048 bits…

apt-get install haveged
sed -i "s/-w 1024/-w 2048/" /etc/default/haveged
service haveged start
update-rc.d haveged defaults

Checking my available entropy again, I see 2285!

Note: Just because this value is high when you check it (without haveged), it might not mean anything - especially if you’ve just installed all the software from the previous posts, which will generate a lot of entropy in the short term. You should still install haveged.

Firewall Modifications

If you follow the StrongSwan installation above, you’ll see their firewall iptables settings for the ports. If you want to make that a bit easier on yourself, use ufw’s frontend instead to open the correct ports.

ufw allow 50/udp
ufw allow 51/udp
ufw allow 500/udp
ufw allow 4500/udp

Wrapping Up

PureVPN has a series on how to setup VPNs on various platforms, but they all use username/password. It’s not too much of a stretch to figure out how to use the certificates you’ve generated, as most operating systems prompt you for the certificate when you set up the VPN.

Otherwise, that’s it for me for the next few weeks. When I’m back, I’d like to start on my massive, mega, ultra testing series (probably 10 posts across several months) … Here’s hoping!