Introduction to L2TPv3

A brief history of L2TP

When originally specified, L2TP was deemed Version 2 of the protocol and will sometimes be referred to as L2TPv2. Version 1 actually had a different name (L2F) and was designed by Cisco. L2TP was standardised by the Internet Engineering Task Force (IETF) in RFC2661 back in 1999.

L2TPv2 was designed to carry PPP traffic over IP networks. Network access equipment (DSL, cable modem or dial-up access interfaces) accepted PPP connections from subscribers and tunnelled the PPP sessions to the ISP over L2TP. Up to 65535 PPP sessions could be carried in a single tunnel.

Soon, L2TPv2 was being used to join private networks together over a public IP network - the so-called Virtual Private Network (VPN). PPP provided user access control and automatic configuration of network settings for connected clients. Each client opened a separate L2TP tunnel with a peer and ran a single PPP session over the tunnel. Microsoft added built-in L2TP VPN support in Windows 2000. Apple, Linux and other operating systems also made L2TP VPNs possible by adding L2TP client support. The L2TP protocol does not implement any encryption of it's own, so VPN administrators often choose to secure the tunnel using IPSec.

The new features of L2TPv3

L2TPv2 was only ever designed to carry PPP traffic. The new revision of the L2TP protcol (known as L2TPv3) changes the protocol so that it can carry data frame formats other than PPP. Each L2TPv3 session carries one data frame type which is agreed by both peers when the session is established and is effectively a virtual physical wire of that data link type. It is often referred to as a "pseudowire" for that reason. Many L2TP pseudowire types are already defined: PPP, ethernet, VLAN, HDLC, Frame Relay and various ATM flavours.

If only PPP is carried over L2TP, upgrading to L2TPv3 may still be useful. L2TPv3 brings the following other enhancements:

  • L2TPv3 can be carried directly over IP, without UDP. L2TPv2 can only be carried over UDP.
  • L2TPv3 packets have an optional cookie, which can be useful to detect and discard misdirected data packets which have the wrong session id. This provides some protection against some packet insertion attacks.
  • L2TPv3 control message authentication is done over the entire message, while L2TPv2 covers only individual attributes of specific messages. L2TPv3 is therefore less susceptible to man-in-the-middle attacks when the tunnel is not secured by IPSec.
  • L2TPv3 tunnel and session ids are 32-bit values; L2TPv2 used 16-bit values. L2TPv3 is therefore able to support more than 65535 tunnels or more than 65535 sessions in a single tunnel. Few installations approach these limits though!
  • L2TPv2 requires the L2TP tunnel and session to be established by a control message exchange with the peer. L2TPv3, however, allows sessions to be configured without a control channel; each L2TP endpoint is manually configured with static parameters. This makes it possible to set up L2TPv3 pseudowires without a separate L2TP control service. Doing so might be used for simple setups involving a handful of tunnels.

Most people are interested in L2TPv3 because of its facility to carry non-PPP traffic. ISPs and network operators may use L2TPv3 to extend Frame Relay or ATM networks over an IP infrastructure. Perhaps the most interesting use for smaller operators and network administrators is L2TPv3's facility of carrying ethernet frames over an IP network, which joins one or more ethernet LANs together. This is often called Layer 2 Tunneling.

Systems supporting L2TPv3

Commercial networking equipment from several vendors including Cisco and Juniper Networks will usually support L2TPv3.

The use of Linux or BSD systems as networking equipment by corporations and smaller ISPs is becoming increasingly popular. Unfortunately, BSD does not support L2TPv3, but some support is now available in Linux (from kernel 2.6.35).

The difference between Ethernet and VLAN L2TPv3 pseudowires

Ethernet pseudowires carry the complete ethernet frame, including its MAC header. The ethernet frame is inserted inside an L2TPv3 packet and transmitted to the peer. The peer removes the L2TPv3 header and passes the ethernet frame on, as if it were directly connected to the LAN from where the ethernet frame came. Most implementations will model each pseudowire endpoint as a virtual network interface, which can be configured as a bridge port or assigned an IP address, like any other interface.

VLAN pseudowires also carry ethernet frames. However, each VLAN pseudowire carries traffic only of a nominated VLAN. This allows an L2TP node to send traffic from different VLANs through different L2TP tunnels, potentially to different L2TP peers. The VLAN id is signalled to the peer when the L2TP session is established, which allows the peer to configure its forwarding tables to handle the given VLAN appropriately.

Ethernet pseudowires can also carry VLAN-tagged frames. However, this extends the VLAN networks to the peer, which must therefore be manually configured with the same VLAN ids.

Unmanaged L2TPv3 L2 tunnels for Linux

