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
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
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
oe=off
protostack=netkey
conn L2TP-PSK-NAT
rightsubnet=vhost:%priv
also=L2TP-PSK-noNAT
conn L2TP-PSK-noNAT
authby=secret
pfs=no
auto=add
keyingtries=3
rekey=no
ikelifetime=8h
keylife=1h
type=transport
left=YOUR.SERVER.IP.ADDRESS
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
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/*
do
echo 0 > $each/accept_redirects
echo 0 > $each/send_redirects
done
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
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 behind openswan
. Install it by running
sudo aptitude install xl2tpd
Change /etc/xl2tpd/xl2tpd.conf
to
[global]
ipsec saref = yes
[lns default]
ip range = 10.1.2.2-10.1.2.255
local ip = 10.1.2.1
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.
PPP
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
require-mschap-v2
ms-dns 8.8.8.8
ms-dns 8.8.4.4
asyncmap 0
auth
crtscts
lock
hide-password
modem
debug
name l2tpd
proxyarp
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 with xl2tpd
(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 bug too, which prevents clients with changing IP address to connect with a shared secret. So the best bet right now is to compileopenswan
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
wget http://www.openswan.org/download/openswan-2.6.24.tar.gz
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/*
do
echo 0 > $each/accept_redirects
echo 0 > $each/send_redirects
done
/etc/init.d/ipsec restart
Troubleshooting
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.