ProL2TP L2TP/IPSec VPN Server Appliance Administrators Guide

This document is for Amazon AWS administrators.

Introduction

The AWS EC2 appliance is a 64-bit Intel appliance based on Ubuntu 20.04 that you can launch on your AWS EC2/VPC. The appliance is a minimal Ubuntu system, with only required software packages installed.

License keys are not required for instance activation. Charges will be automatically billed to your Amazon AWS account. Charges consist of software license costs for the tiered instances, and the cost of running the instance on AWS EC2 itself. The prices are visible on the appliance product pages of Amazon AWS Marketplace.

Overview

Setting up a ProL2TP L2TP/IPSec VPN Server Appliance instance involves several steps:

Launch the instance.
Run the appliance setup script.
If not using an external RADIUS server to authenticate users, add VPN user accounts using the provided CLI tools.
Setup static routes in your AWS network to route traffic through the appliance to/from nodes in your private network.
Disable AWS source and destination address checking.
Assign an Elastic IP to the instance and configure a DNS entry for it.
Test the appliance, verifying that test clients can connect and access resources in the private network.
Distribute access instructions to each VPN user. This will include their username and password, and either the IPSec Pre-Shared-Key or IPSec client certificate. We provide some instructions for configuring common L2TP/IPSec clients in our User Guide.

Once provisioned, maintenance tasks should be minimal. VPN users may be added or removed at any time.

Limitations

We don't want you to install and configure the appliance only to find that it doesn't provide a feature that you require. The ProL2TP L2TP/IPSec VPN Appliance has the following limitations:

There is no web UI. Configuration is done when the appliance is provisioned. To view system state, such as a list of users currently connected or debug logs, an administrator would use CLI tools and an SSH login.
The appliance setup cannot be fully automated because it requires some AWS network configuration which will be specific to the AWS VPC in which the appliance instance is run. Some technical knowledge of AWS VPC network configuration will be required.
In this version, VPN users cannot be authenticated using LDAP or Active Directory. The VPN user database is stored either on an external RADIUS server or on the appliance itself.
VPN client users may need to configure local IP routing to route specific traffic over the VPN when connected. Most VPN clients allow routes to be configured.
In this version, the appliance configuration utility does not support IPv6.

Amazon VPC Setup

The VPN appliance must be provisioned in a public subnet of your VPC. It has a single network interface with a private IP address. All traffic from VPN clients will be NATed internally such that it appears to come from the appliance. If VPN clients need to access systems in your VPC, the VPC network configuration must allow traffic from the VPN appliance's private IP.

Any traffic from connected VPN clients which is destined outside the VPC will be NATed again by the Amazon VPC router.

Instance Launch Options

When launching a ProL2TP VPN appliance, you will specify several parameters:

Parameter	Use
Version	The default should launch the latest version available on Amazon Marketplace. It is strongly recommended that you always run the latest version of the software to ensure that security and stability fixes are in place.
Region	Select the region you would like to launch your instance in. The default is US East (N. Virginia).
AWS EC2 Instance Type	Select the instance type you would like to use for your newly launched instance. The Micro or Small instances should be appropriate for most small workloads, however, you may want to change the instance type to a higher tier if a higher demand is to be expected. You may change the instance type at any time.
VPC Settings	Select the VPC network or AWS EC2 network in which you would like to launch the instance.
Security Group	Select the security group you would like to use for this instance. The appliance is automatically associated with a predefined security group which opens the following ports: TCP 22 (SSH), UDP 500 (ISAKMP), UDP 4500 (IPSec NAT Traversal). Note that L2TP (UDP port 1701) should not be enabled since all L2TP traffic is encapsulated by IPSec.

After verifying the instance pricing details, initiate the launching process. You should then be able to access the instance on the AWS EC2 console.

Assign an elastic IP and setup DNS

Amazon assigns public IP addresses from an address pool. If the instance is stopped, it will usually be assigned a different public address the next time it is started. In order to configure a DNS entry to point to the VPN server appliance, its public IP address must first be fixed. This is done by assigning an Elastic IP to the instance. To do so, visit the Elastic IPs section in the left navigation panel.

Once an Elastic IP is assigned to the instance, add a DNS entry to point your server's fully qualified domain name (FQDN) at that IP.

