Having an L2TP/IPSEC VPN comes in very handy if you have a Macbook, iOS device, or run Stock Android and want to be able to remotely access your network from on the road. L2TP over IPSEC is a better choice than PPTP which is now considered insecure. Plus L2TP/IPSEC is supported natively by those devices, so no additional client software would be needed unlike OpenVPN.
To get started, let’s imagine a small network that runs on a fairly standard private address range. 192.168.1.0/24. This setup would be run on an internal Ubuntu Server that is networked to the internal network you wish to access. In this example, you only need 1 network card.
Since the server resides on the internal network behind a router or firewall, you will need to forward certain ports to the server from your perimeter device for this to work.
You need to forward
ESP Traffic (protocol 50)
AH Traffic (protocol 51)
ESP and AH are not ports, they are protocols. Most comsumer routers can’t forward these protocols, so you may be forced to use a “Forward All traffic” option to the internal server or use a “Internal DMZ Host” setup that can be found on many device. Test it out and find the best option that works for you.
sudo aptitude install openswan
Openswan is the package that provides the IPSEC functionality. You can use it for site to site VPNs using Preshared Keys, certificates, or other back-end auth mechanisms. In this setup, I’ll keep it simple and just use a Pre-Shared Key (PSK). A PSK with id and password would be good enough for most people who want to securely access a small or home network.
Edit the file /etc/ipsec.conf so that it looks like this
SANITY CHECK: Make sure you keep the spacing intact under the config headers and conn headers. You might get format errors without it…
version 2.0 config setup dumpdir=/var/run/pluto/ 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 keep_alive=10 include /etc/ipsec.d/*.conf
Edit the /etc/ipsec.secrets file and add in the following to the bottom of the file:
Now lets setup the files that define the Connection.
Create/edit a file and call it /etc/ipsec.d/road-warrior.conf
conn L2TP-PSK-noNAT authby=secret pfs=no auto=add keyingtries=3 rekey=no ikelifetime=8h keylife=1h type=transport left=IP.ADDRESS.OF.SERVER leftprotoport=17/1701 right=%any rightprotoport=17/%any conn L2TP-PSK-NAT rightsubnet=vhost:%priv also=L2TP-PSK-noNAT
Next, Create/edit a file called /etc/ipsec.d/road-warrior.secrets
IP.ADDRESS.OF.SERVER %any: PSK "YourPreSharedKey"
Next, for OPENSWAN to function correctly, you need to run to following at the bash prompt:
for each in /proc/sys/net/ipv4/conf/* do echo 0 > $each/accept_redirects echo 0 > $each/send_redirects done echo 1 > /proc/sys/net/ipv4/ip_forward
To verify the OPENSWAN config use the IPSEC VERIFY command. Your output should match the output below.
root@opk-dfw-vpn01:/etc/ipsec.d# ipsec verify 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-51-virtual (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] Checking for 'ip' command [OK] Checking /bin/sh is not /bin/dash [WARNING] Checking for 'iptables' command [OK] Opportunistic Encryption Support [DISABLED]
Lastly, restart the IPSEC service
Next up we need to install an L2TP package. L2TP works with IPSEC in that L2TP provides the Tunnel, where IPSEC provides the encryption.
Install the L2TP package:
sudo aptitude install xl2tpd
Edit the /etc/xl2tpd/xl2tpd.conf
[global] ipsec saref = yes [lns default] ip range = 10.10.10.2-10.10.10.200 local ip = 10.10.10.1 refuse chap = yes refuse pap = yes require authentication = yes ppp debug = yes pppoptfile = /etc/ppp/options.xl2tpd length bit = yes
The IP range is used by the L2tp Tunnel. You want to be sure that this range does not overlap with any internal network subnet. The Server IP address should not be part of the ip range.
The final piece of this setup is the user authentication. Every user can share a PreSharedKey, but each user should have a unique ID/PW.
sudo aptitude install ppp
require-mschap-v2 ms-dns 188.8.131.52 ms-dns 184.108.40.206 asyncmap 0 auth crtscts lock hide-password modem debug name l2tpd proxyarp lcp-echo-interval 30 lcp-echo-failure 4
Change the DNS servers to fit your needs. These servers are public, but you could just as easily use your private DNS in there as well.
Now add users by editing /etc/ppp/chap-secrets
# Secrets for authentication using CHAP # client server secret IP addresses user1 l2tpd user1password * user2 l2tpd user2password * sudo /etc/init.d/xl2tpd restart
Now setup your remote device with the proper servername, PSK, and id/pw and give it a test.
Final Note, if your OpenSwan doesn’t startup correctly after a reboot, you probably need to add the following to run on startup:
Edit /etc/rc.local to contain:
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
If you run into trouble:
- Look at the logs. “tail -f /var/log/syslog /var/log/auth.log” These will give you a lot of insight.
- Double check that the ports are forwarded. The logs would show an inbound connection of some kind if the ports are open.
- Double check the PSK matches on client and server
- From logsd, Server Sends MR2 and waits for MI3 forever indicated ports are partially open, check the perimeter device.
- The Command IPSEC whack –status” gives you a lot if instant info on the configuration. Plus it’s nice output to GREP for other scripts.
Finally, here are some little facts that threw me for a loop the first time I played with openswan and I wished someone would have pointed out to me when I started:
- in the road-warrior.conf file, Right and Left simply differentiate the 2 sides of the VPN. You could switch the values for left and right without any issues. There is no difference.
- Traffic leaving the OpenSwan server into the internal network will masquerade as the Server’s IP. All VPN traffic will look like it originates from the Server if you take a packet capture from any internal target.
- You can have many *.conf files and *.secrets files as needed. You can mix Road Warrior confs with Site to site confs on the same host. Each with it’s own secrets file. No problem.