Quick Start

This page is intended to provide a quick summary of common OpenL2TP configurations to help new users get started.

OpenL2TP Features

OpenL2TP, is a dual-licensed, open-source implementation of L2TP for Linux. OpenL2TP is ideal for use in any of the following environments:-

  • as an L2TP VPN service for deployment on servers at the workplace, providing L2TP VPN access for home workers.
  • as a component in commercial Embedded Linux systems, such as home gateways or even big telecommunications switches.
  • as an L2TP client for desktop users.

OpenL2TP is a complete implementation of RFC2661 - Layer Two Tunneling Protocol, Version 2. Key features are listed below. Impatient readers may safely skip this section.

  • Operation as both LAC and LNS simultanesously is supported. A single server may be a LAC for some tunnels and a LNS for others.
  • Incoming and outgoing tunnels and sessions are supported.
  • Multiple tunnels and multiple sessions in those tunnels are supported. The maximum number of tunnels and sessions is limited only by available system memory (max 65535 tunnels and 65535 sessions per tunnel) or by system and user-configured limits.
  • All four session types are supported, i.e. LAC/LNS Incoming/Outgoing Calls.
  • Multiple tunnels between the same two L2TP hosts is supported.
  • Tunnel, session and PPP parameters may be defined in named profiles, simplifying the management interface and allowing specific parameter values to be used for specific incoming tunnels (those created by remote request over the network).
  • Is able to parse and record all standard L2TP AVPs defined in RFC2661. It checks that all required AVPs are present in each message and generates error log messages if unexpected AVPs are seen.
  • Control messages are handled by a userland daemon, openl2tpd. All L2TP data packets are handled by the kernel.
  • Trace messages optionally logged using syslog can be enabled/disabled at system, tunnel and session levels. Thus to debug problems on a busy system, tracing can be safely enabled only for specific entities without flooding the system with messages from other uninteresting entities.
  • Management interface uses Sun RPC, making OpenL2TP particularly suitable for embedded chassis environments such as telco systems.
  • Bundled with an intuitive command-line management application that uses TAB syntax completion, command history and context sensitive help.
  • Employs a plugin architecture to allow third parties to easily extend or integrate OpenL2TP with other software, e.g. PPP, RADIUS, B-RAS etc etc. Includes a plugin for interfacing to pppd but other PPP
    implementations may be used if desired via a plugin.
  • Supports automatic IP address assignment from local address pools if other address allocation mechanisms (e.g. RADIUS) are not configured. Use ippoold.
  • Locally created tunnels may optionally be designated persistent, causing them to try to recreate themselves should the tunnel fail for some reason. Any locally created sessions in persistent tunnels are also automatically restored if/when the tunnel restablishes itself. This is useful if openl2tpd is used as an L2TP client.
  • Interoperates with Cisco IOS 12.2, Microsoft W2K/XP, Apple OSX, Draytek and others.

The Linux kernel PPP-over-L2TP driver, pppol2tp, was developed by the OpenL2TP project. It was integrated into the official kernel in 2.6.23. Several Linux distributions now ship with the driver. For earlier kernels, the pppol2tp-kmod package should be installed. Binary RPMs are available for some kernels, or the driver can be built from source. Be aware though that OpenL2TP version 1.0 is only compatible with pppol2tp-kmod-0.17.

L2TP Client

When OpenL2TP's server, openl2tpd is started, it reads configuration commands from /etc/openl2tpd.conf by default, or the file specified with the optional -c command line switch. The following example config file will create an L2TP tunnel to host and log in using user bert, password ernie. Note that two separate commands create the VPN - an L2TP tunnel is created and then a session is created in that tunnel.


ppp profile modify profile_name=default \
	auth_eap=no auth_mschapv1=no auth_mschapv2=no

tunnel create tunnel_name=katalix dest_ipaddr= \

session create tunnel_name=katalix \
	session_name=katalix \
	user_name=bert \

The use of persist=yes in the above config tells OpenL2TP to retry the tunnel setup is the server goes down. OpenL2TP will send periodic tunnel setup requests until the tunnel comes up and will try to recreate the tunnel if it ever goes down.

Since OpenL2TP operates as both an L2TP client and an L2TP server by default, some VPN users may wish to disable the server functionality. To do so, include the following command in the above config file.

system modify deny_remote_tunnel_creates=yes

The l2tpconfig command line utility may be used to interactively view or modify OpenL2TP configuration and status. The utility is intuitive to use - it has tab command completion and command editing. The following shows an example session to display status information about the L2TP tunnel created above.