Running the ProL2TP VPN Server setup script

A simple setup script, configure-vpn-server.sh prepares the VPN appliance for use. While we have preconfigured as much as possible, some configuration details are needed at install time. Our setup script is a script that can be run from an SSH session to configure the instance.

The script asks for the following information:

Network interface name of the instance. Usually eth0.
Private IPv4 address of the instance.
VPN client IP address pool. This is specified in CIDR notation, e.g. 172.26.0.0/16, which defines a pool of addresses from 172.26.0.1 to 172.26.255.254. Choose an IP address range with sufficient addresses for the expected number of connected clients. It doesn't matter if this address pool is larger than the maximum number of clients. It is, however, important that the range is dedicated for use by VPN clients; any address in the range must not be used elsewhere in the VPC.
VPN connection MTU. The default value (1460) works best in most cases because it avoids IP fragmentation across the VPN link in most networks while maximising packet size. VPN clients may negotiate a smaller MTU during connection setup.
VPN server IPSec certificate location country code, e.g. 'US'. IPSec certificates require a country code. For a list of country codes, see https://www.ssl.com/country-codes/
VPN server IPSec certificate domain. This should be the fully qualified domain name of your server, e.g. vpn.example.com.
Number of VPN IPSec client certificates to generate. For best security, create a certificate for each VPN user. It may take several minutes to create hundreds of certificates but this needs to be done only once.
VPN server name. This is a short name which is used only in IPSec certificates generated by the appliance. The name may appear if a user displays information about their installed IPSec client certificates. The default value (ProL2TP) will result in client certificates with the name ProL2TP VPN client associated. Choose a short name that would identify the certificate source here.
VPN server ID. This is an internal name that identifies the server during IPSec connection setup. Some clients may use this to choose which certificate to use if they are configured to connect to multiple servers. If you have more than one appliance, it is best to use a different ID for each appliance. The default value is vpnserver1.
IPSec certificate key size. This can be 1024, 2048, 3072 or 4096. Larger certificates are more secure but are more CPU intensive and may not be supported by older clients.
IPSec pre-shared key (PSK). Rather than distribute IPSec certificates to each VPN user, you can instead just give them a PSK (password) to grant access. This is not recommended because it is less secure than certificate-based authentication. It is a single point of failure -- if the PSK is compromised, you will need to reconfigure the appliance with a new PSK and tell all of your users to change their settings to use the new PSK. If you distribute a client certificate to each VPN user and that certificate is compromised, individual client certificates can be disabled without impacting other users.
External RADIUS server IP address, if VPN users will be authenticated using an external RADIUS server.
RADIUS secret configured at the external RADIUS server for requests from the VPN appliance.

Here is an example setup script run:

# configure-vpn-server.sh
============================================================================
ProL2TP L2TP/IPSec VPN Applicance configure utility
============================================================================

This utility writes config files for ProL2TP, IPSec, RADIUS and
prepares IPSec certificates.

External network interface name: enp0s8
External IPv4 address: 172.27.0.9
IPv4 VPN client address pool CIDR: 172.26.0.0/16
VPN connection MTU: 1460
VPN server IPSec certificate location country code: GB
VPN server IPSec certificate domain: vpn.example.com
VPN server name: ProL2TP
VPN server ID: vpnserver1
Number of VPN client certificates to generate: 2
IPSec certificate key size (1024|2048|3072|4096): 2048
Allow VPN client authentication by IPSec PSK? (y/n): y
IPSec PSK: vpn.example.comssupersecretpsk
Authenticate VPN users using an external RADIUS server? (y/n): n

Creating IPSec certificates... done
Configuring IPSec...
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
Configuring local RADIUS server/proxy...
Synchronizing state of freeradius.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable freeradius
Created symlink /etc/systemd/system/multi-user.target.wants/freeradius.service → /lib/systemd/system/freeradius.service.
Configuring L2TP server...
Created symlink /etc/systemd/system/multi-user.target.wants/l2tp-nfqd.service → /usr/local/lib/systemd/system/l2tp-nfqd.service.
Done
============================================================================
Configuration complete.

