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:
- A client (my android phone), connects to the server on port 4500.
- IPsec server (OpenSWAN) responds and asks for the PSK.
- If the previous “gatekeeper” is ok with you, control is handed over L2TP, the other “tunnel keeper” who will ask for another password.
- If L2TP is satisfied with your answer, PPPD, the ancient UNIX beast will be waken up and ask for… your user and password !
- 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 !