[bert@ernie.net]# l2tpconfig
l2tp> system show status
L2TP service status:-
  tunnels: 1, sessions: 1

l2tp> user list
   TunId  SesId  User                                              Create Time
   17767   9158  bert                                 Mon Feb  4 13:45:10 2008

l2tp> session show tunnel_id=17767 session_id=9158
Session 9158 on tunnel 17767:-
  type: LAC Incoming Call, state: ESTABLISHED
  created at:  Feb  4 16:22:18 2008
  created by admin: YES, peer session id: 17432
  ppp user name: bert
  ppp interface name: ppp0
  data sequencing required: OFF
  use data sequence numbers: OFF
  trace flags: NONE
  framing types: SYNC ASYNC
  bearer types: DIGITAL ANALOG
  connect speed: 1000000
  use ppp proxy: NO

  Peer configuration data:-
    data sequencing required: OFF
    framing types: SYNC
    bearer types: ANALOG
    connect speed: 54000000
  data rx packets: 593, rx bytes: 608676, rx errors: 1
  data tx packets: 135, tx bytes: 40145, tx errors: 0

If a secure VPN is required, the L2TP tunnel can be secured by IPSec. This configuration is supported by commercial environments such as Windows XP. See the IPSec section below for information on creating L2TP/IPSec VPNs.

L2TP Server

Readers who are not setting up OpenL2TP as a server for other remote L2TP clients may safely skip this section.

Most effort required to set up OpenL2TP as an L2TP server is in setting up user authentication and IP address assignment. When a RADIUS server is used for both of these, the OpenL2TP configuration required is minimal. The options available for user authentication and IP address assignment are described below.

IP Address Assignment

Almost all L2TP clients expect the IP addresses of the PPP session to be assigned by the server. Therefore, when configuring an OpenL2TP server, the mechanism by which IP addresses are assigned must be set. There are three alternatives:

  1. Fixed IP addresses, preconfigured for each connecting client.
  2. Dynamic IP addresses, obtained from an IP address pool.
  3. Dynamic IP addresses, obtained via a RADIUS lookup.

For initial testing of a server, or if the IP addresses of connecting clients is well known, fixed addresses can be configured in OpenL2TP per client. To do this, a peer profile is created per L2TP client (peer), which calls out a unique ppp profile, which in turn defines the IP addresses to be used. OpenL2TP inherits configuration parameters from preconfigured profiles. If you need certain parameters to be set for specific peers, define the settings in tunnel, session or ppp profiles, and reference those profiles in peer profiles.

When an L2TP tunnel setup request is received, OpenL2TP tries to find a peer profile that matches the sender's IP address (or L2TP name, if provided). If none is found, the default peer profile is used. Each peer profile points to a unique ppp profile. This is shown by the following example, where two peers and are assigned IP addresses and respectively when they connect.


ppp profile create profile_name=peer1 \
	local_ipaddr= \

ppp profile create profile_name=peer2 \
	local_ipaddr= \

peer profile create profile_name=peer1 \
	peer_ipaddr= \

peer profile create profile_name=peer2 \
	peer_ipaddr= \

But uing a separate ppp profile is tedious when there are lots of clients. It is also impossible to use separate ppp profiles when the IP address (or L2TP hostname) is unknown. To support this case, OpenL2TP supports ippoold, which is a separate server that maintains IP address pools. The ippool server is available from the OpenL2TP project download page.

Configuration of ippoold is simple. Address pools may be created interactively using the ippoolconfig utility. Or a config file may be written to create the address pools. The following example shows a simple configuration with a single address pool containing 100 addresses.


pool create pool_name=default first_addr= num_addrs=100

When all PPP clients are to use the same IP address pool, configuration of OpenL2TP is simple. The following configuration is all that is needed!


ppp profile modify profile_name=default \

The above configuration will allow any L2TP client to connect, and have IP addresses automatically assigned and reused as clients come and go. PPP authentication for each allowed users should be set as documented by pppd, e.g. /etc/ppp/pap-secrets.


For corporate L2TP VPNs and in ISP setups, a RADIUS server is typically used to provide per user authentication, usage accounting and per-subscriber parameters. To use a RADIUS server, pppd should be configured for access to each RADIUS server (see pppd documentation) and the OpenL2TP ppp profile must indicate that RADIUS is to be used.

