With the amount of insecure wifi networks all around it’s tempting just to use them for Internet access – right?
Doing so opens up a nasty way of messing with your data – getting to know what sites you visit, and also access to all transmitted data, sent in clear.
One solution – IPsec+L2TP
A way to use the insecure net, but still be safe is to tunnel all traffic to a server under your own control.
On both Android and iOS based phones you can connect to VPN, but the problem is: it’s IPsec + L2TP – not plain IPsec, and this is where the trouble starts.
There’s some pretty useful guides around the net, which have inspired me greatly – will try to find the links again and post them here to give proper credit (they deserve it).
1. link to get some usefull info http://www.jacco2.dds.nl/networking/openswan-l2tp.html
Setting up openswan
Wait – what is openswan? In short it’s an IKE responsible of setting up the IPsec part of your connection.
Here we’ll use a PSK setup – later I’ll make a solution using PKI with x509 certificates.
Simple openswan (version 2.6.26 on kernel 2.6.35-24-server) config, based on the default config (removed comments to make it easier to read here)
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,%v4:!172.30.0.0/24 oe=off protostack=netkey nhelpers=0 force_keepalive=yes keep_alive=500 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 type=transport left=YourIPAddress leftnexthop=%defaultroute leftprotoport=17/1701 right=%any rightprotoport=17/%any forceencaps=yes
What does the config mean?
Line 1-8 : just general stuff, where I define which internal network I use – 172.30.0.0/24, and which networks openswan should apply nat rules to.
10-12 : enable nat traversal, and include the new
14-26 : this is the fun part – just commenting some of the lines, the rest should be easy to understand 🙂
15: we’re using PSK for authentication
23+25: we want to ensure l2tp (udp port 1701) is encrypted
MYIP %any: "some-preshared-key"
Open up your firewall on udp port 500 and 4500 + protocol esp.
With this tested you should be able to bring up IPsec (but nothing else)
Now we have Ipsec running, it’s time to go into the fun world of l2tp – fun or painfull depending on who and when you ask …
The version of xl2tpd I’m currently using is 1.2.7+dfsg-1 (1.2.6 was bugged on my system).
[global] ipsec saref = yes [lns default] exclusive = no ip range = 172.30.0.40-172.30.0.60 local ip = 172.30.0.2 unix authentication = yes require authentication = yes name = l2tp pppoptfile = /etc/ppp/options.xl2tpd length bit = yes
This config opens up for a setup where you use pam for auth
asyncmap 0 nodefaultroute noipx auth idle 1800 mtu 1280 mru 1280 debug lock proxyarp name home lcp-echo-interval 30 lcp-echo-failure 4 ms-dns 172.30.0.1 nodetach ipcp-accept-local ipcp-accept-remote idle 1800 crtscts noccp
echo '* l2tp "" *' >> /etc/ppp/pap-secrets
Allows authentication for system users
When the configs are in place – restart xl2tpd and connect with your phone 🙂
You wrote “and more?”
Yes I did – this setup is also compatible with the built-in VPN on OS X, and might also work on Windows, though I don’t have one to test from.
The places to log for stuff is in /var/log/auth.log, /var/log/debug and /var/log/syslog