Sunday, June 3, 2012

Configure L2TP/IPSec VPN on Ubuntu

Configure L2TP/IPSec VPN on Ubuntu

I need a working L2TP/IPSec VPN for my MacBook and iPhone. I used to have PPTP since it is easy to configure. However some friends suggest that PPTP might not be available on certain 3G networks (i.e. China Unicom) and only L2TP/IPSec is allowed. The extra security of IPSec is also nice to have.
You need several components in order to run L2TP/IPSec.


IPSec encrypts your IP packets to provide encryption and authentication, so no one can decrypt or forge data between your Mac/iPhone and your server. openswan is the preferred daemon to run IPSec. Install it on your Ubuntu server:
sudo aptitude install openswan
There are several ways to handle encryption for IPSec. I use Pre-Shared Key since it is easy to tweak. Change /etc/ipsec.conf to this:
version 2.0
config setup


conn L2TP-PSK-noNAT
and change /etc/ipsec.secrets to
YOUR.SERVER.IP.ADDRESS   %any:  PSK "YourSharedSecret"
Remember to change YOUR.SERVER.IP.ADDRESS and YourSharedSecret accordingly.
Run the following command for openswan to stop complaining
for each in /proc/sys/net/ipv4/conf/*
    echo 0 > $each/accept_redirects
    echo 0 > $each/send_redirects
Check if IPSec is correctly setup
sudo ipsec verify
Don’t worry about the disabled Opportunistic Encryption Support. Just make sure other checks are passed OK. Then restart openswan by running
sudo /etc/init.d/ipsec restart
Now you can add a L2TP/IPSec connection on your OS X and see if IPSec is working. Use whatever account and password. We are not there yet. The only thing you need to make sure is that you connect to the right server with the right shared secret as specified in /etc/ipsec.secrets on your server.
Monitor /var/log/system.log on your OS X by running
tail -f /var/log/system.log
while OS X is trying to connect to your server via L2TP/IPSec. It will fail eventually because we haven’t configured L2TP yet, but if you see a line in the system log saying something like
Apr 30 18:12:48 bender pppd[1507]: IPSec connection established
IPSec is good to go.


L2TP provides a tunnel to send data. It does not provide encryption and authentication though, that is why we need to use it together with IPSec. Interestingly, both Apple and Microsoft tend to refer L2TP as the secure VPN technology but totally ignore the fact that security is provided by IPSec.
The commonly used L2TP daemon is xl2tpd from the same buys behindopenswan. Install it by running
sudo aptitude install xl2tpd
Change /etc/xl2tpd/xl2tpd.conf to
ipsec saref = yes

[lns default]
ip range =
local ip =
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
ip range is the set of internal IP addresses that will allocate to clients connected. Make sure it does not overlap with your exisiting IP addresses being used, and not in conflict with the ones on the client’s network. Since most home routers use 172.16.X.X and 192.168.X.X range, you might want to avoid that. local ip is the internal IP for the L2TP server. Make sure it is NOT in the ip range allocated to clients.


I also run PPTP service using PPP, so I would like to use the same daemon to handle user managenet. Install ppp by running
sudo aptitude install ppp
if you do not have it. Create this file /etc/ppp/options.xl2tpd with the following content
asyncmap 0
name l2tpd
lcp-echo-interval 30
lcp-echo-failure 4
Note I am using Google Public DNS in the ms-dns field. If you want to use other DNS servers, change the IP addresses accordingly.
Add a test user in /etc/ppp/chap-secrets to try out if L2TP works.
# user      server      password            ip
test        l2tpd       testpassword        *
Now restart xl2tpd by running
sudo /etc/init.d/xl2tpd restart
In addition, if you use iptables for firewalling, make sure it forwards packets so you can browse the Interent after connecting to VPN. Run the following command
iptables --table nat --append POSTROUTING --jump MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

Almost Done

Update the L2TP/IPSec VPN connection on your OS X with the test user account and try connect. If it can connect and authenticate successfully, congrats! You are done. Now go enjoy the better security.
However if you are running Ubuntu 9.10 you will probably have to work a little bit more. openswan 2.6.22 in Ubuntu 9.10 does not play well withxl2tpd (though older openswan 2.4.x in Debian 5 and Ubuntu 8.04 should be fine): you can connect via IPSec, but it never talks L2TP. You need to upgrade to openswan 2.6.24. As of now there is no ready-made .deb package for you to upgrade. Time to get your hands dirty compiling from source code!
(Update May 1, 2010) I was helping Lawrence to setup L2TP/IPSec VPN on his Debian Lenny server. It has openswan 2.4.12. Turns out that version has a bugtoo, which prevents clients with changing IP address to connect with a shared secret. So the best bet right now is to compile openswan 2.6.24 from source.

Compiling Openswan from Source

SSH into your server and choose a temporary directory to do the following
sudo aptitude install libgmp3-dev gawk flex bison
tar xf openswan-2.6.24.tar.gz
cd openswan-2.6.24
make programs
sudo make install
The process might take a while so please be patient. You need a decent Linux kernel (2.6.6+) for this to work. Read openswan-2.6.24/README if you are using Linux kernel 2.4.x or do not want to use Netkey.
You do not need the packaged openswan installed by aptitude anymore. Remove it (but keep all config files) by running
sudo aptitude remove openswan
Then restart the openswan installed from source
sudo /etc/init.d/ipsec restart
Try connect from OS X. It should work now.

One More Thing

For some reason openswan does not start correctly after reboot, so I put the following lines in my /etc/rc.local
iptables --table nat --append POSTROUTING --jump MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
for each in /proc/sys/net/ipv4/conf/*
    echo 0 > $each/accept_redirects
    echo 0 > $each/send_redirects
/etc/init.d/ipsec restart


On the server side you can monitor /var/log/auth.log and see what is going on with the connection. On OS X you can monitor/var/log/system.log. These two should give you enough information to determine which part is malfunctioning in case of failure. Openswan’s mailing list is a good place to go if you cannot figure out what is wrong.


Post a Comment