The pppd RADIUS client configuration file is usually /etc/radiusclient/radiusclient.conf. In the simplest case, this just calls out the IP address and authentication information for each RADIUS server. See man pppd-radius for more information. The RADIUS server itself is configured with the ppp username and password of each allowed user. The RADIUS server usually hands out IP addresses to successfully authenticated users, in which case ippoold isn't required.

To configure OpenL2TP to use RADIUS, simply set the ppp profile to enable RADIUS. The radiusclient.conf configuration file is identified using the optional radius_hint parameter, allowing different RADIUS servers to be used for different L2TP clients by defining different PPP profiles. If a radius_hint value isn't specified, the default radiusclient config file is used.


ppp profile modify profile_name=default \
	use_radius=yes \

If the RADIUS server does not assign IP addresses, ippoold can still be used, thereby using RADIUS to authenticate users and ippoold to allocate IP addresses. To do so, just add ip_pool_name=xxx to the above PPP profile configuration.


Because OpenL2TP is implemented using standard Linux components, i.e. UDP sockets, kernel datapath and pppd, it integrates seamlessly with other components such as IPSec.

Linux has several IPSec protocol implementations to choose from. OpenL2TP is known to work with at least two of them, namely OpenSWAN and Racoon. An L2TP/IPSec server built using OpenL2TP can support all known L2TP/IPSec clients, including Micorosoft Windows/XP, Apple OSX and of course, OpenL2TP.