Unmanaged (static) L2TPv3 ethernet pseudowires are a great way to implement simple Layer 2 tunnels where the number of pseudowires is limited and all L2TP endpoints can be locally administered.

It is possible to create unmanaged L2TPv3 L2 tunnels on Linux without any additional server software. All that is required is reasonably recent kernel and the free iproute2 package.

Prerequisites

First, ensure that the kernel has L2TPv3 support enabled. Few distributions currently do this. One distribution that does enable L2TPv3 is Debian Squeeze, but only in their optional 2.6.38/39 kernels. Ubuntu and Fedora don't have L2TPv3 enabled at the time of writing, so you will need to build a custom kernel for those systems. If you don't know how to build a custom kernel, consider using a Debian Squeeze VM.

Next, install or build iproute2 version 3.2.0 or later. If your distro comes with iproute2-3.2.0 or later, nothing more needs to be done, but this is unlikely unless you have kernel 3.2 or later. The iproute2 source is at http://www.kernel.org/pub/linux/utils/net/iproute2/. Depending on the installed kernel version, the whole iproute2 package might not build. We only need the ip utility (built in the ip subdirectory). It is best not to replace the system's ip binary (usually installed at /sbin/ip). Instead, install it with a different filename, say, ipl2tp and use it only for L2TP commands. The reason not to overwrite the standard ip utility is that iproute2 is versioned with the kernel and is typically updated when new kernel versions are released. Using iproute2 intended for a different kernel version might introduce unexpected behaviour in other commands. For the L2TP commands, we know that the kernel API hasn't changed since 2.6.35.

Creating the tunnel

Now we are ready to create L2TPv3 ethernet pseudowires at each L2TP endpoint. In the commands shown below, we use the standard ip utility. Replace ip with the path to your own ip utliity if you are using your own build of ip.

site-A:# ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 encap udp \
           local 1.2.3.4 remote 5.6.7.8 udp_sport 5000 udp_dport 6000
site-A:# ip l2tp add session tunnel_id 3000 session_id 1000 peer_session_id 2000
site-B:# ip l2tp add tunnel tunnel_id 4000 peer_tunnel_id 3000 encap udp \
           local 5.6.7.8 remote 1.2.3.4 udp_sport 6000 udp_dport 5000
site-B:# ip l2tp add session tunnel_id 4000 session_id 2000 peer_session_id 1000
site-A:# ip link set l2tpeth0 up mtu 1488
site-B:# ip link set l2tpeth0 up mtu 1488

Notice that the IP addresses, UDP ports and tunnel / session ids are matched and reversed at each site.

Configuring the interface

IP interfaces

The two interfaces can be configured with IP addresses if only IP data is to be carried. This is perhaps the simplest configuration.

site-A:# ip addr add 10.42.1.1 peer 10.42.1.2 dev l2tpeth0
site-B:# ip addr add 10.42.1.2 peer 10.42.1.1 dev l2tpeth0

Now the link should be usable. Add static routes as needed to have data sent over the new link.

site-A:# ping 10.42.1.2
Bridged interfaces

Most likely, L2TPv3 ethernet pseudowires are being used to implement Layer-2 tunnels. To carry non-IP data, the L2TP network interface is added to a bridge instead of being assigned its own IP address, using standard Linux utilities.

brctl addbr br0
brctl addif br0 l2tpeth0
brctl addif br0 eth0
ip link set br0 up promisc on

If you are using VLANs, setup a bridge per VLAN and bridge each VLAN over a separate L2TP session. For example, to bridge VLAN ID 5 on eth1 over an L2TP pseudowire:

brctl addbr brvlan5
brctl addif brvlan5 l2tpeth0.5
brctl addif brvlan5 eth1.5
ip link set brvlan5 up promisc on

Adding the L2TP interface to a bridge causes the bridge to forward traffic over the L2TP pseudowire just like it forwards over any other interface. The bridge learns MAC addresses of hosts attached to each interface and intelligently forwards frames from one bridge port to another. IP addresses are not assigned to the l2tpethN interfaces. If the bridge is correctly configured at both sides of the L2TP pseudowire, it should be possible to reach hosts in the peer's bridged network.

Tuning

The next thing to consider is the maximum packet size (often called the Maximum Transfer Unit, or MTU) that can be sent over the pseudowire before IP fragmentation is needed. Fragmentation hurts performance. To avoid fragmentation as much as possible, it can be beneficial to set the TCP Maximum Segment Size (MSS) to 1448, which is 40 bytes less than the interface MTU. The 40 bytes allows space for the L2TPv3, UDP and IP headers.

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss \
	 --mss 1448:1536 -j TCPMSS --set-mss 1448

