L2TP/IPSec VPN client on Slackware

29 December 2016
Following on from the article on L2TP/IPSec VPN server setup, here are instructions for setting up a corresponding Linux VPN client. A Slackware system is assumed because Slackware is now my preferred distribution, although the same instructions should work with any distribution. I had intended to also include some commentary on my choice of L2TP/IPSec, but have decided to leave that for a future article.

Linux VPN software seems to be one of those areas that has been plagued by multiple politicially-motivated forks. FreeS/WAN forked into OpenSwan and strongSwan, and the former then forked to LibreSwan. My first practical use of VPN used OpenSwan because that was what the spare server had installed, but OpenSwan seems to have fallen out of favour. To help muddy the water distributions decided to switch from OpenSwan to strongSwan rather than LibreSwan, which is a bit irritating because major changes to both command-line and configuration options mean that is is far from a drop-in replacement.

Pre-shared key client setup

This is the client-side compliment of my L2TP/IPSec server setup. Likewise the content of configuration files that need changing from a clean install are shown. Replace xxx.xxx.xxx.xxx with your VPS's IP address.

Predictably the values for name and password will need to be changed to match the server. Having defaultroute seems ineffective when a system already has a network connection, so I've opted to have nodefaultroute which only sets up a route to the VPN over the L2TP/IPSec tunnel.

Note: Change to something better, such as outout of “openssl rand -base64 32”.
Form those who prefer certificate-based authentication over pre-shared keys, this is the compliment of the server-side certificate setup. It is assumed that all the keys & certificates have been generated as part of the former setup, so first thing to do is copy the ones required by the client into place:

Once these are in place, the changes to the strongSwan configuration files required with respect to a pre-shared key setup are highlighted in bold below. I suspect the configuration has more elaboration than is actually required.

Opening up a VPN connection

Here a root shell is assumed, although in production it is expected that these commands would be put into a suid root script. Idea is to show how it can be done manually to get an understanding of what is going on.

Start strongSwan

# ipsec start
Starting strongSwan 5.3.4 IPsec [starter]...

Establish IPSec Security Association

This will print out a screen or two worth of output, but all you are really interested in is the last line:

You should also be able to ping 192.168.128.1 (the VPS on the other side of the VPN connection). At this point you can setup IP routing to send traffic over the VPN tunnel rather than using the local gateway.

Closing the VPN connection

Tearing down the VPN connection is a case of shutting down the various parts in order:

Telling xl2tpd to disconnect the L2TP tunnel

Shutting down xl2tpd

Closing the IPSec Security Association

Shutting down strongSwan

Technically these are not all strictly necessary, but here I'm assuming you want to cold-shutdown all the VON software. All these shutdown stages can be done using the following commands:

Once an L2TP/IPSec tunnel is in place, all that is left to be done is to delete the existing default route to the local gateway and add the VPS network interface as a new default route. The one trick is that traffic to the VPS itself (i.e the L2TP/IPSec connection) needs to be specifically routed to the local gateway using a single-host routing rule. Prior to disconnecting the reverse of this needs to be done. Below are two shell scripts to perform these routing table manipulations (but as usual caveat emptor, and you'll need to edit in your actual VPS IP address):

The solution is to get clients to use different port numbers. Deleting the leftprotoport and rightprotoport directive from the client's ipsec.conf seems to fix the issue, so guessing that without those directives the strongSwan client is guessing it needs to use different ephemeral ports.

DNS issues

One complicating factor is DNS addresses, as the address of the local DNS server is likely different from the one accessible from the VPS. The easiest thing to do is to setup the local machine to use Google's public DNS servers which are 8.8.8.8and 8.8.4.4, as these will always be useable regardless of which gateway is in use. In fact some VPS providers actually use these themselves rather than running their own DNS proxies.