Please copy /opt/prol2tp/prol2tp-vpn-client-certs-vpn.example.com.tar.gz
off the appliance. This contains your client certificates. One of these
certificates should be delivered to each of your VPN users to enable access.
In order to install a certificate on a client machine, users will need your
certificate import password (eic9phuseiFayuoZ).
If you prefer not to use certificates, give your users your PreSharedKey PSK
(vpn.example.comssupersecretpsk). Please note that using a PSK is not recommended since
it is less secure than certificates.

Please register an account at https://prol2tp.com/register for access
to ProL2TP product documentation and support.
============================================================================

After running the setup script, copy the generated client certificates off the appliance and keep them somewhere safe, ready to distribute to your VPN users.

scp -i /path/to/ec2-instance-key.pem 1.1.1.1:/opt/prol2tp/prol2tp-vpn-client-certs.tar.gz /tmp
rm /opt/prol2tp/prol2tp-vpn-client-certs.tar.gz

where 1.1.1.1 is replaced by your instance's public IP.

Adding and Removing VPN users

If you aren't using an external RADIUS server to authenticate your VPN users, you must add username/password configuration on the appliance. We provide some simple scripts to assist with this:

add-vpn-user <user> <password>
change-vpn-user <user> <password>
del-vpn-user <user>
add-vpn-users [/path/to/user/file]
show-vpn-users

These scripts must be run on the appliance, since they modify local configuration files.

Use add-vpn-user to add users one at a time. Make a note of the password because you'll need to give it to your VPN user, along with their IPSec certificate or PSK later.

If you're adding lots of VPN users, use add-vpn-users. This takes a list of usernames and passwords from the filename given as a parameter, or from stdin. Each username/password must be on a separate line in the file, with the username and password values space-separated, e.g.

add-vpn-users <<EOF
jon.doe@example.com mysupersecret
bob bobspassword
EOF

If you use a file, copy it off the appliance when you're finished. It is strongly recommended to not store the file on the appliance since it is a security risk.

Finally, give each VPN user information about how to access the VPN:

Public IP address or DNS name of the VPN appliance.
IPSec client certificate and its import password, if used. The import password is used only to protect the certificate. Its value is stored in client certificate tarball that you previously copied from the appliance.
IPSec PSK, if not using client certificates.
VPN username and password.
Static routes to install on client system when connected to the VPN, if any.

You can use change-vpn-user to modify an existing user's password, and del-vpn-user to remove a VPN user.

Setup static routes

In order to allow a VPN client to access internal servers of your VPC, you may need to configure static routes and security group settings. All VPN traffic will appear to be sourced by the VPN appliance's private IP and replies will be sent back via the appliance. For more information, see this document on Amazon AWS VPC routing: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html

Disable Source Destination Checking

Since the VPN appliance NATs traffic to/from VPN clients to the appliance's private IP, you will need to disable source destination check protection on Amazon, otherwise routing will not function properly. To do this, right click on the VPN instance, select Change Source/Dest. Check and make sure the status is Disabled. This setting must also be used if for for example want traffic from your VPC to go directly to the IP addresses of your VPN clients in the VPN client subnet or this security feature will block the traffic.

Testing

After configuring the appliance, test that VPN clients can connect and that they can communicate with systems in the private network. We offer the following recommendations:

Check that a VPN test client can connect. Test all client types that you use, e.g. Windows, MAC, Linux, Android, iOS.
Ping the VPN appliance from a connected VPN test client.
Ping systems in the private network which are behind the VPN appliance in your private network. If the ICMP protocol is filtered by firewalls in the private network, use another protocol to verify connectivity, e.g. HTTP.

If the VPN client is unable to connect, check that it is correctly configured. If using IPSec client certificates, check that the certificate is installed on the client. If using IPSec Pre-Shared-Key (PSK), check that the PSK value is correct.

If the VPN client is unable to ping the VPN appliance, check that it is assigned an IP address in the expected range. The IP address range used by VPN clients must be unique in the customer network. Use prol2tp show sessions on the appliance to view status of connected users.

If the connected VPN client cannot reach systems behind the appliance, check IP routing in the private network. Use tools such as traceroute to debug the problem. Check that static routes are correctly configured in the AWS VPC.

Updating

