L2tp ipsec configuration using openswan and xl2tpd

Ariaan Bruinsma edited this page Jun 14, 2015 · 2 revisions

L2TPIPsec configuration using openswan and xl2tpd

To run an L2TP/IPsec server you need to configure a few compontents

  • openswan
  • xl2tpd
  • ppp
  • system networking and firewalling

This design assumes you are using NAT on the VPN gateway but of course this does not have to be the case if you connect to an office network where you want to access internal IP addresses. In that case, the corporate network should NAT you later on automatically. We are going to let xl2tpd manage the IP POOL, though you can have a pppd module (eg radius or ldap) handle that part if you wish. We will use PreSharedKeys, but you can of course also use X.509 certificates.

These configuration files come from “l2tp.nohats.ca” which lives at and will use to assign IPs on L2TP/IPsec tunnels to roadwarriors.

openswan configuration

You need to configure /etc/ipsec.secrets for the preshared key and /etc/ipsec.conf for the configuration of the tunnel

# /etc/ipsec.secrets %any PSK "test"
# /etc/ipsec.conf
version	2.0	# conforms to second version of ipsec.conf specification

config setup
        #protostack=mast  # used for SAref + MAST only

conn l2tp-psk
        # overlapip=yes   # for SAref + MAST
        # sareftrack=yes  # for SAref + MAST
        # The remote user.

xl2tpd configuration

All configurations for xl2tpd live in /etc/xl2tpd/xl2tpd.conf

; /etc/xl2tpd/xl2tpd.conf

; you cannot leave out listen-addr, causes possible wrong src ip on return packets
listen-addr = 
; ipsec saref = yes   ; For SAref + MAST only
; debug tunnel = yes

[lns default]
ip range =
local ip =
assign ip = yes
require chap = yes
refuse pap = yes
require authentication = yes
name = OpenswanVPN
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

ppp configuration

Set proper values for the options file used by pppd. Especially important is the smaller mtu/mru settings.
Below follows the /etc/ppp/options.xl2tpd file:

idle 1800
mtu 1200
mru 1200
connect-delay 5000

And the /etc/ppp/chap-secrets file. Note that you can assign from a pool (the /25 below) or give people a static IP. In this example the static ip is assigned from the range Note that this range is OUTSIDE the range specified in xl2tpd above. If you overlap, your static IP will also get assigned randomly by xl2tpd for the pool and would cause a conflict.

# /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client        server  secret     IP addresses
test            *       "test"
*               test    "test"
test2           *       "test"
*               test2   "test"
boss            *       "test"
*               boss    "test"

system configuration

Most important is /etc/sysctl.conf:

# /etc/sysct.conf
# only values specific for ipsec/l2tp functioning are shown here. merge with existing file
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1

I used no firewall rules except the NAT rule. You might want to tighten it down more

-bash-3.2# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
-bash-3.2# iptables -t nat -L -n
target prot opt source destination

target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

setsockopt recvref 22: Protocol not available

If you see this error, you might have an xl2tpd and openswan that are out of sync in trying to determine IPsec SAref tracking socket option number. The number 22 is the old value used. The new value is 30. The easiest solution is to upgrade to xl2tpd 1.3.1 which allows you to specify the number:

ipsec refinfo = 30

Then you can set it to 22 or 30, depending on your SAref kernel patch

Using SAref tracking and the MAST IPsec stack

With SArefs you can support overlapping IP assignments from behind different and the same NAT routers:

See: [http://www.openswan.org/docs/ipsecsaref.png IPsec SAref tracking]

If you are using an SAref kernel with the MAST stack, then check the above entries for the comments and enable those as well.
To see if you kernel supports SAref, run ipsec verify:

-bash-3.2# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                             	[OK]
Linux Openswan U2.6.35dr1/K2.6.35rc1 (klips)
Checking for IPsec support in kernel                        	[OK]
 KLIPS: checking for NAT Traversal support                  	[OK]
 KLIPS: checking for OCF crypto offload support             	[OK]
 Kernel: IPsec SAref kernel support                         	[OK]
 Kernel: IPsec SAref Bind kernel support                    	[OK]
Checking that pluto is running                              	[OK]
 Pluto listening for IKE on udp 500                         	[OK]
 Pluto listening for NAT-T on udp 4500                      	[OK]
Two or more interfaces found, checking IP forwarding        	[OK]
Checking NAT and MASQUERADEing                              
Checking for 'ip' command                                   	[OK]
Checking /bin/sh is not /bin/dash                           	[OK]
Checking for 'iptables' command                             	[OK]
Opportunistic Encryption Support                            	[DISABLED]

Note that both “ipsec policy” and “ipsec eroute” do not work for IPsec MAST in transport mode, as used here.
For now, you can check kernel state using:

cat /proc/net/ipsec/spi/all 
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.