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:


192.168.24.100 %any: PSK "your_PSK_here"
10.1.20.1 %any: PSK "your_PSK_here"


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):


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


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 !

1. My swedish e-legitimation BankID software token.
2. My spanish digital certificate renewal request.

The first one failed to authenticate (silently!) because the (propietary) software, BankID, refused to work properly on 64-bit Ubuntu. Adding a wrapper solved the issue:


sudo apt-get install nspluginwrapper
sudo nspluginwrapper -i /usr/local/lib/personal/libplugins.so


On the other hand, the spanish counterpart, complained like this:

"Su certificado no ha permitido generar una firma válida"

Pasting the error on google sufficed to find the solution as well.

Now I wonder how our mums can cope with these big user annoyances :-S

Hopefully not everything is a lost cause here… openness and common sense in security seem to start making their way on Spain regarding DNIe: PKCS11 sources have been recently released !.

It seems that dovecot has a nice server-side mail compression plugin… how come there are no implementations of a session-based cyphering of mail storage based on this same principle ?

The use case is quite simple to imagine:

1. Mails keep coming to the MDA, on plain text, as usual.
2. User logs into the IMAP server with her credentials.
3. A keypair stored on user’s maildir, for instance, is unlocked using the login password.
4. New mails are cyphered and all subsequent read/write operations are performed through this (de)cyphering mechanism.
5. User logs out and the key is forgotten, shrinking the window of opportunity on possible sneakers or forensic forces.

EDIT: Of course, keeping just the public key on the server is way smarter in this case:

1. The user’s GnuPG public key is stored on her maildir.
2. All incoming emails are cyphered as they arrive with the previous public key.
3. The user logs in and sees all her mailbox cyphered, ready to be decyphered with his private key residing on her mail client.
4. Forensic analysis/spying on emails gets just a little bit harder .

He argued that just a quick UNIX pipework (using qmail) should be sufficient, but I rather preferred to keep the MTA out of the equation. The reason is that the MTA just “sinks” mail to the mailbox, while the MDA usually has both read and write access to emails, so to me it makes more sense to keep this “plugin” on the MDA side…

Is the idea clear at this point ? Is this already invented and passed under my radar ? Anyone has suggestions on top of that ?

But sometimes you find yourself reading on some foreign bit of info, like a swedish newspaper… sure, one can easily perform a full translation by just going to google translate, but supposing you’re learning how to use a new pipe, how can you translate that word and integrate it into your vocabulary without losing the focus on the piece of text you were reading on the first place ?

Firefox with greasemonkey together with Google Translator Tooltip, saves the day for me, I hope it’s useful to you as well

Hint: configure it as “detect language” and you have an anti-babel device in just one double click.

Summarizing from their official page, iGEM is about:

Using standard biological parts to build biological systems and operate them in living cells.

I’ve been tracking them since before joining KTH’s Computational Biology Masters degree. Having a quick look at past editions is both surprising and enlightening to see what they archieve year after year.

Perhaps the most rewarding sensation is being able to incrementally be aware of what they are talking about on their projects as I progress on my studies. Indeed, before joining the Masters I could barely understand the general idea, and got absolutely lost in the biological details. Now I can follow it after stepping on some stones that the master provided me.

Last year, together with Hassan, we based our final Biomodelling presentation on one project that matched the models we were studying on the course: Reaction diffusion systems.

Just a few weeks ago, while learning again how to stand up on a snowboard table on Romme, I had the great opportunity to talk with one of last year’s Uppsala Team advisor, Daniel, who not only enjoyed the experience, but together with his team, managed to contribute back some biobrick.

Today I would even like to try (dare?) and join one of those groups, just for the fun of learning how this amazing world actually works and to struggle with a real world problem.

And you ? What are you doing this summer ?