Although OpenSWAN comes with its own L2TP implementation, it is trivial to use OpenL2TP instead. Two example configurations are given below, the first of which is simplest and suitable for most installations where it is known that at most one L2TP client will connect from the same IP address.

  1. Simple server with fixed ports
    tunnel profile modify profile_name=default \
    ppp profile modify profile_name=default \

    The above configuration tells OpenL2TP to use a fixed UDP port for all tunnels (which limits it to 1 tunnel per peer). Using a fixed port simplifies OpenSWAN IPSec configuration.

    The OpenSWAN configuration file is shown below.

    conn my-client

    The above example is set to authenticate a tunnel from the client at using a Pre-shared key (PSK). A PSK is basically a common password that must be configured in advance at both the client and server. The PSK is defined in a file named *.secret under directory /etc/ipsec.d/. The corresponding PSK secret is shown below.

    /etc/ipsec.d/my-client.secret : PSK "myunsecurepassword"

    Using PSK is often the easiest way to get started with IPSec but it is less secure than using other IPSec authentication methods, such as RSA certificates. Refer to OpenSWAN documentation for how to configure other IPSec authentication options.

    As usual with OpenSWAN, when changes are made to configuration files, OpenSWAN must be restarted for the new configuration to be loaded. Please note that the OpenSWAN configuration file syntax is sensitive to line indentation.

    In the above example, the IP address of the server is and the address of the client is Port 1701 is the UDP port number assigned to L2TP.

    When multiple tunnels are required between individual peer pairs, things are more complicated because it isn't possible to use a fixed UDP port number 1701. The our_udp_port=1701 tunnel profile parameter is removed. This causes OpenL2TP to use ephemeral ports for each tunnel. Ephemeral ports are assigned by the local IP stack during the tunnel setup process. When both the client and server use ephemeral ports, locally assigned source and destination ports are used. These port numbers cannot be determined in advance, which causes us a problem in the OpenSWAN configuration because we can't call out port 1701 in its configuration. Fortunately, OpenSWAN supports a %any syntax which can be used as a wildcard. However, care is needed because we can't define %any for both left and right ports. Doing so would match every UDP packet! This would cause all UDP traffic between specific peers to be carried in IPSec, which almost certainly isn't what is required. So the server's port (1701) is included in the rules (port 1701 is always used for the initial tunnel setup request) and we enable OpenL2TP's IPSec port tracking feature to have IPSec rules dynamically added/removed by OpenL2TP during the tunnel setup and teardown phases.

  2. Complex server supporting multiple tunnels per IP address pair
    ppp profile modify profile_name=default \
  3. In this configuration, ephemeral UDP ports will be used, so the OpenSWAN config needs to be amended.

    conn my-clients

    However, due to a bug in OpenSWAN 2.4.7 and 2.4.9, it can only support one tunnel between each client/server IP address pair. The problem will show up as the following error in the system log files. Future versions will probably fix this issue.

    ASSERTION FAILED at kernel.c:2237: c->kind == CK_PERMANENT || c->kind == CK_INSTANCE


    Racoon is an alternative IPSec implementation which is distributed in the ipsec-tools package. Its roots are in BSD. The choice of whether to use Racoon or OpenSWAN to use is largely one of personal choice.

    To use OpenL2TP with Racoon, OpenL2TP should be configured exactly as described for OpenSWAN. The Racoon configuration is done using the following config file.

    # Racoon IKE daemon configuration file.
    # See 'man racoon.conf' for a description of the format and entries.
    # log warning;
    path include "/etc/racoon";
    path pre_shared_key "/etc/racoon/psk.txt";
    path certificate "/etc/racoon/certs";
    listen {
    	isakmp [500];
    	isakmp_natt [4500];
    padding {
    	maximum_length 20;	# maximum padding length.
    	randomize off;		# enable randomize length.
    	strict_check off;	# enable strict check.
    	exclusive_tail off;	# extract last one octet.
    remote anonymous {
    	exchange_mode main, aggressive;
    	doi ipsec_doi;
    	situation identity_only;
    	nat_traversal on;
    	generate_policy on;
    	proposal_check obey;
    	proposal {
    		encryption_algorithm 3des;
    		hash_algorithm md5;
    		hash_algorithm sha1;
    		authentication_method pre_shared_key;
    		dh_group modp1024;
    sainfo anonymous
    	lifetime time 1 hour;
    	encryption_algorithm 3des, blowfish 448, rijndael 256, aes 256;
    	authentication_algorithm hmac_md5, hmac_sha1;
    	authentication_algorithm hmac_sha1, hmac_md5;
    	compression_algorithm deflate;

    The above config file sets pre-shared keys to be obtained from /etc/racoon/psk.txt. An example psk.txt is shown below.

    # file for pre-shared keys used for IKE authentication
    # format is:  'identifier' 'key'
    # For example:
    #		flibbertigibbet
    #  www.example.com      12345
    #  foo@www.example.com  micropachycephalosaurus

    IPSec rules must be manually added. This is done using the setkey utility. The following script sets up rules to have L2TP (UDP port 1701) use IPSec.

    #!/sbin/setkey -v
    # This file is to be processed by the setkey(8) utility
    # upon startup of the ipsec service
    # All tunnels to (this host) shall use ESP transport mode
    spdadd [1701] udp -P in ipsec
    spdadd[1701] udp -P out ipsec

    The above script should be run at boot time, when racoon is started.

    If multiple tunnels to a single client are needed, OpenL2TP's default behaviour of using ephemeral UDP ports works well. However, since the port numbers are assigned during the connection process, they cannot be known in advance so cannot be added to OpenSWAN or Racoon config files. But all is not lost. The OpenL2TP ipsec.so plugin causes OpenL2TP to insert and remove rules dynamically as tunnels are set up and torn down. To enable this feature, simply use the -p option when starting openl2tpd, i.e.

    openl2tpd -p ipsec.so

    Miscellaneous Configuration Scenarios

    This section describes several common configuration scenarios and how to set up OpenL2TP in each case.

    • Apply a different set of parameters to tunnels from the network
      peer profile create profile_name=anyname \
      	peer_ipaddr= netmask= \
      	tunnel_profile_name=123net \
      	session_profile_name=123net \
    • Authenticate tunnels using an L2TP tunnel password
      tunnel profile modify profile_name=default \
      	auth_mode=challenge secret=mytunnelpassword

      If multiple tunnels are expected with different passwords, create separate tunnel profiles for each password and use peer profiles to call out the appropriate tunnel profile for each connecting peer.

    • Allow only clients from networks 1.2.3/24 and to connect
      peer profile create profile_name=123net \
      	peer_ipaddr= netmask=
      peer profile create profile_name=4241net \
      	peer_ipaddr= netmask=
      tunnel profile modify profile_name=default \

      With simple tunnel authentication, OpenL2TP allows connections from networks that match a peer profile. This is a convenience feature for operators who do not want to use the Linux firewall.

    • Enable data packet reordering
      session profile modify profile_name=default \
      	use_sequence_numbers=yes \

      Data packet reordering can be useful when packets travel across different routes through the IP network such that they arrive out of order. PPP requires in-order delivery so if packets are received out of order, they are discarded. Setting a non-zero reorder_timeout value enables in-kernel packet reordering to prevent loss of data when reordering occurs.

    • Enable only PPP PAP authentication.
      ppp profile modify profile_name=default \
      	auth_eap=no auth_chap=no \
      	auth_mschapv1=no auth_mschapv2=no 

      Enabling only PAP (or CHAP) is often necessary when using RADIUS.

    • Limit the server to a maximum of 100 connected users
      system modify max_sessions=100