From the time we have generated the appliance and the time you have downloaded and are using the appliance, operating system updates might have become available. To make sure your appliance operating system is up to date, execute the following commands:

sudo apt-get update
sudo apt-get upgrade

Monitoring

To obtain a list of users currently connected:

root@vpnsrv:~# prol2tp show sessions
       TunId     SessId TunName SessName   Type State      Time Identifier
N      31994      49289       -        -    PPP    UP  00:08:39 test
N      61580      52833       -        -    PPP    UP  00:20:06 test2

To see a list of all open connections, use conntrack:

root@vpnsrv:~# conntrack -L
tcp      6 25 TIME_WAIT src=172.26.0.14 dst=216.58.204.227 sport=37760 dport=443 src=216.58.204.227 dst=172.27.95.219 sport=443 dport=37760 [ASSURED] mark=0 use=1
tcp      6 2 TIME_WAIT src=172.26.0.14 dst=216.58.204.238 sport=45523 dport=443 src=216.58.204.238 dst=172.27.95.219 sport=443 dport=45523 [ASSURED] mark=0 use=1
tcp      6 2 TIME_WAIT src=172.26.0.14 dst=172.217.169.46 sport=43679 dport=443 src=172.217.169.46 dst=172.27.95.219 sport=443 dport=43679 [ASSURED] mark=0 use=1
tcp      6 103 TIME_WAIT src=172.26.0.14 dst=13.224.227.120 sport=49501 dport=443 src=13.224.227.120 dst=172.27.95.219 sport=443 dport=49501 [ASSURED] mark=0 use=1
tcp      6 431926 ESTABLISHED src=172.26.0.14 dst=13.224.128.174 sport=39254 dport=443 src=13.224.128.174 dst=172.27.95.219 sport=443 dport=39254 [ASSURED] mark=0 use=1
...

Troubleshooting

A number of components work together to implement the L2TP VPN appliance:

prol2tpd - L2TP server
propppd - PPP server
strongswan - IPSec connection manager
freeradius - RADIUS server

All components must be working and correctly configured. If something isn't working, the following may help to identify the problem.

If no L2TP tunnel or setup requests are being received, the problem will be either IPSec (client using incorrect certificate or PSK) or incorrect VPC mnetwork configuration. To determine if L2TP packets are being received:

root@vpnsrv:~# prol2tp show system stats
Statistics:
  local tunnel creates/destroys: 0, 0
  net tunnel creates/destroys: 0, 0
  local session creates/destroys: 0, 0
  net session creates/destroys: 0, 0
  config file reconfigures: 0
  API requests: 0

If L2TP net tunnel and session creates not increasing when clients are trying to connect, IPSec is not working correctly. IPSec activity is logged in the system journal by the strongswan service:

root@vpnsrv:~# journalctl -u strongswan -f

