L2TP (Layer 2 Tunnel Protocol)
L2TP (RFC 2661, RFC 2888) unites the best features and approaches of L2F and PPTP. This reflects the name, too. L2TP is the preferred choice to realize state-of-the-art protocol-independent VPDNs and is a replacement for PPTP and L2F. L2TP uses port 1701/udp and protocol number 115; adjust possible security filters accordingly.
Securing L2TP Using IPSec (RFC 3193)
Although L2TP supports tunnel endpoint authentication, it lacks a tunnel-protection mechanism. However, because it encapsulates PPP, it inherits PPP authentication and the PPP Encryption/Compression Control Protocol (ECP/CCP). The IPSec protocol suite provides features such as tunnel authentication, privacy protection, integrity checking, and replay protection at the network layer for IP networks.
L2TP Operation
L2TP offers the capability to separate the actual call termination of Layer 2 connections such as plain old telephone service (POTS), Integrated Services Digital Network (ISDN), or Digital Subscriber Line (DSL) from the transport of the associated PPP session. This means that the terminating device (modem line card, DSLAM) can reside geographically and logically separated from the network access server (NAS). The PPP sessions are tunneled from the concentrator/aggregator device to the NAS architecture, and the PPP call is terminated there. Therefore, L2TP is a logical extension of PPP over a packet-switched (IP) infrastructure.
Modern DSL metro architectures consisting of DSLAMs, aggregator devices, and service-selection gateways facilitating L2TP tunnels to transport large quantities of PPP sessions represent good examples of L2TP deployment. L2TP is downward compatible with L2F and works with NAT. The latest-and-greatest gadgets and gizmos are included in the L2TPv3 standards.
L2TP also offers a potential solution to the multilink-multichassis hunt-group problem: The strict requirement that all channels composing a multilink bundle must reside on the same NAS can be circumvented.
L2TPv3 and Related "Work in Progress"
L2TP's evolution is determined largely by its usefulness for Internet service providers (ISPs), with occasional features finding their way into enterprise networking (such as IPSec). To sum it up, L2TPv3 offers the following:
A clearer separation from PPP
Extended address-value pairs (AVPs)
32-bit session ID and control connection ID
Pseudo wire extensions for High-Level Data Link Control (HDLC) and Frame Relay transport
Transport of Ethernet and VLAN frames over L2TP pseudo wires
Header compression
Multicast extensions
L2TPd for UNIX: A Project in Transition
This package (http://www.l2tpd.org) is not considered production grade, but it is reported to work with Cisco L2TP setups, the Microsoft implementation, and L2TP/IPSec combinations. It is the only implementation for UNIX I am aware of. If you encounter problems, try the previous package at http://sourceforge.net/projects/rp-l2tp.
Form your own opinion as to whether L2TPd for UNIX is stable enough for your purposes. If you have questions, consult the mailing list at http://www.l2tpd.org and be sure you have a good foundation in PPP debugging. The terms LNS and LAC are IETF lingo and mean L2TP network server and L2TP access concentrator, respectively.
Figure 11-3 presents a standard L2TP architecture useful for most applications.
Figure 11-3. L2TP Architecture
In Example 11-9, a Linux gateway can act as an LAC or LNS. See the configuration in Example 11-9 as a start for your own tests.
Example 11-9. L2TPd Configuration Example and Secrets File
[root@callisto:~#] cat /etc/l2tp/l2tpd.conf ; ; Sample l2tpd configuration file ; ; ; [global] ; Global parameters: ; port = 1701 ; * Bind to port 1701 ; auth file = /etc/l2tp/l2tp-secrets ; * Where our challenge secrets are ; access control = yes ; * Refuse connections without IP match ; rand source = dev ; Source for entropy for random ; ; numbers, options are: ; ; dev - reads of /dev/urandom ; ; sys - uses rand() ; ; egd - reads from egd socket ; ; egd is not yet implemented ; ; [lns default] ; Our fallthrough LNS definition ; exclusive = no ; * Only permit one tunnel per host ; ip range = 192.168.0.1-192.168.0.20 ; * Allocate from this IP range ; no ip range = 192.168.0.3-192.168.0.9 ; * Except these hosts ; ip range = 192.168.0.5 ; * But this one is okay ; ip range = lac1-lac2 ; * And anything from lac1 to lac2's IP ; lac = 192.168.1.4 - 192.168.1.8 ; * These can connect as LACs ; no lac = untrusted.marko.net ; * This guy can't connect ; hidden bit = no ; * Use hidden AVPs? ; local ip = 192.168.1.2 ; * Our local IP to use ; length bit = yes ; * Use length bit in payload? ; require chap = yes ; * Require CHAP auth. by peer ; refuse pap = yes ; * Refuse PAP authentication ; refuse chap = no ; * Refuse CHAP authentication ; refuse authentication = no ; * Refuse authentication altogether ; require authentication = yes ; * Require peer to authenticate ; unix authentication = no ; * Use /etc/passwd for auth. ; name = myhostname ; * Report this as our host name ; ppp debug = no ; * Turn on PPP debugging ; pppoptfile = /etc/ppp/options.l2tpd.lns ; * ppp options file ; call rws = 10 ; * RWS for call (-1 is valid) ; tunnel rws = 4 ; * RWS for tunnel (must be > 0) ; flow bit = yes ; * Include sequence numbers ; challenge = yes ; * Challenge authenticate peer ; ; ; [lac cisco] ; Example VPN LAC definition ; lns = lns.marko.net ; * Who is our LNS? ; lns = lns2.marko.net ; * A backup LNS (not yet used) ; redial = yes ; * Redial if disconnected? ; redial timeout = 15 ; * Wait n seconds between redials ; max redials = 5 ; * Give up after n consecutive failures ; hidden bit = yes ; * User hidden AVPs? ; local ip = 192.168.1.1 ; * Force peer to use this IP for us ; remote ip = 192.168.1.2 ; * Force peer to use this as their IP ; length bit = no ; * Use length bit in payload? ; require pap = no ; * Require PAP auth. by peer ; require chap = yes ; * Require CHAP auth. by peer ; refuse pap = yes ; * Refuse PAP authentication ; refuse chap = no ; * Refuse CHAP authentication ; refuse authentication = no ; * Refuse authentication altogether ; require authentication = yes ; * Require peer to authenticate ; name = marko ; * Report this as our host name ; ppp debug = no ; * Turn on PPP debugging ; pppoptfile = /etc/ppp/options.l2tpd.marko ; * ppp options file for this lac ; call rws = 10 ; * RWS for call (-1 is valid) ; tunnel rws = 4 ; * RWS for tunnel (must be > 0) ; flow bit = yes ; * Include sequence numbers ; challenge = yes ; * Challenge authenticate peer [root@callisto:~#] cat /etc/l2tp/l2tp-secrets # Secrets for authenticating l2tp tunnels # us them secret # * marko blah2 # zeus marko blah # * * interop
Exercise 11-3: L2TP
Configure a Linux/BSD LAC and LNS in combination with a Cisco LNS and figure out the degree of interoperability. Then analyze the Microsoft IPSec/L2TP implementation in combination with this architecture.
