VPN server for remote clients using IKEv1 with L2TP

From Libreswan
Revision as of 01:18, 24 June 2016 by Paul Wouters (talk | contribs)
Jump to navigation Jump to search

Using IPsec/L2TP is a common deployment. Note that it is a dated solution that should be avoided when possible. Specifically, there are issues with multiple Transport Mode IPsec connections and NAT. Additionally, L2TP clients tend to be PSK based using Aggressive Mode, which is also an unwise choice from a security perspective. There will be two extra layers of packet encapsulation, a PPP layer and an L2TP layer. This can cause MTU issues, so usually the L2TP/IPsec client uses an MTU of 1200 for the ppp device that is created.

While we document how to run an L2TP/IPsec server, we do not recommend this type of setup.

If you place your L2TP/IPsec server behind NAT (such as on Amazon AWS) you will need to change Registry settings on Windows to allow it to connect to IPsec servers behind NAT

L2TP/IPsec based server

As this is the most widely supported IPsec configuration, almost every enduser device that supports IPsec, supports this setup.

Supported clients:

  • All Apple iphones, ipads
  • Mac OSX
  • Android
  • Linux with commandline
  • Microsoft Windows

The server has three components to configure: libreswan for IPsec, xl2tpd for L2TP and pppd for PPP.

IPsec server configuration

We are going to hand out IP address from the range 100.64.0.10/24 via PPP. So we need to exclude those addresses from being used by the remote endpoints as pre-NAT address. It is important to keep your address pool small and not a commonly used IP range like 10.0.0.0/24 to avoid collisions with pre-NAT IP addresses. We use something from the range 100.64.0.0/10 which is reserved for Carrier-grade NAT and should therefore never be visible on the internet, and unlike the traditional RFC-1918 address space is not commonly in use for local networks. 

config setup
    # needed when using PSK only. Not needed for X.509 based servers
    uniqueids=no
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:100.64.0.0/10,%v4:!100.64.0.0/24

conn ikev1
	authby=secret
	pfs=no
	auto=add
	rekey=no
	left=%defaultroute
	right=%any
	ikev2=never
	type=transport
	leftprotoport=17/1701
	rightprotoport=17/%any
	dpddelay=15
	dpdtimeout=30
	dpdaction=clear

conn ikev1-nat
	also=ikev1
	rightsubnet=vhost:%priv

And of course your PreSharedKey (PSK) in /etc/ipsec.secrets 

: PSK "strongrandomstring"

L2TP server

For the L2TP server, we use xl2tpd.

/etc/xl2tpd/xl2tpd.conf 

[global]
    listen-addr = YourPublicIP
    ipsec saref = no
    force userspace = no
    ; debug tunnel = yes

[lns default]
    ip range = 100.64.0.100-100.64.0.200
    local ip = 100.64.0.1
    require chap = yes
    refuse pap = yes
    require authentication = yes
    name = LinuxVPNserver
    ppp debug = yes
    pppoptfile = /etc/ppp/options.xl2tpd
    length bit = yes

Some xl2tpd versions are buggy when you leave out the ipsec saref setting even if you want it to be 'no'. The force userspace option is required to allow the kernel to decapsulate L2TP data packets so only L2TP control packets make it to userland's xl2tpd. This significantly increases performance.

The IP address from the pool is handed over to PPP.

PPP server configuration

This is done via the above pppoptfile, in our case /etc/ppp/options.xl2tpd 

ipcp-accept-local
ipcp-accept-remote
# use an internal server for DNS if you need to reach local-only zones or if
# you want DNS to be encrypted through the tunnel.
ms-dns  100.64.0.1
# ms-dns  8.8.8.8
# ms-dns  
noccp
auth
crtscts
idle 1800
# when having MTU issues, can be decreased to about 1200
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
Retrieved from "https://libreswan.org/wiki/index.php?title=VPN_server_for_remote_clients_using_IKEv1_with_L2TP&oldid=20777"