Linux L2TP/IPsec VPN Server
A Virtual Private Network (VPN) is a way of using a secure network tunnel to carry all traffic between between different locations on the Internet - for example between your local office workstations and servers in your Crosspeer Account, or from your office workstations to your Crosspeer Cloud servers and then out into the internet from there.
In this tutorial, we’ll set up a VPN server using Openswan on Debian Linux. To do this, we’ll be using the Layer 2 Tunnelling Protocol (L2TP) in conjunction with IPsec, commonly referred to as an ‘L2TP/IPsec’ (pronounced “L2TP over IPsec”) VPN. For more information, see the L2TP/IPsec standard (RFC 3193).
Step 1: Initial setup
You’ll need to have Set up a Cloud Server running Linux. The steps in this tutorial assume that you are using Debian Linux, but should be similar for other
versions of Linux or BSDs if you have a preference. We recommend running all the commands below as root, or using sudo.
If you are looking to use the VPN to connect to several servers within the Crosspeer Cloud, make sure that the others are connected to the VPN server by a VLAN as described in our tutorial on VLANs. If you don’t intend to connect to other machines within your Crosspeer Account (for example, if you want to use the VPN for increased privacy while browsing), you won’t need the second server.
Finally, if you’re using a firewall such as iptables or the built-in Crosspeer firewall, you’ll need to make sure that UDP traffic is allowed to port 500 (IKE) and port 4500 (for IPsec Nat traversal).
For the purposes of this tutorial, we will give our VPN server an address of 10.0.5.1 on the VLAN, and connect a second server over the VLAN at 10.0.5.2.
If you are not using a VLAN, you can add an internal address to your server’s eth0 device as follows:
A Virtual Private Network (VPN) is a way of using a secure network tunnel to carry all traffic between between different locations on the Internet - for example between your local office workstations and servers in your Crosspeer Account, or from your office workstations to your Crosspeer Cloud servers and then out into the internet from there.
In this tutorial, we’ll set up a VPN server using Openswan on Debian Linux. To do this, we’ll be using the Layer 2 Tunnelling Protocol (L2TP) in conjunction with IPsec, commonly referred to as an ‘L2TP/IPsec’ (pronounced “L2TP over IPsec”) VPN. For more information, see the L2TP/IPsec standard (RFC 3193).
Step 1: Initial setup
You’ll need to have Set up a Cloud Server running Linux. The steps in this tutorial assume that you are using Debian Linux, but should be similar for other
versions of Linux or BSDs if you have a preference. We recommend running all the commands below as root, or using sudo.
If you are looking to use the VPN to connect to several servers within the Crosspeer Cloud, make sure that the others are connected to the VPN server by a VLAN as described in our tutorial on VLANs. If you don’t intend to connect to other machines within your Crosspeer Account (for example, if you want to use the VPN for increased privacy while browsing), you won’t need the second server.
Finally, if you’re using a firewall such as iptables or the built-in Crosspeer firewall, you’ll need to make sure that UDP traffic is allowed to port 500 (IKE) and port 4500 (for IPsec Nat traversal).
For the purposes of this tutorial, we will give our VPN server an address of 10.0.5.1 on the VLAN, and connect a second server over the VLAN at 10.0.5.2.
If you are not using a VLAN, you can add an internal address to your server’s eth0 device as follows:
$ nano /etc/network/interfaces
#These lines, or something similar to them, should already exist
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
#We need to add the lines below this one
auto eth0:1
iface eth0:1 inet static
address 10.0.5.1
netmask 255.255.255.0
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
#We need to add the lines below this one
auto eth0:1
iface eth0:1 inet static
address 10.0.5.1
netmask 255.255.255.0
Next, we need to enable IP forwarding. Using your text editor of choice, open your server’s sysctl configuration file:
$ nano /etc/sysctl.conf
This allows you to change several operating system parameters within Linux. We’re going to add three lines: the first enables IP forwarding, and is essential. The other two lines disable ICMP redirects: this is not essential but is highly recommended unless you believe they are specifically required.
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
Tell sysctl to re-read the configuration file to start using the new parameters.
$ sysctl -p /etc/sysctl.conf
Finally, we must install the packages we will be using -- the Openswan IPsec VPN, and xl2tpd, the Layer 2 Tunneling Protocol Daemon.
$ apt-get update
$ apt-get install openswan xl2tpd
$ apt-get install openswan xl2tpd
When installing Openswan, you will be asked whether you want to create an X.509 certificate. This tutorial will cover preshared key (PSK) authentication, so you can select No here: if you change your mind at any time you can reach this prompt again by running the command dpkg-reconfigure openswan.
It’s important to note that while PSK authentication is secure enough for most uses, this may leave servers vulnerable to ‘Man in the Middle’ (MitM) attacks, potentially allowing a malicious server to masquerade as the VPN gateway. While this is only possible if the attacker is in possession of the PSK, authentication with X.509 certificates or with RSA keypairs makes this type of attack significantly more difficult.
If you are planning to allow VPN clients to use the server’s internet connection, you may also wish to install the iptables-persistent package, as this will come in useful later.
It’s important to note that while PSK authentication is secure enough for most uses, this may leave servers vulnerable to ‘Man in the Middle’ (MitM) attacks, potentially allowing a malicious server to masquerade as the VPN gateway. While this is only possible if the attacker is in possession of the PSK, authentication with X.509 certificates or with RSA keypairs makes this type of attack significantly more difficult.
If you are planning to allow VPN clients to use the server’s internet connection, you may also wish to install the iptables-persistent package, as this will come in useful later.
$ apt-get install iptables-persistent
Step 2: IPsec Configuration
First, we’ll configure the IPsec part of our network: this will provide a secure channel for our L2TP-tunnelled data. We’ll start by editing the main Openswan configuration file as follows.
First, we’ll configure the IPsec part of our network: this will provide a secure channel for our L2TP-tunnelled data. We’ll start by editing the main Openswan configuration file as follows.
$ nano /etc/ipsec.conf
config setup
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
oe=off
protostack=netkey
conn L2TP-PSK
authby=secret
pfs=no
auto=add
keyingtries=3
rekey=yes
ikelifetime=8h
keylife=1h
type=transport
left=<Your server's public IP>
leftnexthop=%defaultroute
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
oe=off
protostack=netkey
conn L2TP-PSK
authby=secret
pfs=no
auto=add
keyingtries=3
rekey=yes
ikelifetime=8h
keylife=1h
type=transport
left=<Your server's public IP>
leftnexthop=%defaultroute
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
For more detailed information on these parameters, consult the Openswan manual page by typing man 5 ipsec.conf. Some important points, however:
• Openswan uses the terms left and right to describe servers as belonging to the left- or right-hand sides of a typical network diagram.
• That means that left here refers to the VPN server, and right refers to decrypted traffic being passed on by the server, either to an internal network
(the Crosspeer VLAN) or the public Internet if the server is being used as a proxy.
• The authby keyword selects the authentication type. Here we are using a shared secret (our preshared key) for ease of setup and compatibility with
clients on different operating systems. Other common options include %rsasigkey for RSA authentication, or %cert for X.509 certificate authentication.
The last step in this section is to configure our shared secret.
• Openswan uses the terms left and right to describe servers as belonging to the left- or right-hand sides of a typical network diagram.
• That means that left here refers to the VPN server, and right refers to decrypted traffic being passed on by the server, either to an internal network
(the Crosspeer VLAN) or the public Internet if the server is being used as a proxy.
• The authby keyword selects the authentication type. Here we are using a shared secret (our preshared key) for ease of setup and compatibility with
clients on different operating systems. Other common options include %rsasigkey for RSA authentication, or %cert for X.509 certificate authentication.
The last step in this section is to configure our shared secret.
$ nano /etc/ipsec.secrets
This file may already contain some data preconfigured: unless you’ve chosen to use another authentication method we won’t be using this, so delete or comment out any existing information in this file. In order to use PSK authentication, we’ll add the following:
%any : PSK “a-secure-psk”
This breaks down as follows:
• In Openswan’s terminology, this is the left IP.
• %any - This field allows us to specify who can connect to the VPN using this shared secret. The wildcard %any means “any IP address”
but can be replaced by a space separated list of IPs or IP ranges.
• PSK - Here we specify the key. Remember that this is a password, and should follow your normal rules on password strength.
You can add several lines following this format if you wish, allowing you to use different PSKs depending on source IP. Once you’ve completed this, we can move on to the next step.
• In Openswan’s terminology, this is the left IP.
• %any - This field allows us to specify who can connect to the VPN using this shared secret. The wildcard %any means “any IP address”
but can be replaced by a space separated list of IPs or IP ranges.
• PSK - Here we specify the key. Remember that this is a password, and should follow your normal rules on password strength.
You can add several lines following this format if you wish, allowing you to use different PSKs depending on source IP. Once you’ve completed this, we can move on to the next step.
Step 3: Configure L2TP
Next we configure xl2tpd, the L2TP server daemon.
Next we configure xl2tpd, the L2TP server daemon.
$ nano /etc/xl2tpd/xl2tpd.conf
[global]
ipsec saref = yes
listen-addr = <Your server's public IP>
[lns default]
ip range = 10.0.5.50-10.0.5.255
local ip = 10.0.5.1
refuse chap = yes
refuse pap = yes
require authentication = yes
name=elastichosts-vpn-server
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
ipsec saref = yes
listen-addr = <Your server's public IP>
[lns default]
ip range = 10.0.5.50-10.0.5.255
local ip = 10.0.5.1
refuse chap = yes
refuse pap = yes
require authentication = yes
name=elastichosts-vpn-server
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
• ms-dns - Some clients will request DNS settings from the server when connected over the VPN. Here, we are simply using public DNS
provided by Google and Level3.
• proxyarp - Proxy ARP is required to rewrite the source hardware address and prevent traffic being dropped for coming from an invalid location.
Finally, the CHAP secret for PPP authentication.
provided by Google and Level3.
• proxyarp - Proxy ARP is required to rewrite the source hardware address and prevent traffic being dropped for coming from an invalid location.
Finally, the CHAP secret for PPP authentication.
$ nano /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client server secret
IP addresses
* crosspeer-vpn-server a-secure-chap-secret
*
# client server secret
IP addresses
* crosspeer-vpn-server a-secure-chap-secret
*
Again, you can specify several lines following this format, in order to provide different secrets for different users.
• client - This allows you to set a username to go with the CHAP secret. Here, we use the wildcard * to allow any username.
• server - The name of the server. We specified this in /etc/xl2tpd/xl2tpd.conf above.
• secret - The CHAP secret itself. Again, this is a password and should follow good practice for password strength.
• IP addresses - An IP address or range of addresses that will be used to allocate an address to any user who connects using this CHAP secret. This
should be a subset of the range specified above: here we have used * once again, meaning the server should allocate addresses from the whole range.
This nearly completes our tutorial - if you would like to make this server’s Internet connection available for remote clients to use a proxy, you must follow
one more step. If you are simply aiming to use your IPsec VPN to connect remote users to servers within a Crosspeer Cloud VLAN, you can skip to the
final step: Start Openswan.
• client - This allows you to set a username to go with the CHAP secret. Here, we use the wildcard * to allow any username.
• server - The name of the server. We specified this in /etc/xl2tpd/xl2tpd.conf above.
• secret - The CHAP secret itself. Again, this is a password and should follow good practice for password strength.
• IP addresses - An IP address or range of addresses that will be used to allocate an address to any user who connects using this CHAP secret. This
should be a subset of the range specified above: here we have used * once again, meaning the server should allocate addresses from the whole range.
This nearly completes our tutorial - if you would like to make this server’s Internet connection available for remote clients to use a proxy, you must follow
one more step. If you are simply aiming to use your IPsec VPN to connect remote users to servers within a Crosspeer Cloud VLAN, you can skip to the
final step: Start Openswan.
Step 4 (Optional): Enable NAT for Remote Clients
In order for remote users to connect to the public Internet through this VPN server, the gateway must be configured to perform Network Address Translation (NAT) for remote clients. To do that, we will use Linux’s built-in iptables firewall: the following command tells it to perform NAT for the IP range 10.0.5.0/24.
In order for remote users to connect to the public Internet through this VPN server, the gateway must be configured to perform Network Address Translation (NAT) for remote clients. To do that, we will use Linux’s built-in iptables firewall: the following command tells it to perform NAT for the IP range 10.0.5.0/24.
$ iptables -t nat -A POSTROUTING -o eth0 -s 10.0.5.0/24 -j MASQUERADE
You may recall that we installed the package iptables-persistent during the first step. This provides a simple method of ensuring that the firewall rules we create will be loaded when the server boots. To save the firewall rules, run:
$ iptables-save > /etc/iptables/rules.v4
Remote users can now set a default route through this server in order to securely access the internet through the VPN.
Step 5: Start Openswan
All we need to do now is start Openswan and xl2tpd. On Debian, we can do this as follows:
Step 5: Start Openswan
All we need to do now is start Openswan and xl2tpd. On Debian, we can do this as follows:
$ /etc/init.d/ipsec start
$ /etc/init.d/xl2tpd start
$ /etc/init.d/xl2tpd start
To make Openswan and xl2tpd start automatically on boot, simply run the following two commands.
$ update-rc.d ipsec defaults
$ update-rc.d xl2tpd defaults
$ update-rc.d xl2tpd defaults