When a client connects successfully using a certificate, you should see something like the following:

 06[ENC] parsed ID_PROT request 0 [ SA V V V V V ]
 06[IKE] received XAuth vendor ID
 06[IKE] received DPD vendor ID
 06[IKE] received FRAGMENTATION vendor ID
 06[IKE] received NAT-T (RFC 3947) vendor ID
 06[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
 06[IKE] 1.2.3.4 is initiating a Main Mode IKE_SA
 06[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
 06[ENC] generating ID_PROT response 0 [ SA V V V V ]
 10[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
 10[IKE] local host is behind NAT, sending keep alives
 10[IKE] remote host is behind NAT
 10[IKE] sending cert request for "C=UK, O=vpn.example.com, CN=ProL2TP CA"
 10[ENC] generating ID_PROT response 0 [ KE No CERTREQ CERTREQ NAT-D NAT-D ]
 13[ENC] parsed ID_PROT request 0 [ FRAG(1) ]
 13[ENC] received fragment #1, waiting for complete IKE message
 14[ENC] parsed ID_PROT request 0 [ FRAG(2/2) ]
 14[ENC] received fragment #2, reassembled fragmented IKE message (1500 bytes)
 14[ENC] parsed ID_PROT request 0 [ ID CERT SIG CERTREQ N(INITIAL_CONTACT) ]
 14[IKE] received cert request for 'C=UK, O=vpn.example.com, CN=ProL2TP CA'
 14[IKE] received end entity cert "C=UK, O=vpn.example.com, CN=ProL2TP VPN client 1"
 14[CFG] looking for RSA signature peer configs matching 172.27.0.9...1.2.3.4[vpnclient1]
 14[CFG] selected peer config "vpnclient1"
 14[CFG]   using trusted ca certificate "C=UK, O=vpn.example.com, CN=ProL2TP CA"
 14[CFG] checking certificate status of "C=UK, O=vpn.example.com, CN=ProL2TP VPN client 1"
 14[CFG] certificate status is not available
 14[CFG]   reached self-signed root ca with a path length of 0
 14[CFG]   using trusted certificate "C=UK, O=vpn.example.com, CN=ProL2TP VPN client 1"
 14[IKE] authentication of 'vpnclient1' with RSA_EMSA_PKCS1_NULL successful
 14[IKE] authentication of 'vpnserver1' (myself) successful
 14[IKE] IKE_SA vpnclient1[4] established between 172.27.0.9[vpnserver1]...1.2.3.4[vpnclient1]
 14[IKE] sending end entity cert "C=UK, O=vpn.example.com, CN=ProL2TP VPN server"
 14[ENC] generating ID_PROT response 0 [ ID CERT SIG ]
 14[ENC] splitting IKE message (1948 bytes) into 2 fragments
 14[ENC] generating ID_PROT response 0 [ FRAG(1) ]
 14[ENC] generating ID_PROT response 0 [ FRAG(2/2) ]
 08[ENC] parsed QUICK_MODE request 604849487 [ HASH SA No KE ID ID NAT-OA NAT-OA ]
 08[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_3072/NO_EXT_SEQ
 08[IKE] received 28800s lifetime, configured 0s
 08[ENC] generating QUICK_MODE response 604849487 [ HASH SA No KE ID ID NAT-OA NAT-OA ]
 09[ENC] parsed QUICK_MODE request 604849487 [ HASH ]
 09[IKE] CHILD_SA vpnclient1{3} established with SPIs c9e48f10_i ce78e8a6_o and TS 172.27.0.9/32[udp/l2f] === 1.2.3.4/32

When a client connects successfully using a PSK, you should see something like the following:

 10[ENC] parsed QUICK_MODE request 2599905659 [ HASH SA No KE ID ID NAT-OA NAT-OA ]
 10[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_3072/NO_EXT_SEQ
 10[IKE] received 28800s lifetime, configured 0s
 10[ENC] generating QUICK_MODE response 2599905659 [ HASH SA No KE ID ID NAT-OA NAT-OA ]
 13[ENC] parsed QUICK_MODE request 2599905659 [ HASH ]
 13[IKE] CHILD_SA vpnclient-psk{2} established with SPIs cfd4f89c_i cd2d865b_o and TS 172.27.0.9/32[udp/l2f] === 1.2.3.4/32

L2TP activity is logged in /var/log/prol2tpd.log

VPN clients will try to create a PPP session in L2TP. To examine PPP activity:

root@vpnsrv:~# propppctl status
ProPPP v2.1.0
  support: support@prol2tp.com
License:
  unlicensed
PPP:
  ppp instance count: 0
  create requests: 0, failures: 0
  destroy requests: 0, failures: 0
RADIUS:
  access requests: 0, accepts: 0, rejects: 0, challenges: 0
  accounting starts: 0, stops: 0, updates: 0, responses: 0
  disconnect requests: 0, responses: 0
  retransmits: 0, timeouts: 0
  auth requests in progress: 0, accounting requests in progress: 0
Events:
  created: 0, destroyed: 0, up: 0, down: 0
Config:
  config updates: 1, failures: 0

The number of RADIUS rejects increases each time a VPN client attempts to connect with an invalid username/password. If this happens, check the VPN client configuration and check that the file /etc/freeradius/3.0/vpnusers/$USER.confexists for the user trying to connect. If the file is not present, did you forget to add the VPN user using add-vpn-user[s]?

PPP activity is logged in /var/log/propppd.log

RADIUS debug can be viewed from the system journal:

root@vpnsrv:~# journalctl -u freeradius -f

Support

Please register an account at https://prol2tp.com/register for access to ProL2TP product documentation and support.