Managed L2TPv3 L2 tunnels for Linux

Unmanaged pseusowires are just that - they are unmanaged and there is no indication of pseudowire link state changes. Where pseudowires are regularly commissioned such as in ISP environments, it is usual to use L2TP servers to setup managed control connections for each pseudowire.

ProL2TP is an L2TPv2 and L2TPv3 managed tunnel server, suitable for enterprise deployments. It is currently the only option for managed L2TPv3 tunnels for Linux.

To setup a ProL2TP server at site-A to accept L2TPv3 connections from two peers, site-B and site-C, the following config file could be used:

peer profileIdentifies parameters to be used when connecting with an L2TP peer. Peers are identified by name or by IP address / netmask.  The peer profile specifies default tunnel, session, PPP and ethernet profile names which are to be used for the peer, unless overridden by other settings. Peer profiles are matched by IP address or peer identifier, which is provided in the L2TP tunnel setup request. They are the core mechanism used in servers to identify specific tunnel, session, ppp and ethernet profiles for incoming requests from clients. "site-B" {
     tunnel_profile_nameName of default Tunnel Profile. Default="default" "site-B"
     ethernet_profile_nameName of default Ethernet Profile. Default="default" "site-B"
}

peer profileIdentifies parameters to be used when connecting with an L2TP peer. Peers are identified by name or by IP address / netmask.  The peer profile specifies default tunnel, session, PPP and ethernet profile names which are to be used for the peer, unless overridden by other settings. Peer profiles are matched by IP address or peer identifier, which is provided in the L2TP tunnel setup request. They are the core mechanism used in servers to identify specific tunnel, session, ppp and ethernet profiles for incoming requests from clients. "site-C" {
     tunnel_profile_nameName of default Tunnel Profile. Default="default" "site-C"
     ethernet_profile_nameName of default Ethernet Profile. Default="default" "site-C"
}

