In an earlier post describing my PPTP VPN configuration, one reason I gave for my use of the (relatively) insecure protocol was that the IPsec alternative appeared to require building updated versions of the software. I’m delighted to report that that’s no longer the case.

The versions of openswan and xl2tpd shipping with Ubuntu 12.04 (precise) are more recent than those mentioned in the elderly walkthroughs I’d found, and have worked for the OS X clients I’m using.

Simple Configuration

If you need instructions for creating a VPN using pre-shared keys, this post by Riobard Zhan is good despite overlooking the required firewall configuration.

IPsec traffic can be permitted using the ufw tool:

1
2
3
4

$ sudo ufw allow proto udp from any to any port 500
Rule added
$ sudo ufw allow proto udp from any to any port 4500
Rule added

L2TP is a little more tricky. We only want to allow L2TP traffic that has been secured by IPsec, which isn’t a scenario that ufw(1) supports. The solution is to add a rule to the ufw-before-input chain by adding the following lines to /etc/ufw/before.rules.

1
2

# Allow L2TP only over IPSEC
-A ufw-before-input -m policy --dir in --pol ipsec -p udp --dport 1701 -j ACCEPT

Riobard’s instructions disable ICMP redirects through the proc filesystem, and do this on boot from rc.local. I chose to use sysctl instead:

1
2
3

$ echo "net.ipv4.conf.all.accept_redirects = 0" | sudo tee -a /etc/sysctl.conf
$ echo "net.ipv4.conf.all.send_redirects = 0" | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p

Advanced Configuration

Setting Up an IPsec L2TP VPN Server on Ubuntu gives a very thorough walkthrough for those looking to support Windows clients with certificates for IPsec and user authentication against Active Directory. Each facet of the configuration is discussed separately, so it’s useful even if (like me) you aren’t looking to use AD.

OS X and Split DNS

It turns out that OS X configures routing for IPsec/L2TP VPNs in the same way as PPTP, so I’m still unable to change my DNS resolver configuration – but not my default route – when the VPN connection is established. I’ve done a little more investigation, but it looks as though this “split DNS” configuration is only available for Cisco-flavoured IPsec VPNs.

Fortunately, the OS X resolver can be configured on a per-domain basis. A near-enough solution changes my domain so that the VPN’s nameserver is tried initially, before falling back to my local resolver after a shortened request timeout.

1
2
3

options timeout:1
nameserver 192.168.42.1
nameserver 192.168.1.1

When the VPN is disconnected, this configuration occasionally delays lookups for records in my public-facing zone. I could live with the inconvenience, but it’s an “infrastructure smell” that I’d rather not have.

A better solution is to use a different domain for the hosts that will only be accessible when I’m on the VPN.