[alert style=”green”]This tutorial is originally written by: Remy Van Elst @ www.raymii.org (original post here)[/alert]
This is a guide on setting up a IPSEC/L2TP vpn on Ubuntu 12.10 using Openswan as the IPsec server, xl2tpd as the l2tp provider and ppp for authentication. We choose the IPSEC/L2TP protocol stack because of recent vulnerabilities found in pptpd VPNs.
IPSec encrypts your IP packets to provide encryption and authentication, so no one can decrypt or forge data between your clients and your server. 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.
To work trough this tutorial you should have:
- 1 ubuntu 12.10 server with at least 1 public IP address and root access
- 1 (or more) clients running an OS that support IPsec/L2tp vpns (Ubuntu, Mac OS, Windows, Android).
- Ports 1701 TCP, 4500 UDP and 500 UDP opened in the firewall.
If you are not running Ubuntu 12.10 you might have to compile the packages manually because openswan and xl2tpd in the older repositories seem to have critical bugs which make this all fail.
I do all the steps as the root user. You should do to, but only via * -i* or * su -*. Do not allow root to login via SSH!
Install ppp openswan and xl2tpd
First we will install the required packages:
|
1 2 |
apt-get install openswan xl2tpd ppp |
The openswan installation will ask some questions, this tutorial works with the default answers (just enter through it).
If you do not have lsof installed you also need to install that, otherwise the ipsec verify will fail:
|
1 2 |
apt-get install lsof |
Firewall and sysctl
We are going to set the firewall and make sure the kernel forwards IP packets:
Execute this command to enable the iptables firewall to allow the vpn:
|
1 2 |
iptables --table nat --append POSTROUTING --jump MASQUERADE |
Execute the below commands to enable kernel IP packet forwarding and disable ICP redirects.
|
1 2 3 4 5 6 |
echo "net.ipv4.ip_forward = 1" | tee -a /etc/sysctl.conf echo "net.ipv4.conf.all.accept_redirects = 0" | tee -a /etc/sysctl.conf echo "net.ipv4.conf.all.send_redirects = 0" | tee -a /etc/sysctl.conf for vpn in /proc/sys/net/ipv4/conf/*; do echo 0 > $vpn/accept_redirects; echo 0 > $vpn/send_redirects; done sysctl -p |
/etc/rc.local
To make sure this keeps working at boot you might want to add the following to /etc/rc.local:
|
1 2 3 |
for vpn in /proc/sys/net/ipv4/conf/*; do echo 0 > $vpn/accept_redirects; echo 0 > $vpn/send_redirects; done iptables --table nat --append POSTROUTING --jump MASQUERADE |
There are better ways to do this (via sysctl.conf and ufw for example) but this is something that just works.
Configure Openswan (IPSEC)
Use your favorite editor to edit the following file:
|
1 2 |
/etc/ipsec.conf |
Below is the contents of mine. Most lines have a comment below it explaining what it does.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
config setup dumpdir=/var/run/pluto/ #in what directory should things started by setup (notably the Pluto daemon) be allowed to dump core? nat_traversal=yes #whether to accept/offer to support NAT (NAPT, also known as "IP Masqurade") workaround for IPsec virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v6:fd00::/8,%v6:fe80::/10 #contains the networks that are allowed as subnet= for the remote client. In other words, the address ranges that may live behind a NAT router through which a client connects. protostack=netkey #decide which protocol stack is going to be used. conn L2TP-PSK-NAT rightsubnet=vhost:%priv also=L2TP-PSK-noNAT conn L2TP-PSK-noNAT authby=secret #shared secret. Use rsasig for certificates. pfs=no #Disable pfs auto=add #start at boot keyingtries=3 #Only negotiate a conn. 3 times. ikelifetime=8h keylife=1h type=transport #because we use l2tp as tunnel protocol left=%SERVERIP% #fill in server IP above leftprotoport=17/1701 right=%any rightprotoport=17/%any |
The shared secret
The shared secret is defined in the /etc/ipsec.secrets file. Make sure it is long and random:
|
1 2 3 |
%SERVERIP% %any: PSK "69EA16F2C5DCED8B29E74A7D1B0FE99E69F6BDCD3E44" |
Verify
Now to make sure IPSEC works, execute the following command:
|
1 2 |
ipsec verify |
My output looks like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
Checking your system to see if IPsec got installed and started correctly: Version check and ipsec on-path [OK] Linux Openswan U2.6.37/K3.2.0-29-generic-pae (netkey) Checking for IPsec support in kernel [OK] SAref kernel support [N/A] NETKEY: Testing XFRM related proc values [OK] [OK] [OK] Checking that pluto is running [OK] Pluto listening for IKE on udp 500 [OK] Pluto listening for NAT-T on udp 4500 [OK] Two or more interfaces found, checking IP forwarding [OK] Checking NAT and MASQUERADEing [OK] Checking for 'ip' command [OK] Checking /bin/sh is not /bin/dash [WARNING] Checking for 'iptables' command [OK] Opportunistic Encryption Support [DISABLED] |
The /bin/sh and Opportunistic Encryption warnings can be ignored. The first one is a openswan bug and the second doesnt matter.
Configure xl2tpd
Use your favorite editor to edit the following file:
|
1 2 |
/etc/xl2tpd/xl2tpd.conf |
Below is the contents of mine. Most lines have a comment below it explaining what it does.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
[global] ipsec saref = yes [lns default] ip range = 172.16.1.30-172.16.1.100 local ip = 172.16.1.1 refuse pap = yes require authentication = yes ppp debug = yes pppoptfile = /etc/ppp/options.xl2tpd length bit = yes |
- ip range = range of IPs to give to the connecting clients
- local ip = IP of VPN server
- refuse pap = refure pap authentication
- ppp debug = yes when testing, no when in production
Local user (PAM//etc/passwd) authentication
To use local user accounts via pam (or /etc/passwd), and thus not having plain text user passwords in a text file you have to do a few extra steps. Huge thanks to Sascha Scandella for the hard work and troubleshooting.
In your /etc/xl2tpd/xl2tpd.conf add the following line:
|
1 2 |
unix authentication = yes |
and remove the following line:
|
1 2 |
refuse pap = yes |
In the file /etc/ppp/options.xl2tpd make sure you do not add the following line (below it states to add it, but not if you want to use UNIX authentication):
|
1 2 |
require-mschap-v2 |
Also in that file (/etc/ppp/options.xl2tpd) add the following extra line:
|
1 2 |
login |
Change /etc/pam.d/ppp to this:
|
1 2 3 4 5 |
auth required pam_nologin.so auth required pam_unix.so account required pam_unix.so session required pam_unix.so |
Add the following to /etc/ppp/pap-secrets:
|
1 2 |
* l2tpd "" * |
(And, skip the chap-secrets file below (adding users).)
Configuring PPP
Use your favorite editor to edit the following file:
|
1 2 |
/etc/ppp/options.xl2tpd |
Below is the contents of mine. Most lines have a comment below it explaining what it does.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
require-mschap-v2 ms-dns 8.8.8.8 ms-dns 8.8.4.4 auth mtu 1200 mru 1000 crtscts hide-password modem name l2tpd proxyarp lcp-echo-interval 30 lcp-echo-failure 4 |
- ms-dns = The dns to give to the client. I use googles public DNS.
- proxyarp = Add an entry to this systems ARP [Address Resolution Protocol] table with the IP address of the peer and the Ethernet address of this system. This will have the effect of making the peer appear to other systems to be on the local ethernet.
- name l2tpd = is used in the ppp authentication file.
Adding users
Every user should be defined in the /etc/ppp/chap-secrets file. Below is an example file.
|
1 2 3 4 5 |
# Secrets for authentication using CHAP # client server secret IP addresses alice l2tpd 0F92E5FC2414101EA * bob l2tpd DF98F09F74C06A2F * |
- client = username for the user
- server = the name we define in the ppp.options file for xl2tpd
- secret = password for the user
- IP Address = leave to * for any address or define addresses from were a user can login.
Testing it
To make sure everything has the newest config files restart openswan and xl2tpd:
/etc/init.d/ipsec restart;
/etc/init.d/xl2tpd restart;
On the client connect to the server IP address (or add a DNS name) with a valid user, password and the shared secret. Test if you have internet access and which IP you have (via for example http://whatsmyip.org. If it is the VPN servers IP then it works.
Another nice test is to connect multiple clients of which one has a webserver. Make sure it only listens on a VPN IP (172.16.1.xxx in above example). Test if you can access it only via the VPN. You now have a secret webserver.
If you experience problems make sure to check the client log files and the ubuntu /var/log/syslog file. If you google the error messages you most of the time get a good answer.
Sources
http://blog.riobard.com/2010/04/30/l2tp-over-ipsec-ubuntu http://www.cryptocracy.com/blog/2012/05/13/ipsec-slash-l2tp-vpn-server-with-ubuntu-precise http://rootmanager.com/ubuntu-ipsec-l2tp-windows-domain-auth/setting-up-openswan-xl2tpd-with-native-windows-clients-lucid.html
It would be nice if you could link to the Ubuntu 12.04 variant: https://raymii.org/s/tutorials/IPSEC_L2TP_vpn_with_Ubuntu_12.04.html and the CentOS / Red Hat 6 variant: https://raymii.org/s/tutorials/IPSEC_L2TP_vpn_on_CentOS_-_Red_Hat_Enterprise_Linux_or_Scientific_-_Linux_6.html
It is now available from here in the comment section 🙂
Thanks for the great tutorial.
i am trying to setup simplest ipsec. i checked my setting is ok using #ipsec verify and it says OK.
For simplest configuration i use ip xfrm to set up SA and SP using:
#HOST A:192.168.77.24
ip xfrm state add src 192.168.77.23 dst 192.168.77.24 proto esp spi 0x53fa0fdd mode transport reqid 16386 replay-window 32 auth “hmac(sha1)” 0x55f01ac07e15e437115dde0aedd18a822ba9f81e enc “cbc(aes)” 0x6aed4975adf006d65c76f63923a6265b sel src 0.0.0.0/0 dst 0.0.0.0/0
ip xfrm state add src 192.168.77.24 dst 192.168.77.23 proto esp spi 0x53fa0fdd mode transport reqid 16386 replay-window 32 auth “hmac(sha1)” 0x55f01ac07e15e437115dde0aedd18a822ba9f81e enc “cbc(aes)” 0x6aed4975adf006d65c76f63923a6265b sel src 0.0.0.0/0 dst 0.0.0.0/0
ip xfrm policy add dir out src 192.168.77.23 dst 192.168.77.24 ptype main action allow priority 2080 tmpl src 192.168.77.23 dst 192.168.77.24 proto esp reqid 16385 mode transport
ip xfrm policy add dir in src 192.168.77.24 dst 192.168.77.23 ptype main action allow priority 2080 tmpl src 192.168.77.24 dst 192.168.77.23 proto esp reqid 16385 mode transport
#HOST B:192.168.77.23
ip xfrm state add src 192.168.77.24 dst 192.168.77.23 proto esp spi 0x53fa0fdd mode transport reqid 16386 replay-window 32 auth “hmac(sha1)” 0x55f01ac07e15e437115dde0aedd18a822ba9f81e enc “cbc(aes)” 0x6aed4975adf006d65c76f63923a6265b sel src 0.0.0.0/0 dst 0.0.0.0/0
ip xfrm state add src 192.168.77.23 dst 192.168.77.24 proto esp spi 0x53fa0fdd mode transport reqid 16386 replay-window 32 auth “hmac(sha1)” 0x55f01ac07e15e437115dde0aedd18a822ba9f81e enc “cbc(aes)” 0x6aed4975adf006d65c76f63923a6265b sel src 0.0.0.0/0 dst 0.0.0.0/0
ip xfrm policy add dir out src 192.168.77.24 dst 192.168.77.23 ptype main action allow priority 2080 tmpl src 192.168.77.24 dst 192.168.77.23 proto esp reqid 16385 mode transport
ip xfrm policy add dir in src 192.168.77.23 dst 192.168.77.24 ptype main action allow priority 2080 tmpl src 192.168.77.23 dst 192.168.77.24 proto esp reqid 16385 mode transport
Host A is Linux Ubantu 12.04LTS.
I check setting SA and SP set using, #ip x s and #ip xfrm policy show. It shows correct setting of the SA and SP.
But when i ping it shows simple ICMP packet on wireshark where i expect packet should be ESP.
What that i miss, any clue will be helpful.
Thanks in advance.
Well, To give a correct answer would probably require some hands on and I do not have a setup like this at the moment.
I have some thought in the back of my head about reading something like this before but can’t remember exactly what it was about.
You are tapping in on the right interface with wireshark?
Do you get a reply on your ping/icmp?
If try some other type of traffic, like http between the two hosts, do you get the correct results?
Loads of questions in return. Get back to me and we can probably work something out.
I tried with http, it also has the same result no ESP protocol message when tabbed with wireshark. http communication is as usual.
Yes, I am tapping on the right interface using wireshark,
I get replay on the ping request.
As i am trying with ESP transport or even i use ESP tunneling, i think all type of traffic should get secured. but still i will give a try with http.