tunnel profileProvides a named set of L2TP tunnel parameters which may be used when creating tunnels locally (by specifying the tunnel profile name when the tunnel is created) or when tunnels are created by remote request. "default" {
     proto_versionThe protocol version of a tunnel. 2 means L2TPv2. 3 means L2TPv3. Default is 0, which means either L2TPv2 or L2TPv3 is acceptable. For clients, the value 0 causes ProL2TP to send its tunnel setup request in a form that will work with both L2TPv2 and L2TPv3 peers. 3
     auth_modeTunnel authentication mode:- 
none - no authentication, unless secret is given
simple - check peer hostname
challenge - require tunnel secret
authenticated } tunnel profileProvides a named set of L2TP tunnel parameters which may be used when creating tunnels locally (by specifying the tunnel profile name when the tunnel is created) or when tunnels are created by remote request. "site-B" { auth_modeTunnel authentication mode:-
none - no authentication, unless secret is given
simple - check peer hostname
challenge - require tunnel secret
authenticated secretOptional secret which is shared with tunnel peer. Must be specified when hide_avps is enabled. Default=NONE (no secret). "site-B-super-secret" proto_versionThe protocol version of a tunnel. 2 means L2TPv2. 3 means L2TPv3. Default is 0, which means either L2TPv2 or L2TPv3 is acceptable. For clients, the value 0 causes ProL2TP to send its tunnel setup request in a form that will work with both L2TPv2 and L2TPv3 peers. 3 hide_avpsHide AVPs. The L2TP protocol allows some L2TP Attribute Value Pairs (AVPs) contained in L2TP control protocol messages to be obscured from network sniffers. This adds some overhead with L2TP message transmit and receive. Requires a tunnel secret to be configured. Default OFF. yes } tunnel profileProvides a named set of L2TP tunnel parameters which may be used when creating tunnels locally (by specifying the tunnel profile name when the tunnel is created) or when tunnels are created by remote request. "site-C" { auth_modeTunnel authentication mode:-
none - no authentication, unless secret is given
simple - check peer hostname
challenge - require tunnel secret
authenticated secretOptional secret which is shared with tunnel peer. Must be specified when hide_avps is enabled. Default=NONE (no secret). "site-C-super-secret" proto_versionThe protocol version of a tunnel. 2 means L2TPv2. 3 means L2TPv3. Default is 0, which means either L2TPv2 or L2TPv3 is acceptable. For clients, the value 0 causes ProL2TP to send its tunnel setup request in a form that will work with both L2TPv2 and L2TPv3 peers. 3 hide_avpsHide AVPs. The L2TP protocol allows some L2TP Attribute Value Pairs (AVPs) contained in L2TP control protocol messages to be obscured from network sniffers. This adds some overhead with L2TP message transmit and receive. Requires a tunnel secret to be configured. Default OFF. yes } session profileProvides a named set of L2TP session parameters which may be used when creating sessions locally (by specifying the session profile name when the session is created) or when sessions are created by remote request. "site-B" { pseudowire_typeIndicates the type of data to be carried in an L2TPv3 pseudowire. Valid values are ppp, eth or vlan, corresponding to PPP, Ethernet and VLAN pseudowires. Valid for L2TPv3 only. For vlan pseudowire types, vlan_id must also be specified. Required parameter for locally created L2TPv3 sessions. For network-created sessions, the pseudowire type is set by the remote peer requesting the session. This is a required parameter of SESSION blocks for L2TPv3 sessions. Default=NONE. eth interface_nameinterface name of session interface. If this is specified in the session profile, the session profile cannot be used to define parameters for more than one session, since sessions must have unique interface names. Default pppN for PPP pseudowires, l2tpethN for ethernet pseudowires, or l2tpethN.M for vlan pseudowires (where M is the vlan id). "l2tpethB" } session profileProvides a named set of L2TP session parameters which may be used when creating sessions locally (by specifying the session profile name when the session is created) or when sessions are created by remote request. "site-C" { pseudowire_typeIndicates the type of data to be carried in an L2TPv3 pseudowire. Valid values are ppp, eth or vlan, corresponding to PPP, Ethernet and VLAN pseudowires. Valid for L2TPv3 only. For vlan pseudowire types, vlan_id must also be specified. Required parameter for locally created L2TPv3 sessions. For network-created sessions, the pseudowire type is set by the remote peer requesting the session. This is a required parameter of SESSION blocks for L2TPv3 sessions. Default=NONE. eth interface_nameinterface name of session interface. If this is specified in the session profile, the session profile cannot be used to define parameters for more than one session, since sessions must have unique interface names. Default pppN for PPP pseudowires, l2tpethN for ethernet pseudowires, or l2tpethN.M for vlan pseudowires (where M is the vlan id). "l2tpethC" } ethernet profileProvides a named set of ethernet parameters which are to be used when creating L2TPv3 ethernet pseudowires. "site-B" { bridge_nameInstead of assigning IP addresses to the ethernet interface, it can be added to a named bridge instance if this parameter is set. Use this to bridge ethernet frames over L2TP. The bridge must already exist. brB mtuThe MTU of the ethernet interface. By default, the MTU is derived from the MTU of the L2TP session, which is itself derived from the tunnel. 1488 } ethernet profileProvides a named set of ethernet parameters which are to be used when creating L2TPv3 ethernet pseudowires. "site-C" { bridge_nameInstead of assigning IP addresses to the ethernet interface, it can be added to a named bridge instance if this parameter is set. Use this to bridge ethernet frames over L2TP. The bridge must already exist. brC mtuThe MTU of the ethernet interface. By default, the MTU is derived from the MTU of the L2TP session, which is itself derived from the tunnel. 1488 }

At site-B and site-C, the following ProL2TP configs are used:

systemContains attributes that may be used to control the system behavior of ProL2TP, i.e. tunnel instance limits, UDP port number, debug logging options etc. There is always one instance of this object and it has no name. {
     deny_remote_tunnel_createsDeny the creation of new tunnels by remote peers. yes
}

ethernet profileProvides a named set of ethernet parameters which are to be used when creating L2TPv3 ethernet pseudowires. "one" {
     bridge_nameInstead of assigning IP addresses to the ethernet interface, it can be added to a named bridge instance if this parameter is set. Use this to bridge ethernet frames over L2TP. The bridge must already exist. brB
     mtuThe MTU of the ethernet interface. By default, the MTU is derived from the MTU of the L2TP session, which is itself derived from the tunnel. 1488
}

tunnelContains parameters of a locally initiated L2TP tunnel.  A tunnel is identified by a unique name and may contain tunnel parameters and one or more session blocks, one per session within the tunnel. Tunnel parameters may be derived from a named tunnel profile. A tunnel block is used only in client configurations to create one or more tunnels. "site-B" {
     host_name "site-B"
     auth_mode authenticated
     secret "site-B-super-secret"     
     proto_version 3
     hide_avps yes
     sessionContains parameters of an L2TP session within a tunnel, such as data link options and whether to use data sequence numbers. A session is scoped by a tunnel block and is identified by a tunnel-unique name. "one" {
         pseudowire_type eth
         ethernet_profile_name "one"
         interface_name "l2tpethB"
     }
}

The configuration above will create interface l2tpethB and add it to bridge brB when the L2TP ethernet pseudowire is established with site-B. If the tunnel goes down, the interface is automatically deconfigured and destroyed.