How-To: Set up a L2TP over IPSec VPN using a Radius backend

3 minute read

Even though I pretty like OpenVPN, there is still some devices that might not support the TUN/TAP driver needed by OpenVPN.

Take IPhones, Android phones for instance, you need to root them in order to get that feature, assuming somebody has already cooked a ROM for your device.

L2TP is quite and old standard that allow setting up VPNs.

On the other end, it does not provide any kind of encryption mechanism, and as such, it is pretty common to get L2TP running over an IPSec link.


In this tutorial, we are going to set up this kind of VPN. First IPSec will create an encrypted link, then L2TP will create a VPN link.

We are going to use a Pre-Shared Key (or PSK) for IPsec.

L2TP will use PAP as an authentication mechanism.

Why PAP? Because that allow us to store encrypted password instead of plain text one. Some might say that the password will go over the wire unencrypted, but here we have IPSec taking care of not letting our password be seeing by others.

This tutorial was done on Debian Lenny and Windows XP SP3 connected to the service successfully. Android 2.2 client also connected successfully.

Windows mobiles would fail to authenticated as PAP is not supported on the client :s !

So let get started with IPSec.


Packages requirements

We are going to use OpenSwan to handle IPSec. On Debian, you can install it with:

# apt-get install openswan

If you are asked questions, just answer the default.

IPSec Configuration

We are going to use the example from /etc/ipsec.d/examples/l2tp-psk.conf and copy the following below # Add connections here in /etc/ipsec.conf.

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # plutodebug / klipsdebug = "all", "none" or a combation from below:
        # "raw crypt parsing emitting control klips pfkey natt x509 private"
        # eg: plutodebug="control parsing"
        # ONLY enable plutodebug=all or klipsdebug=all if you are a developer !!
        # NAT-TRAVERSAL support, see README.NAT-Traversal
        # If we consider that we have an internal interface on subnet, 
        # we need to had here we had %v4:!
        # enable this if you see "failed to find any available worker"

# Add connections here

  # Configuration for one user with any type of IPsec/L2TP client
  # including the updated Windows 2000/XP (MS KB Q818043), but
  # excluding the non-updated Windows 2000/XP.
  # Use a Preshared Key. Disable Perfect Forward Secrecy.
  # PreSharedSecret needs to be specified in /etc/ipsec.secrets as
  # YourIPAddress  %any: "sharedsecret"
  # we cannot rekey for %any, let client rekey
  # or you can use: left=YourIPAddress
  # leftnexthop=YourGatewayIPAddress
  # For updated Windows 2000/XP clients,
  # to support old clients as well, use leftprotoport=17/%any
  # The remote user.
  # Using the magic port of "0" means "any one single port". This is
  # a work around required for Apple OSX clients that use a randomly
  # high port, but propose "0" instead of their port.

# sample VPN connections, see /etc/ipsec.d/examples/

Now we set our preshared key in /etc/ipsec.secrets with the format given in the configuration:

YourIPAddress  %any: PSK "sharedsecret"

And that should be it for the IPsec part. Now you can restart IPSec:

# /etc/init.d/ipsec restart

You might want to check the output of:

# ipsec auto --status

to troubleshoot potential issues.


If you have a firewall set up, you can use those settings to allow ipsec:

-A INPUT -i eth0 -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -i eth0 -p esp -j ACCEPT

Well, assuming IPsec part is fine, let go to the xl2tp part now.