Android L2TP/IPSec VPN mini-howto

Roman Valls Guimerà bio photo By Roman Valls Guimerà Comment

I would have preferred that my Android 1.6 device supported OpenVPN out of the box. Unfortunately, this is only available for rooted devices and a bit of suffering. Instead, I went for configuring IPsec inside L2TP VPN server. All of it stuffed into an old and low-end Soekris net4511 board running Voyage Linux.

First, I will just redirect you to the well-documented, lengthy but primary resource:

Using a Linux L2TP/IPsec VPN server

On the client side, this post is quite complete:

Adding VPN connections to Android 1.6 (Donut)

If you’re feeling impatient and brave, perhaps you’ll succeed with the configuration files that follow (they worked for me)… since those are highly dependant on your network setup, YMMV, a lot.

Before jumping right into the meat and to avoid confusion, let’s see what is the game all these evil daemons are going to play:

  1. A client (my android phone), connects to the server on port 4500.
  2. IPsec server (OpenSWAN) responds and asks for the PSK.
  3. If the previous “gatekeeper” is ok with you, control is handed over L2TP, the other “tunnel keeper” who will ask for another password.
  4. If L2TP is satisfied with your answer, PPPD, the ancient UNIX beast will be waken up and ask for… your user and password !
  5. Congrats ! You’re survived the gates, now you’re on your home network from your smartphone, ain’t it cool ?

Prerequisites

I’m using Openswan for IPsec here since the debian packaging system states its preferences clearly:

freeswan - IPSEC utilities **transition** package to Openswan
openswan - IPSEC utilities for Openswan

On the L2TP part, I went for xl2tpd but is IMPORTANT that you use version 1.2.7 at least. Version 1.2.0 present on Debian Lenny did not work for me !

IPsec

Here is the configuration for “/etc/ipsec.conf”, where I use a group shared PSK:

`
nat_traversal=yes
nhelpers=0
conn L2TP-PSK
authby=secret

Do NOT enable PFS, my android 1.6 did not work with it

pfs=no
rekey=no
keyingtries=3
left=%defaultroute
leftprotoport=17/%any
right=%any
rightprotoport=17/%any
auto=add
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf
`

The secret (PSK) for the IPSec tunnel lays in the “/etc/ipsec.secrets” file, in a simple format:

<br /> 192.168.24.100 %any: PSK "your_PSK_here"<br /> 10.1.20.1 %any: PSK "your_PSK_here"<br />

If you don’t put the gateway IP’s you expect to use, IPsec logs will complain this way on “/var/log/auth.log” or in “/var/log/secure”:

packet from 10.1.20.29:500: initial Main Mode message received on 10.1.20.1:500 but no connection has been authorized

L2TP

First, do make sure that the module “pppol2tp” is loaded and present on “/etc/modules”, for it to survive reboots.

Now, the L2TP configuration (xl2tp.conf):

<br /> [lns default]<br /> ip range = 10.1.20.31-10.1.20.50<br /> ; hidden bit = no<br /> local ip = 10.1.20.30<br /> require chap = yes<br /> refuse pap = yes<br /> require authentication = yes<br /> name = yourhost<br /> ppp debug = yes<br /> pppoptfile = /etc/ppp/options<br /> length bit = yes<br />

Don’t forget to put the L2TP secrets (/etc/xl2tpd/l2tp-secrets):

`

host (us) username password

voyage anonymous another_password
`

I ran into another issue with “/var/run/xl2tpd/l2tp-control”, you’ll see in the logs clearly, but just make sure you “mkdir -p /var/run/xl2tpd”.

I find it quite funny that we’ve to pass through two “gatekeepers” who ask for passwords: IPsec PSK and now, L2TP password. We’ve another old beast to get through, and it’s name is: PPP !

PPP

I just used the daemon already installed on most distributions by default, the “ppp” package.

Nothing fancy to see here, just the “chap-secrets” file:

`

Secrets for authentication using CHAP

client server secret IP addresses

user1 * “yet_another_pass” 10.1.20.32
user2 * “and_another!!!” 10.1.20.33
`

Future improvements

First of all, PSK may be convenient for testing purposes, but I would recommed moving to PKI just after verifying that this setup works as expected.

The IP addresses where set manually for each client, but I’m sure you can scan through the original document and figure out a nicer DHCP/DNS interaction with your clients.

The default configuration/routing will redirect all your requests towards the tunnel, but perhaps you’re more interested on splitting the tunnel.

Good luck !

comments powered by Disqus