Using a Linux L2TP/IPsec VPN server

I heartily endorse  this gigantic book!

This webpage contains information on how to use L2TP/IPsec clients from Microsoft, Apple and other vendors in a 'Road Warrior' setup connecting to a Linux VPN server based on FreeS/WAN or its successors. FreeS/WAN is an IPsec implementation for Linux 2.x kernels, released under the GNU Public Licence. FreeS/WAN has been succeeded by Openswan and strongSwan. The main advantage of such a setup is cost: if you use the free clients that are included with Windows and Mac OS X, you don't have to spend money on third-party VPN clients or servers. Obviously you still need OS licences for those clients if you want to be legal.

IPsec is a network protocol for secure communication. It's an official Internet standard. Clients and devices from different vendors should interoperate (in theory), as long as they adhere to the IPsec standard. More background information on IPsec can be found in this illustrated guide to IPsec. The following L2TP/IPsec clients are supported by the setup described on this webpage:

Windows 2000/XP/Vista, Pocket PC 2003, Windows Mobile and Mac OS X v10.3+ ship with a built-in L2TP/IPsec client. The "Microsoft L2TP/IPSec VPN Client" for Windows 95 / 98 / Me / NT4 is a free download from the Microsoft website. For brevity, I call it the "MSL2TP client" below. SSH Sentinel, Forticlient and SafeNet SoftRemote are third-party clients for Windows that support both IPsec and L2TP.

• FreeS/WAN: this was the first IPsec implementation available for Linux. However, FreeS/WAN is no longer in active development. It forked into Openswan and strongSwan.
  
• Openswan is maintained by former FreeS/WAN team members who have started the company Xelerance.
• strongSwan is also a continuation of FreeS/WAN. StrongSwan's principal author is Andreas Steffen, the creator of the X.509 certificate patch for FreeS/WAN. Not surprisingly, its main focus is on good certificate and smartcard support. StrongSwan is sponsored by Astaro.
• Kernel 2.6+ contains a native IPsec implementation, which is known as "NETKEY", "26sec" or "PF_KEY". This means that recent distributions ship with IPsec support out of the box.
• ipsec-tools is based on KAME and used by default on many distributions. Its IKE daemon is called racoon.
  
• isakmpd: there is a Linux port of OpenBSD's ISAKMP daemon.
  

1.2 Results

The following Windows L2TP/IPsec clients have been tested:

• Windows XP Professional works fine as an L2TP/IPsec client.
  
• Windows XP Home is similar to XP Professional. It has not been tested by me personally but is reported to work.
  
• Windows 2000 Professional also works.
• Windows Vista works.
  
• Windows 2000 Server (used as a client) works just like Windows 2000 Professional. I wouldn't use it as a desktop operating system, though.
• Windows Server 2003 (used as a client): is similar to Windows 2000 Professional with IPsec update (MS KB Q818043) applied. Again: not recommended as a desktop operating system (mainly due to price).
• Microsoft ISA Server is also reported to work.
• The "Microsoft L2TP/IPSec VPN Client" (alias MSL2TP) works.
  
• SafeNet SoftRemote and OEM versions such as Netscreen-Remote and CoSine (Sprint Business) seem to work. The MSL2TP client is actually derived from this client.
• SSH Sentinel has support for L2TP/IPsec. Seems to work fine. (Note: SSH has sold Sentinel to its competitor SafeNet. Development has ceased. Windows XP with SP2 does not support it (Vista probably neither). You can still order the last version from Buy.com and CyProtect.)
• Forticlient: unknown but is based on SSH Sentinel so it might work.
  
• Windows Mobile and Pocket PC 2003 ship with a built-in L2TP/IPsec client. Requires MS-CHAP support in pppd. There are different versions of Windows Mobile. The Smartphone version is a bit odd. I know how to configure a connection on the (emulated) Smartphone but I could not figure out how to start this connection.
  

• Mac OS X v10.4 ("Tiger") and 10.5 ("Leopard") ship with an L2TP/IPsec client. The client GUI supports certificate authentication but importing the client certificates is a bit tricky.
  
• Mac OS v10.3 ("Panther") ships with an L2TP/IPsec client. The Panther GUI supports authentication through Preshared Keys (PSKs) but it does not support certificates.
  
• The iPhone supports L2TP/IPsec. Currently it supports PSK authentication and no certificate authentication.

Linux can connect as an L2TP/IPsec client to other L2TP/IPsec servers. See also this webpage.

All clients mentioned above support some form of NAT-Traversal. Note that you may need to obtain the latest version of your client to actually get the NAT-T support. Although NAT-T is supported by these clients, it may not always work when you connect to a Linux IPsec server. Some of the clients have been tested successfully, others do not work yet (this is discussed below).

1.3 Commercial products with L2TP/IPsec

Here is a list of L2TP/IPsec server products, in case you rather buy something off the shelf. Most of these are closed source, so you may have to pay for user licences. See also this feature chart on the VPNC website. (The list below does not imply that these products have been tested against Linux L2TP/IPsec).

• Linux based:
• Astaro Security Gateway uses strongSwan and supports L2TP over IPsec, in addition to pure IPsec and PPTP.
• phion netfence
  
• Secure Computing firewall/VPN family (formerly CyberGuard SG (Snapgear))
• Smoothwall Corporate Server with the Smoothtunnel add-on module supports both L2TP over IPsec and pure IPsec. They have made client software which makes installation of certificates easier. Although Smoothwall is based on Linux, there are licence fees based on the number of VPN tunnels.
• Stinghorn L2TP Gateway (no longer available?): supports even multiple Windows/Mac clients behind the same NAT box. It is built on Stinghorn's virtualisation platform and thus one server can accommodate up to 50 Stinghorn L2TP Gateways. This allows operators to isolate customers from each other and offer them dedicated gateway services. Stinghorn used to have a public L2TP/IPsec server available for testing.
•  Mac OS X based:
• Apple Mac OS X Server. Version 10.4 and higher supports authentication through certificates, Kerberos and group secrets.
• Windows based:
• Microsoft Windows 2000, Windows Server 2003 and Windows Server 2008. Windows 2000 does not support NAT-T when used as a server.
  
• Microsoft Windows XP Professional and Windows 2000 Professional. These contain a small-scale VPN server (not included with XP Home) that allow one connection at a time. Extremetech and Bob Cerelli have written articles about this.
• Microsoft Windows Vista. See Windows XP. However, some versions of Vista probably do not ship with the built-in VPN server (like with XP Home).
  
• Windows Server based VPN appliances such as those from ActiveLane.
• Microsoft ISA Server.
• ISA Server based appliances.
• Dedicated hardware:
• Checkpoint VPN-1.
• Cisco PIX firewalls, VPN concentrators and routers running IOS.
• Enterasys routers with VPN capabilities.
• IBM/ISS Proventia UTM
• Intoto
  
• Juniper E-series and Netscreen series.
• Nokia
  
• Nortel VPN Routers
• SonicWALL Firewall/VPN Appliances

1.4 Non-commercial and Open Source products with L2TP/IPsec

• Linux based:
• Astaro.org - Free for home users and special programs for non-profits and educational institutions.
• IPCop - L2TP/IPsec support in development by Duncan Reed (HOWTO).
• LR101 - The Linux VPN Router Project.
• redWall Firewall is a bootable CD-ROM firewall with support for multiple VPNs, IDS, proxies etc.
• The firewall, VPN server and wireless access point from scratch, by Coert Vonk
• Zeroshell by Fulvio Ricciardi is a small Linux distribution with support for wired/wireless networks, VPN, VLANs etc.
  

1.5 Author

The author of this document is Jacco de Leeuw. Corrections, additions, extra information etc. are much appreciated. A big thank you to everybody who has provided feedback!

• Introduction
• Contents
• Background information
• Procedure overview
• Safety first: some security considerations
• VPN alternatives
• (Dis-)advantages of using IPsec with L2TP
• Road Warrior support
• Installation (Linux kernel etc.)
• Configuration of Openswan
• Configuring the L2TP/IPsec clients
• Initiating the L2TP/IPsec connection
• L2TP overview
• L2TP installation and configuration (Linux)
• PPP authentication, compression and encryption
• PPP installation and configuration (Linux)
• Initiating the L2TP/IPsec connection once again
• Some remarks on L2TP/IPsec
• NAT-Traversal
  
• Windows Networking (WINS etc.)
• Split tunnelling
• Troubleshooting
• Certificates
• Protecting wireless connections
• Linux as an L2TP/IPsec client
• Some speculation
• Related links
• Acknowledgements and disclaimer
  
• Revision history

Microsoft has included an IPsec client with Windows 2000 Professional / Server, Windows XP Home / Professional, Windows Vista, Pocket PC 2003 and Windows Mobile. The client is supplied with the base operating system so you do not have to download it. See also my other webpages.

A separate IPsec client can be downloaded for free from the Microsoft website. This 'MSL2TP client' can be installed on Windows 95 / 98 / Me / NT4. Although the client is different from the one included with Windows 2000/XP/Vista, it is quite similar in functionality. For more information on the MSL2TP client, see my webpage "Using a Linux server with the Microsoft L2TP/IPSec VPN Client".

As far as I know, there is still no Microsoft client for Windows 3.x, Windows NT 4.0 Server and Pocket PC versions 2002 and older. But there are third-party IPsec clients on the market. For non-commercial use you can download the free PGPNet, but it is is limited to host-to-host connections.

There is however a snag with the free IPsec clients from Microsoft. You can use IPsec only in combination with another protocol called L2TP. It is fairly difficult (2000/XP/Vista) or probably even impossible (MSL2TP, Pocket PC) to get rid of this L2TP requirement. One might say that Microsoft "embraced and extended" the IPsec standard, in true Microsoft fashion. To be fair though, L2TP is currently a 'Proposed Internet Standard' (RFC 2661 ) and so is 'L2TP over IPsec' (RFC 3193). PPTP, on the other hand, is another widely used VPN protocol but it is not an official standard.

The use of the L2TP protocol means that you will have to use an L2TP daemon. Several L2TP daemons are available. I will come to that later. When a Windows L2TP/IPsec client connects to your Linux server, it first sets up an IPsec tunnel to Openswan. Then it uses the tunnel to connect to the L2TP daemon on the Linux server, after which the client can access machines on the internal network.

There is an alternative option if you happen to have a Windows 200x Server. With the L2TP/IPsec client you connect to the Linux IPsec server and then use that IPsec tunnel to connect to the L2TP server of Windows 200x, instead of Linux. Martin Köppe has written a Howto on this. The advantage would be that Microsoft's L2TP server is presumably more compatible with the Windows clients than the Open Source L2TP daemons. Note that with this setup the Windows 200x Server is not directly connected to the Internet: the Linux server is. One might regard this a security advantage. Users are authenticated through PPP against Windows 200x instead of Linux, so you will need Client Access Licences.

Microsoft apparently does not think that IPsec is a good protocol for authenticating teleworkers ("Roadwarriors"). This is a bit odd, because third-party clients (PGPNet, SoftRemote etc.) have absolutely no problem with it. Microsoft's rationale is stated on their website in a VPN FAQ. Basically, they claim that passwords are easier to use than certificates. But I suspect there might be another tactical decision behind this. The L2TP protocol supports additional authentication mechanisms which apparently suit Microsoft better (e.g. authenticating through the Windows logon credentials, which means selling more NT/200x client licences).

Back to Contents

• Download Openswan, L2TP server, PPP server and example scripts/config files.
• Read documentation (including these webpages, Openswan docs, Microsoft docs).
• Use the kernel supplied with your Linux distribution if it supports IPsec. If not, find download a kernel (source) package for your distribution with IPsec support. If none is available, you might need to compile and install one yourself.
  
• Install the Openswan userland utilities for your Linux distribution. If none are available, you might need to compile and install them yourself.
  
• Modify the Openswan configuration files.
• Install the L2TP/IPsec client on a Windows or Macintosh workstation (if not built-in).
• Configure the client to use a Preshared Key ('password').
• Initiate (= "dial") the L2TP/IPsec connection on the client.
• Verify on the Linux VPN server that the IPsec part of the connection is up.
• Download, install and configure L2TP and PPP servers on Linux.
• Adjust your firewall to block UDP port 1701 on the external interface (important!).
• Initiate the L2TP/IPsec connection again on the workstation.
• Verify on the Linux VPN server that now both IPsec and L2TP work.
• (Optional) Repeat using X.509 certificate instead of a Preshared Key.

Back to Contents

Read this part carefully. If you have just started reading this page you don't have to take immediate action. Just keep it in the back of your mind and remember to come back to it when you have got the whole lot working and you are about to hook it up to a hostile network such as the Internet.

5.1.1 Ports to open on the external interface: IPsec

You are probably using a firewall on your VPN server (or in front of it). In that case you will need to adjust your firewall so that the L2TP/IPsec protocol is allowed in.

There are many different types of firewalls on Linux. There are even differences between versions of the same Linux distribution. Many people prefer to use their own custom firewall rules instead of those of the distribution. I'm afraid it is impossible for me to provide specific instructions for each and every type of firewall. See also the FreeS/WAN documentation.

For L2TP/IPsec you need to open the same protocols and ports as for pure IPsec:

• UDP port 500 (IKE)
• IP protocol 50 (ESP)
• UDP port 4500 (NAT-T) - needed if some of your clients are behind a NAT router
  

Note that IP 50 is a protocol, not a port. As you might know, IP has protocols such as ESP, UDP and TCP. The protocols TCP and UDP on their turn have ports such as TCP 80 (HTTP), UDP 500 (IKE) etc.

5.1.2 Ports to block on the external interface: L2TP

You should firewall the L2TP daemon on the external (hostile) interface so that it is not accessible. Or better said: you MUST firewall the L2TP daemon, otherwise you will be taking a huge risk.

So for L2TP/IPsec you need to firewall the following port on all interfaces except ipsec0 (or eth0 if you are using NETKEY instead of KLIPS):

• UDP port 1701 (L2TP)

5.2.1 The listen-addr parameter (KLIPS only)

In addition to firewalling L2TP, here is another suggestion which makes your setup even more secure. This step is described in the following paragraphs. By default the L2TP daemon listens on UDP port 1701. Should your firewall be down (for some reason), the L2TP daemon would be exposed on the external interface. So you do not want anyone to access the L2TP daemon through the VPN server's external interface. What you want is that only IPsec authenticated clients are able to access the L2TP daemon, i.e. L2TP packets should flow through the IPsec tunnel and not directly (unencrypted) between the server and the clients. However, by default the L2TP daemon listens on all interfaces, even on the external (hostile) interface. It binds to INADDR_ANY (for those in the know). Preferably you would like the L2TP daemon to bind to only the ipsec0 interface. Unfortunately, this is not possible. Unlike low-level network applications such as tcpdump and Ethereal you cannot bind the L2TP daemon to a particular interface.

Fortunately, there is a way to bind the L2TP daemon to a particular IP address. Patches are available for two of the major Open Source L2TP daemons (l2tpd and rp-l2tp) which allows the server to bind (listen) to one particular IP address. This listen-addr patch for l2tpd is included in my l2tpd RPM (from version 7jdl and up). To use this patch you add a parameter "listen-addr 192.168.1.98" to the L2TP daemon's configuration file (l2tpd.conf). The daemon will then listen on the IP address 192.168.1.98 (the internal interface in my example configuration).

So now you have an L2TP daemon listening on the internal interface. The daemon cannot be accessed from the external interface, which is good. But the L2TP daemon should be accessible through the ipsec0 interface. This is done by configuring an iptables rule which forwards L2TP packets coming from the ipsec0 interface to the internal interface:

(Where 192.168.1.98 is again the IP address of the internal interface). The rule is deleted with:

Openswan must be running when you execute these lines, i.e. ipsec0 must exist. Alternatively, you could add these extra rules to a firewall script called by Openswan, namely the one specified by the leftfirewall= parameter. See also the FreeS/WAN documentation on this.

5.3 ip_forward

One other security related point to notice is that people often set /proc/sys/net/ipv4/ip_forward to 1 for (VPN enabled) routers, so that packets coming from the IPsec tunnel are forwarded to the internal network. This can be done by adding forwardcontrol=yes to ipsec.conf. However, there are some security implications. Perhaps one or more iptables forward rules could do the same trick, when restricted to certain interfaces. Or you could use iproute2 (advanced routing). This is a bit outside the scope of this document.

5.4 chroot, UML, XEN, SELinux etc.

Both Openswan and l2tpd run as root. For extra security you could try to shoehorn them into a chroot jail or an SELinux policy. Or you could even virtualise your server with Usermode Linux, Xen, etc. I have not attempted to do this but apparently the people at Astaro have managed to run the L2TP/IPsec server in chroot. You could download an evaluation copy and check out how they did it. A commercial product that uses virtualisation to support multiple L2TP/IPsec tunnels is Stinghorn. Red Hat / Fedora appears to have a default SELinux policy but it is for racoon, not Openswan.

Before I dig into the technical details of setting up Openswan with L2TP, let's take one step back. I assume that you are interested in providing remote access over the Internet to your users. Important factors in this are price, security and user friendliness and often you can only pick 2 out of these 3 factors. Several solutions are available, such as:

1. A hardware device (or "appliance") at the client side.
2. PPTP or SSTP, for instance using the clients included with Windows 95 and later, Mac OS and Linux/Unix.
   
3. A remote desktop solution such as Citrix, Windows Terminal Server, pcAnywhere or VNC.
4. An SSL-based VPN, such as SSL Explorer, HOB or Citrix Secure Gateway.
5. Non-standards based Open Source solutions such as CIPE, vtun, tinc and OpenVPN.
6. Non-standards based proprietary solutions such as Hamachi.
   
7. Third-party IPsec clients such as NCP, PGP, SafeNet SoftRemote, SSH Sentinel or TheGreenBow VPN Client.
8. The IPsec client included with Windows 2000/XP/Vista, manually configured to get rid of L2TP.
9. The IPsec client included with Windows 2000/XP/Vista, configured with a free software tool to get rid of L2TP.
10. L2TP/IPsec clients such as Windows 2000/XP/Vista, Pocket PC 2003, Windows Mobile, Mac OS X v10.3+ and the MSL2TP client (Win9x/Me/NT4).

Ad 6.1: These are hardware devices with PPTP/IPsec support such as those from Checkpoint, Cisco, Draytek or Netscreen. Hardware devices are easy to configure for the user (because the system administrator does it for them :-). The hardware box is then handed in person or shipped to the user. Another advantage is that most of these devices also contain a firewall. Security of hardware devices is fairly high. Some hardware devices can be centrally managed. A disadvantage is the price, which tends to be higher when the device has more VPN capabilities. Hardware boxes are also not very portable so they are less suitable for roaming users. Another problem (the classic hardware/software trade off) is that they may be difficult to extend with new features. Many hardware devices only support Preshared Keys (i.e. passwords) and not certificates. But Netscreen and SnapGear do support certificates. If the hardware device only supports Preshared Keys, the user is required to have a fixed IP address, unless the device also supports Aggressive Mode.

Ad 6.2: PPTP is free and easy to use but that's about it, really. PPTP clients are included with Windows 98 and higher. Updates (including a version for Windows 95) are available for free from the Microsoft website. PPTP clients are available for other operating systems as well, including BSD, Linux and Mac. An advantage of PPTP is that it supports NAT-Traversal, i.e. it can get through (most) devices that employ Network Address Translation (NAT). Microsoft claims that PPTP has a "good level of security that is suitable for most companies". Security professionals such as Bruce Schneier think otherwise. A German student managed to crack PPTP passwords in 4 hours. Asleap by Joshua Wright has been extended to crack weak PPTP passwords. The authors of the premier Open Source PPTP implementations PPTPClient and Poptop recommend against using PPTP. Others have found a flaw in Microsoft's PPTP implementation. Even Microsoft now admits that "as a VPN protocol, Microsoft considers PPTP to be non-strategic". Note also that PPTP is not an official Internet standard. It is an 'de-facto industry standard' set by Microsoft. From Microsoft's VPN FAQ mentioned above you might easily get the impression that their PPTP and MS-CHAPv2 protocols are official IETF standards. This is not the case. You can check that on the RFC website. It's even mentioned in the RFCs themselves: "[This RFC] does not specify an Internet standard of any kind". Those two RFCs have never been ratified as official standards. They expired. Quoting the Internet RFC FAQ: "Unscrupulous marketeers and a careless trade press sometimes falsely suggest that every RFC represents a standard, or that all standards have equal weight". PPTP also supports the MPPC compression protocol which is patent encumbered. So is PPTP proprietary? Microsoft says no, but they are not telling the whole story. Microsoft has developed yet another proprietary VPN protocol called SSTP. It is included with Windows Vista SP1 and Windows Server 2008. Other operating systems are not supported. SSTP is based on SSL and should be able to pass through most routers, unlike the GRE protocol used in PPTP which is sometimes blocked by routers.

Ad 6.3: Remote desktop clients and servers often use proprietary protocols (VNC and NX are the exceptions). Effectively, this is "security through obscurity". Security experts generally don't like this concept. There is often little encryption (VNC) or the protocol is vulnerable to a Man-In-The-Middle Attack (VNC, RDP). Prices can also be fairly steep (Citrix, GoToMyPC, pcAnywhere). Again, VNC is the exception because it is open source. Windows Terminal Server (RDP) requires extra client licences (CALs). Remote desktop clients such as VNC and pcAnywhere only support one user per system.

Ad 6.4: SSL-based VPNs are very flexible to set up. In many cases the only requirement is that the user must have a recent browser. The user will have to surf to a certain website and then a special client will be downloaded automatically using Java or ActiveX. This means you will have to maintain and administrate a webserver connected to the Internet. Note that in principle the user can connect from anywhere, even dubious locations such as airport kiosks, Internet cafés etc. Once the client software has been downloaded, the user is presented with a remote desktop (similar to 6.3). In some products, the client will switch to a proprietary protocol (HOB, Windows TS ActiveX). Other products continue to use SSL for the remote desktop part (Citrix Secure Gateway?). SSL is used for downloading the applet and the remote desktop protocol itself. Proprietary protocols may be faster but SSL is a well-understood and open standard, so it is probably more secure than a vendor-specific protocol. Windows Vista SP1 ships with a SSL VPN called SSTP. SSL Explorer is the world's first open-source, browser-based SSL VPN solution. Commercial vendors are Aventail, F5 FirePass, Neoteris and Netilla (server appliance based on Tarantella). A disadvantage is that SSL based VPNs do not support all applications (compared to full blown VPNs such as PPTP/IPsec). For instance, one could argue that Outlook Web Access is also an SSL based VPN but you can use it only to access Exchange Server. Another disadvantage is that you will have to secure the special website and keep it locked down. Or, if you use an appliance, you better not forget to install security updates from the vendor.

Ad 6.5: There are also some other non-standards based Open Source solutions such as CIPE, vtun, tinc and OpenVPN. OpenVPN seems to be promising (based on OpenSSL, runs in user-space, is relatively lightweight, supports compression, simple-to-use and runs on 7 different OS's including Windows) but the others have serious security problems, according to security expert Peter Gutmann.

Ad 6.6: There are a few proprietary solutions of which Hamachi is an example. Hamachi is freeware and claims to be very easy to use ("zero-configuration"). It even works without change when both sides of the VPN are behind NAT. Although the makers of Hamachi have released some details about its protocol, it is still proprietary and a trade secret and thus has not seen any peer review by professional cryptographers. Source code is not available so you cannot fix bugs yourself, or add any new features and when there is no version for your operating system of choice, you are out of luck. Hamachi uses a central "mediation" server operated by the makers of Hamachi. All clients regularly communicate with this server.

Ad 6.8: By default, the IPsec clients included with Windows 2000/XP/Vista, Pocket PC and Mac OS X v10.3+ can only be used for tunnelling L2TP. You might want to get rid of L2TP, so that you don't have to install an L2TP daemon on your Linux server. This leaves you with 'pure' IPsec. Unfortunately, this is very difficult to do manually. You can find an example for Windows 2000 Professional on the Snapgear website. This is hardly user friendly by anyone's standards. As if Microsoft wanted to discourage pure IPsec without L2TP. Another drawback is that you will need Administrator privileges to change the IPsec settings using MMC. Note also that this VPN option is only available for Windows 2000, XP and Vista. The MSL2TP client and Pocket PC cannot be configured for IPsec without L2TP (as far as I know). In other words, if you have Windows 9x/Me/NT or Pocket PC, you will have to choose one of the other VPN options, possibly buying a third-party client (see option 5). This means you will have to support not one, but two different VPN options...

Ad 6.9: Fortunately, there are tools (wrappers around the built-in IPsec client). Two popular tools are available: the Linsys IPsec Tool (lsipsectool) and IPSEC.EXE by Marcus Müller. They do the configuring for you when you want to use Windows 2000/XP without L2TP. Like the previous VPN option, Administrator privileges are required to run the IPSEC.EXE utility, but you can get around this if you are prepared to run IPSEC.EXE as a Service (see this post by Uwe Knop). You will have to distribute the Linsys tool or the IPSEC.EXE program to your users, together with a configuration file and the user's private key and certificate. The configuration file resembles a Openswan config file, so you could even generate it on your Linux server. Nate Carlson has made an excellent webpage with instructions on using Windows 2000/XP with Openswan. There are also several graphical front-ends for the IPSEC.EXE utility available. There is also a free GUI that works similar to these graphical IPSEC.EXE wrappers: the Securepoint Personal Firewall & VPN Client. If you use Mac OS X v10.3+ instead of Windows, then there are similar programs available as well. Note that the MSL2TP client cannot be used with this option. It cannot be configured to get rid of L2TP, so you'll have the same MSL2TP related problem as with option 6.7.

Ad 6.10: I will go into more details below, as L2TP over IPsec is the main topic of this page. One thing is certain, though: you will have to use an L2TP server on the Linux side.

Back to Contents

Here are the advantages and disadvantages of using IPsec with L2TP.

Pros:

• 'Free': a client is included with Windows or can be downloaded without charge from Microsoft. Mac OS X 10.3+ also ships with a client. Of course, the clients themselves are not really free because you pay for them through your Windows/Mac OS licences. And obviously the clients are not free in the definition of the Free Software Foundation.
• Readily available on the client. A client is installed by default on Windows 2000/XP/Vista, Windows Mobile and Mac OS X v10.3+. On Win9x/Me/NT4, you need to install extra software (requires Dial-Up Networking 1.4 and IE 5.01 or higher).
  
• Fairly easy to use. There's not much to configure, so less to go wrong.
• 'Native' client (i.e. from Microsoft and Apple). Some managers fall for that...
• Secure. IPsec is generally considered a secure VPN protocol. More so than PPTP, for example. L2TP is a not a strong VPN protocol but the L2TP packets are encapsulated within IPsec anyway.
  
• Supports 'Virtual IP addresses'. This means that the remote client will get an IP address from the internal network once it has logged on. To other computers it will seem as if the remote client is on the internal network.
• Supports TCP/IP and IPX tunnelling. With L2TP you are creating a layer 2 tunnel, so in theory any layer 3 protocol can be tunnelled. In most cases, however, TCP/IP will be used within the VPN tunnel. IPX is reported to work as well (not tested by me). The Microsoft clients support NetBEUI but pppd does not, so NetBEUI will probably not work.
• L2TP over IPsec is an official IETF standard. (RFC 2661). This means that the protocol is fully documented and supported by multiple vendors. Similar VPN related schemes such as PPTP, SSTP, MPPE, L2sec and OpenVPN are no official standards. Some are closed source and undocumented, which is generally frowned upon in the security community.
• NAT-Traversal. Most of the IPsec clients support this (but in some cases an update is needed, for instance Windows 2000/XP). More information below.

• Possibly difficult to install on the server. L2TP/IPsec may be easier to use on the client, but the trade-off is that it is more difficult to install on the server than either PPTP or pure IPsec. However, this largely depends on your skill set and your choice of Linux distribution.
• Fewer features. AES encryption, for example, is only supported on Microsoft Vista, Mac OS X and some commercial clients. AES is considerably faster than 3DES. It is not supported by Windows 2000/XP.
  
• Support. Who can you call for support on the clients? Microsoft? Microsoft resellers? There are Openswan and l2tpd mailinglists with very helpful people, but if you bump into a bug in a Windows client, only Microsoft can fix it. There are companies such as Astaro and Xelerance that provide support on their Linux VPN products.
  
• Requires an L2TP server. Openswan provides an IPsec server but you will also need an L2TP server. Several implementations exist but they are not widely used on Linux/Unix.
• Requires certificates. Unless all your clients have fixed IP addresses, you will need X.509 certificates. In other words, you need a Public Key Infrastructure (PKI). PPTP on the other hand only requires passwords.
  
• Not much experience available. The combination of IPsec with L2TP is fairly new on Linux. There are probably few people using this setup at the moment. There is a relatively active community on the Openswan mailinglist. As far as I know there is also not much information online except for these webpages and the Microsoft documentation. However, several commercial vendors are using this setup, so professional support is available if you need it, including support from Xelerance, the authors of Openswan.
  
• Uncertain upgrade path. I am not aware of any long term roadmap by Microsoft. Windows Vista supports new features such as AES but the IPsec client shipped with Windows 2000/XP has not been updated since June 2003.  The MSL2TP client for Win9x/NT/Me is basically a version 1.0 client and it will not be updated.
• Packet overhead. The payload traffic gets encapsulated a couple of times (IPsec, L2TP, PPP). This requires more bandwidth. It could also result in a problem with MTU size. If I'm not mistaken, 'pure' IPsec has an overhead of 56 bytes per packet. L2TP will add an extra 16 bytes per packet. If NAT-Traversal (IPsec encapsulated in UDP) is used the overhead will be even larger. I have not done any extensive performance evaluations. (Here is one report by a user). The 16 byte overhead is especially apparent if IP is the only protocol you want to tunnel, which is usually the case. Pure IPsec does not have this extra L2TP/PPP overhead. Note that if you want to tunnel IPX over the Internet, you cannot avoid this overhead.
• Slower. The L2TP and PPP protocols require extra daemons on the Linux server. These daemons currently run in user mode. This means extra processing overhead and more latency. I have not done many measurements, but on an ADSL line the line speed seemed to be the bottleneck, not the VPN. If you run the VPN over a LAN, the VPN is the bottleneck. On my (crappy old) hardware, adding pure IPsec seemed to halve the throughput, and when l2tpd was added it seemed to halve again. (If you have done some more elaborate benchmarking, let me know).
• Complicates things for non-Microsoft/non-Apple clients. L2TP on top of IPsec makes life easer for the native Windows clients and Mac OS X clients but not all third-party IPsec clients support L2TP. For instance, if you also have Linux users, it would be silly to ask them to run an L2TP client. It would also mean more work for you too because you would have to provide support for not one, but two different VPN options, i.e. IPsec with and without L2TP.
• NAT-Traversal with L2TP/IPsec is currently experimental on Linux. Some NAT configurations are currently not supported by Openswan. NAT-T has been ratified by the IETF (RFC 3947) but most vendors have only implemented older draft versions.
  
• No "Perfect Forward Secrecy". PFS is a security feature that can be enabled for IPsec connections but the Windows and Mac L2TP/IPsec clients do not support it (unless the user manually creates an IPsec policy, which is user unfriendly and error prone, or unless Vista is used from the command-line which is user unfriendly, too).
  
• Patent issues. Cisco has a U.S. patent claim on the L2F protocol. L2TP is essentially Cisco's L2F and Microsoft's PPTP merged into one. Cisco has a patent on L2TP as well. It is licensed under "Reasonable And Non-Discriminatory" (RAND) terms which may be not that great as it sounds. However, according to people in the know, it is not to be expected that Cisco will seek royalties. There are also patent claims on NAT-Traversal as well, by several companies (some even mutually exclusive?). Note that this patent issue may only affect you if you are in the United States, Japan or another country with silly software patent laws.
  

Back to Contents

• One Preshared Key (PSK) shared by every user
  
• RSA authentication
  
• Multiple Preshared Keys with Aggressive Mode
• XAUTH
• DHCP-over-IPsec
• IKEv2
  
• X.509 certificates
  

A Preshared Key is a secret password that is shared by both sides of the IPsec tunnel. Preferably, the PSK is distributed 'out-of-band', i.e. not over the hostile network (read: the Internet). For instance, you could meet the user face to face and hand him the PSK on a piece of paper. PSKs are fairly simple to use, but they do not scale very well with the number of users and if you want to use a PSK in a Road Warrior setup, all users with dynamic IP addresses will have to share the same PSK ("group secret"). This is of course a significant security risk: if one user leaves the company or loses his laptop, all the other users will have to get a new PSK. The alternative would be to give every user a different PSK, but this is only supported in IPsec if all users have fixed (= static) IP addresses. Because of this limitation PSKs are generally not used in Road Warrior setups, unless there is only one user or everyone has a static IP address (e.g. home workers with cable or ADSL).

With RSA authentication you specify the raw RSA public key of the user in the Openswan configuration. RSA authentication supports both static and dynamic IP addresses. RSA authentication is also relatively light-weight to implement and almost as easy to use as a password. RSA keys have the advantage that they are inherently more secure because passwords can be guessed. Unlike passwords, RSA keys cannot be remembered by the user. They will have to be cut and pasted into the configuration. Unfortunately, none of the IPsec clients that support RSA authentication seem to support L2TP/IPsec, and vice versa.

Some IPsec clients support Aggressive Mode. This allows them to use PSKs with dynamic IP addresses. Especially clients for devices with relatively little processing power such as Pocket PC and Palm use Aggressive Mode, because RSA encryption is much slower than symmetric key encryption. There is a patch for FreeS/WAN that adds support for Aggressive Mode. This patch is also included with Openswan 1.x and SuperFreeS/WAN. The trouble with Aggressive Mode is that security depends on the strength of the password itself (PPTP has the same problem). There are programs such as IKEcrack and Cain&Abel that attempt to crack the Preshared Key from intercepted sessions, as explained by Michael Thumann.

XAUTH (Hybrid Mode) is an extension to IPsec that was never ratified by IETF because it required changes to the (already complex) IKE standard. Cisco seems to be a big XAUTH proponent. XAUTH is not supported by FreeS/WAN or strongSwan, but there is an implementation in Openswan (disabled by default; requires a recompile). Philippe Sultan demonstrates that the XAUTH username and password can be obtained using a spoofed server if the Preshared Key is already known. That Preshared Key can be obtained through brute-force cracking (as mentioned in the previous paragraph) or by copying from the client itself (disk or memory). A solution to this problem is to switch to Cisco's Mutual Group Authentication (server certificates and client passwords; currently only available for Cisco VPN Concentrators, not IOS) or to use certificates (requires client passwords and both client and server certificates, but the client certificates can be 'junk' so a full PKI can be avoided).

DHCP-over-IPsec is supported by Openswan but there is very little client support. The only Windows client is currently SSH Sentinel but this product has been discontinued. (Note: this is not the same as DHCP Inform, which is essentially DHCP-over-PPP-over-L2TP-over-IPsec).

IKEv2 is a successor to the current IKE. It will support 'legacy' authentication modes such as passwords through EAP. IKEv2 is expected to become the main standard. StrongSwan already supports IKEv2 and other implementations are under development.

X.509 certificates are supported by almost all L2TP/IPsec clients. Openswan supports it too, courtesy of a patch by Strongsec. Certificates are generally considered the way to go for Road Warriors. The disadvantage is that you will need to set up some kind of Public Key Infrastructure (PKI), which may be an administrative burden. You need to generate, distribute, revoke etc. the X.509 certificates for the Openswan host and the L2TP/IPsec clients. More information can be found in this section on certificates.

Other IPsec authentication methods such as AuthIP, CRACK, HYBRID, Kerberos and PIC exist as well, but currently there are no implementations available for Openswan or any other Linux IPsec implementation (as far as I know).

Back to Contents

Here are the components to be used at the server side.

• Linux kernel. A fairly recent version is required, e.g. kernel 2.4.18 or higher, kernel 2.6.11 or higher. The 2.6 kernels contain NETKEY, a native IPsec implementation.
• Openswan or strongSwan. If you can, try to avoid Openswan 1.x (or use at least version 1.0.6) because 1.x is no longer supported by the Openswan team. Preferable use Openswan 2.4.x+. For strongSwan, use at least version 2.1.3. (That's because older versions of Openswan and strongSwan contain a vulnerability). If you prefer to use the discontinued FreeS/WAN (which is not recommended because security bugs will not be fixed) you should avoid versions 2.0, 2.01, 2.02 and 2.06. This is because Transport Mode (a requirement for L2TP/IPsec) has been removed from FreeS/WAN v2.06. The FreeS/WAN versions 2.0, 2.01 and 2.02 contain a bug in the SHA-1 hashing algorithm which leads to problems with some clients, most notably the MSL2TP client. FreeS/WAN 2.03 and lower are not compatible with NETKEY. On FreeS/WAN 2.x you may need to disable Opportunistic Encryption (OE). Openswan and strongSwan ship with OE disabled by default.
• Strongsec's X.509 certificate patch. This is a very popular add-on for FreeS/WAN. Openswan and strongSwan already contain this patch. Only if you use FreeS/WAN, you need this patch. In that case, make sure you use at least version 0.9.40 or version 1.6.1 of the X.509 patch.
  
• Optional (but strongly recommended for FreeS/WAN versions below 2.00): the Delete/Notification patch. It is already included in Openswan and strongSwan.
  
• Optional: Mathieu Lafon's NAT-Traversal patch. For more information, read this.
• Recommended if you use MSL2TP clients: JuanJo Ciarlante's patch for FreeS/WAN. For more information, read this. Openswan and strongSwan already contain this patch.
• An L2TP server. I myself used l2tpd-0.69 but several other L2TP daemons are available. I had to use extra patches from the l2tpd mailinglist and create some patches myself. Vanilla 0.69 will not work. These patches are included in my l2tpd RPM. A version 0.70 is long overdue (the Debian people created one themselves).
• A PPP server. One should be included with your distribution. I used ppp-2.4.1 but 2.4.2 should be fine as well. You also need to enable PPP support in your Linux kernel (most distributions already do).
  
• Configuration files for Openswan, l2tpd and pppd. These are included in my l2tpd RPM. Also available is a tarball which contains these configuration files.

Red Hat 9 and previous versions are no longer supported by Red Hat. Fedora 4 and previous version are also  no longer supported by the Fedora Project. The Fedora Legacy Project has been discontinued so there are no more security updates for these old versions. There are also other alternatives if you use an old Red Hat version. MandrakeLinux 10.0 and older are no longer supported by Mandriva. SuSE 8.0 and older are no longer supported. Obviously it does not make much sense to run a VPN server on an old distribution with unpatched vulnerabilities. The VPN part may be highly secure but it won't help much if you are using, say, a vulnerable kernel. This means that I won't be releasing updated RPMs for Mandrake 8.x and Mandrake 9.0. (Also from a practical standpoint: they simply had to make room for newer distributions on my systems). Of course you should be able to compile the Source RPM yourself if there is no RPM available for your distribution.

FC 2 and later (and quite possibly also RHEL) do not contain 'Legacy (BSD) PTY support' (CONFIG_LEGACY_PTYS=y), in contrast with previous FC and Red Hat versions. You will need to use l2tpd RPM version 11jdl or later. These versions use the new(er) Unix98-style pty system instead of the legacy BSD-style pty system. L2tpd version before 11jdl will not be able to start pppd and abort with the error message "getPtyMaster: No more free pseudo-tty's". An alternative is to switch from l2tpd to another L2TP daemon such as rp-l2tp.

If you use Red Hat Enterprise (RHEL) or clones such as CentOS, Lineox, Tao Linux, Whitebox Linux or X/OS Linux then I don't have much advice because I do not have these installed myself. It seems that they use the backported NETKEY implementation for kernel 2.4. Openswan RPMs for RHEL are available on the Openswan website.

According to Paul Wouters of the Openswan team, RHEL 3 (and its derivatives such as CentOS 3) "is the worst choice for a kernel for IPsec related matters" because its kernel is a 2.4 / 2.6 hybrid. You are better off with RHEL 4+ or Fedora.

9.1.2 SuSE / Novell

Novell (SuSE) was a sponsor of Openswan development. SuSE kernels already contain IPsec support, either through NETKEY or KLIPS. But SuSE employee Kurt Garloff has made source and binary RPMs for several versions of SuSE. They contain more IPsec related patches than SuSE's official kernels. Some of Kurt's KLIPS based kernels also contain the NAT-T patch. Alternatively, Openswan RPMs are available on the Openswan website.

9.1.3 Mandriva / Mandrake

The 2.6 kernels included with Mandriva 2005-2006 and Mandrake 10.x contain the native NETKEY implementation. FreeS/WAN 2.04 is included with Mandrake 10.0 and FreeS/WAN 2.06 is included with Mandrake 10.1, Mandrive 2005 (=10.2) and 2006. Unfortunately, FreeS/WAN version 2.06 cannot be used for L2TP/IPsec because Transport Mode has been removed. Openswan and strongSwan RPMs are available in the Mandriva Cooker / contrib directory. If you don't want to use FreeS/WAN or one of its successors, you can use racoon from ipsec-tools instead. Mandrake 10.0--10.2 also ship with a SuperFreeS/WAN RPM but it is based on FreeS/WAN 1.99 so it is utterly useless because that version of FreeS/WAN does not support NETKEY. Unfortunately the openswan RPM in Cooker has a dependency on the ipsec-tools RPM. That RPM will install and run (the competing IKE daemon) racoon by default. That means you will have to stop racoon (service racoon stop) and remove it from the startup scripts (chkconfig --del racoon) before you install the Openswan RPM.

The stock kernel included with Mandrakelinux 10.1 (and probably Mandriva 10.2 as well) does not contain 'Legacy (BSD) PTY support'. This is the same problem as with Fedora Core 2 and 3. This means that you will have to download l2tpd RPM version 11jdl or later. Or you will have to switch to another L2TP daemon such as rp-l2tp.

The stock kernels included with Mandrake 9.x contain KLIPS and the X.509 patch. A FreeS/WAN RPM is also included. This should in theory be sufficient to get you started. In practice however, there are some problems. The current kernel for Mandrake 9.2 at the time of this writing is kernel-2.4.22.28mdk. Unfortunately that kernel contains FreeS/WAN 1.99.8 but the userland utilities are FreeS/WAN 2.01 (freeswan-2.01-1mdk.i586.rpm). So there is a mismatch and it will not work. You could try to compile the Openswan RPM from Mandrake Cooker. Mandrake 9.1's kernels for x86 are broken (kernel-2.4.21.0.13mdk...0.19mdk). There is a workaround, however. Kernel-2.4.21.0.24mdk for x86 is OK. And Mandrake 9.1's kernels for PowerPC are also OK. The current kernel for Mandrake 9.1 at the time of this writing is kernel-2.4.21.0.28mdk. That kernel contains FreeS/WAN 2.00 but unfortunately the userland utilities are still FreeS/WAN 1.99, so it does not work. Mandrake 9.0 uses a fairly old version of the X.509 patch (be sure to avoid using special characters in certificate names!).

Mandrake 8.1 and 8.2 contain older versions of FreeS/WAN without the X.509 patch. The stock kernels included with 8.1 and 8.2 will not work with L2TP/IPsec because the X.509 patch is required. That means you should either upgrade your kernel or upgrade your Mandrake. Upgrading to a more recent Mandrake version is highly recommended. Should you still want to use Mandrake 8.x, you can find newer kernels here. You will also need an update for the FreeS/WAN user mode utilities (normally called freeswan-x.xx.rpm). I could not find these in the official updates but I did find a version 1.98 on Mandrake Cooker at rpmfind.net. Unfortunately (again), the latest Mandrake 8.x kernels contain older FreeS/WAN versions than 1.98 so there is a mismatch.

Only Mandrake 9.2 contains the "Delete/Notification" patch and the 'malformed payload' patch. But if you use an older Mandrake version it can be fixed.

9.1.4 Debian / Ubuntu / Knoppix etc.

Debian's "unstable" and "testing" distribution contain freeswan-modules-source and openswan. Simply run the command 'apt-get install openswan' in install the Openswan .deb file. Most of Debian's 2.4 and 2.6 kernels ship with NETKEY support. If you want to build a kernel yourself, you may need to install the kernel-headers, kernel-package, debianutils and fakeroot packages.

Debian ships with l2tpd, xl2tpd and l2tpns. There is a bug in recent versions of xl2tpd which results in a kernel Oops on Ubuntu 7.10 if AppArmor is running (which is the default). You'll have to either disable AppArmor (perhaps only for xl2tpd?), downgrade xl2tpd, change to another L2TP daemon or wait for this bug to be fixed.

9.1.5 Slackware

Derek T. Murphy has released (unofficial) kernels with FreeS/WAN support.

9.1.6 Gentoo

Openswan and strongSwan packages are available for Gentoo. Gentoo specific information can be found on the Gentoo forum and on this webpage by Brett Curtis. See also the Gentoo Wiki on the Openswan website.

You probably have to compile the kernel yourself, if there are none available on rpmfind.net or other sites.

9.2.1 The X.509 certificate patch

The X.509 certificate patch by Strongsec adds support for variable IP addresses to FreeS/WAN. Openswan and strongSwan already contain this patch. In addition to X.509 support, the patch provides another feature which is vitally important to L2TP/IPsec. L2TP/IPsec clients want to restrict the IPsec tunnel so that only UDP packets (=IP protocol 17) are tunnelled. The standard version of FreeS/WAN can not make such restrictions. Vanilla FreeS/WAN wants to encrypt all protocols between itself and the other party, not just the L2TP traffic. Openswan, strongSwan and the X.509 certificate patch for FreeS/WAN support two parameters that solve this problem: leftprotoport and rightprotoport.

    leftprotoport=17/1701
    rightprotoport=17/1701

However the original (non-updated) L2TP/IPsec client included with Windows 2000/XP requires these parameters which seem to be a mistake (or at least an inconsistency) by Microsoft because no other vendor uses them):

    leftprotoport=17/0
    rightprotoport=17/1701

Mac OS X 10.3.x+ clients require yet another configuration because they use a 'floating' UDP port. Fortunately, this configuration also covers the rightprotoport=17/1701 mentioned above:

    leftprotoport=17/1701
    rightprotoport=17/%any

    leftprotoport=17/1701
    rightprotoport=17/0

Only recent versions of the X.509 patch (e.g. 1.4.8+ for FreeS/WAN 2.x and 0.9.37+ for FreeS/WAN 1.99) can actually restrict the IPsec connection to the specified protocol and port. Older versions of the X.509 do support the left/rightprotoport parameters but they can not enforce those restrictions. They will accept the protocol 17 (UDP) / port 1701 (L2TP) restriction but still happily send all other traffic (ICMP, HTTP, SSH etc.) through the IPsec tunnel, ignoring the restriction.

9.2.2 Protocol tunnelling problem

If you don't use the X.509 patch there will be an interoperability problem between the L2TP/IPsec clients and FreeS/WAN (reported by Jason A. Pattie, among others). An IPsec connection can not be set up because FreeS/WAN complains:

 "peer client ID payload ID_IPV4_ADDR specifies protocol 17; we only support 0"

If you get this error then you will have to apply the X.509 patch to the FreeS/WAN userland programs.

9.2.3 "Delete/Notification" support

FreeS/WAN versions below 2.00 ignore "Delete/Notification" messages. Mathieu Lafon has made a "Delete/Notification" patch for FreeS/WAN which contains support for these messages. Openswan, strongSwan and FreeS/WAN versions 2.00 and higher already contain this patch.

A client may want to inform the server that it has taken down the IPsec connection. It may do so by sending a "Delete SA" message. If the server does support "Delete SA" messages, it simply ignores them and the IPsec connection may time out. In the mean time however, a client could of course reconnect to the server. The server then gets confused about the packets it receives. It thinks the packets are for the old connection, whereas the client is convinced it has a new IPsec connection. Mathieu Lafon's "Delete/Notification" patch fixes this. Note that if the client crashes or if the Internet connection breaks down, the client does not get a chance to send a "Delete SA" message. In that case, the server will time out, with or without the "Delete/Notification" patch. For more information on this issue, see this document by FreeS/WAN team member Henry Spencer. The "Delete/Notification" patch seems especially useful for the MSL2TP client (see this paragraph). (Note: the MSL2TP client seems to send each "Delete SA" message twice. The first message will normally remove the SA so the second one will result in a harmless "ignoring Delete SA payload" message).

Dominique Cressatti wrote in private correspondence that the "Delete/Notification" support is required if you want the connection to last for more than a few hours.

Mandrake RPMs lack "Delete/Notification" support. Also missing is the 'malformed payload' patch which is recommended for use with the MSL2TP client. I added these two patches to the original RPM (the modified RPMs have been signed with my PGP key). Again, I do not recommend using outdated and unmaintained versions of Mandrake, but here they are anyway:

   Mandrake Cooker original:  freeswan-1.98b-1mdk.src.rpm
   Modified 8.1/9.0 source:   freeswan-1.98b-2jdl.src.rpm
   Mandrake 8.1 binary (x86): freeswan-1.98b-2jdl.i586.rpm (please read this)
   Mandrake 9.0 binary (x86): freeswan-1.98b-2jdl.i586.rpm (please read this)
   Mandrake 9.1 original:     freeswan-1.99-3mdk.src.rpm
   Modified 9.1 source:       freeswan-1.99-4jdl.src.rpm
   Mandrake 9.1 binary (x86): freeswan-1.99-4jdl.i586.rpm
   Mandrake 9.1 binary (PPC): freeswan-1.99-4jdl.ppc.rpm

   You may need to hold the 'Shift' key while clicking these links!

Back to Contents

Once you have a kernel with IPsec support, you will need to configure one or more IPsec connections. (If you use FreeS/WAN, don't forget to disable Opportunistic Encryption first).

The examples in the Openswan documentation assume that "Roadwarrior" clients want to make "host-to-subnet" IPsec connections. I assume you want to do this as well. In other words, you want users to have access to an (internal) subnet protected by a Openswan gateway. In 'pure' IPsec (i.e. without L2TP) you do this using the left/rightsubnet keyword.

The Openswan documentation does not cover L2TP/IPsec connections. In L2TP/IPsec the user also wants to access the subnet, but the mechanism to achieve this is different. First, you specify a host-to-host IPsec tunnel between the Windows/Macintosh client and the Openswan server. Once this IPsec connection is up, the client connects to the L2TP server on the Openswan server. The L2TP server then forwards the packets to the internal subnet. In pure IPsec, Openswan does the forwarding itself.

10.1 Preshared Keys overview

Most L2TP/IPsec clients support two kinds of authentication methods: X.509 certificates and Preshared Keys (PSK). I suggest you try PSKs first, get an understanding of how IPsec works with the L2TP/IPsec clients and then switch to certificates if you need them.

10.1.1 Preshared Key: configuration an IPsec connection

Here is an example Openswan configuration file (included in my l2tpd RPM). It defines an IPsec connection for one user. Note that if you want to use this configuration you will have to add it to your ipsec.conf file (or add the following parameter at the end of your ipsec.conf file: include L2TP*.conf).

As you can see, the configuration is relatively simple. Note the absence of leftsubnet and rightsubnet, as explained above. A convention followed by many people is to use "left" for the server ("local") and "right" for Road Warriors. Recent versions of FreeS/WAN, Openswan and strongSwan support the use of "right=%any" for Preshared Keys as well as certificates.

Note: by default my example configuration files are not activated by default (for security reasons). You will have to change auto=ignore to auto=add if you want to enable them.

10.1.2 Specifying the Preshared Key

You enter the Preshared Key in /etc/ipsec.secrets following the FreeS/WAN guidelines. On Mandrake the path can be /etc/freeswan, /etc/ openswan or /etc/strongswan. Nothing much to it. For instance:

10.2 Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) provides extra security. When you enable PFS, your adversaries (hackers, competitors, law enforcement, the mob etc.) cannot decipher packets previously sent through the IPsec connection, even if they eavesdropped on the encrypted connection and they have your secret key (through hacking, court order, escrow etc.). This property of PFS is also known as "escrow-foilage".

As you can see in the example above, there is a line:

         pfs=no

This parameter is required because Apple's and Microsoft's L2TP/IPsec clients do not enable PFS. Openswan, on the other hand, enables PFS by default. (One could only speculate why PFS is not used by Apple and Microsoft as a default. Is it because of the <insert your favourite 3-letter government agency>?).

The easiest way to solve this interoperability problem is to disable it explicitly in Free/SWAN. But this is what the FreeS/WAN team says about it:

"The FreeS/WAN default is [pfs=yes]. We see no reason not to; this is more secure and costs little. The PFS settings on the two ends must match. You can turn PFS off in FreeS/WAN with the  pfs=no   setting in ipsec.conf(5), but if possible we suggest you enable PFS on the other end instead. That is more secure".

Note that Openswan will use PFS when the client asks for it, even when pfs=no is specified in the Openswan configuration. Openswan will ignore the pfs=no for that particular client because PFS is more secure and if the client supports it, why not use it? So pfs=no allows you to connect with clients that are configured with or without PFS.

In short, if you see the following error in your Openswan logs:

     "we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION"

...the simplest solution would be to add the line   pfs=no  to your Openswan configuration.

Back to Contents

I assume that you have configured Openswan at this stage. Now it is time to install and configure the L2TP/IPsec clients. This depends on the type(s) of clients you use (Windows 2000/XP/Vista, SoftRemote, Mac OS X 10.3+, Pocket PC etc.). See the list of clients at the top of this page.

After you have configured your client(s), you can use it to initiate the VPN connection. It will first try to set up an IPsec connection and then an L2TP connection.

Back to Contents

Initiate ('dial') the VPN connection. The procedure for this depends on the type of client (see the previous section). The client will report an error ("The computer you are dialling is not responding" or something similar). The error is correct: you do not have an L2TP server yet so just ignore the error for the moment.

The IPsec connection should come up successfully, though. You can check that in the Openswan logfile (normally /var/log/secure) which should look similar to this:

If you see this, congratulations! You've got the IPsec part nailed. Continue with the L2TP part below. If not, check your configuration or go to 'Troubleshooting'.

Back to Contents

The IPsec connection you just configured is to be used for tunnelling the L2TP protocol (L2TP over IPSEC is defined in RFC 3193). L2TP on its turn will tunnel PPP and PPP is to tunnel the actual payload. This means you will need an L2TP server on your Linux system. I am aware of the following open source implementations:

• l2tpd: originally by Mark Spencer, Jeff McAdams and others (project webpage previously at http://www.marko.net/l2tp/ and http://www.l2tpd.org). Now maintained by Damion de Soto and Robert Vogelgesang, but development seems to have stalled. Included with Debian/Ubuntu and Mandriva.
  
• xl2tpd: a version of l2tpd by Xelerance, the main authors of Openswan. In active development. xl2tpd is included with Fedora and Debian/Ubuntu. The upcoming version 1.2.x is expected to support the PPPoL2TP module (CONFIG_PPPOL2TP) that is included in Linux kernel 2.6.23+. Data packets will then be processed by the kernel (fast!), only the control messages will be processed by the userland daemon.
• rp-l2tp: an L2TP server implementation by Roaring Penguin, of rp-pppoe fame. Development has stalled.
  
• OpenL2TP: already supports the PPPoL2TP module in Linux kernel 2.6.23+. A patch is available for older kernel versions, which requires (re-)compiling the PPPoL2TP module for those kernel versions. Binary RPMs are available for some distributions. When used with Openswan or ipsec-tools (racoon) OpenL2TP has been tested with several L2TP/IPsec clients and servers including Windows 2000/XP, Mac OS X and Draytek. It has also been tested with a Cisco 3600 router and a commercial IXIA network protocol tester in configurations without IPsec. In active development.
• l2tpns: this is an L2TP server with an integrated PPP server by Optus Internet Engineering. The functionality of the PPP server is limited, compared to pppd. Unlike l2tpd, it cannot be used as a client, only as a server. "l2tpns does not require pppd or any kernel patches. It can support up to 65535 active sessions on a single box. Also supports ISP features like speed throttling, walled garden, usage accounting, and more". An example L2TP/IPsec configuration is provided by Alan Whinery and another one by Wolfgang Hennerbichler. l2tpns is in active development and appears to be the preferred L2TP daemon in Debian/Ubuntu.
  
• l2tp: a kernel-mode implementation. Seems to be defunct, no new versions since January 2002.
• Apple's L2TP client plugin for pppd. I don't know if this one can be used for anything else but Mac OS X (there is also an L2TP kernel extension?). Is the server part from Mac OS X Server available as well?
  
• internet-l2tp: = l2tpd + wrapper scripts in Portuguese?
• sl2tps is a simple, statically configured L2TP server for FreeBSD (alpha quality). It probably won't run on Linux but I am just mentioning it for completeness.
  

1. L2tpd has a simple configuration file called l2tpd.conf which is reasonably intuitive to configure.
   
2. L2tpd runs in user mode so there is no kernel recompilation needed. Recompiling the kernel is often a lot of trouble.
   
3. L2tpd has built-in support for IP pools which means that l2tpd can dynamically assign internal IP addresses from a pool that l2tpd maintains. The other L2TP servers require installation of a RADIUS server to maintain an IP pool.
4. L2tpd uses pppd. This is a well-known PPP implementation which is very complete and has several authentication options and plugins.
   

1. L2tpd runs in user mode and uses pppd, so it is slower than kernel mode L2TP servers.
2. L2tpd is in maintenance mode. No new features are to be expected, but bugfixes and security vulnerabilities will be fixed if reported. There is not a very active user community (older archive).
3. There are some concerns about the code quality and possibly security issues in l2tpd.
   

Dossy Shiobara reports that rp-l2tp works for L2TP/IPsec, which I can confirm. One thing to note is that both l2tpd and rp-l2tp use the same location for their daemon: /usr/sbin/l2tpd. That is very unfortunate but in most cases you will only install one of these two daemons so it should not be that much of a problem. Rp-l2tp seems to have a better code base than l2tpd.

Most of the L2TP daemons (l2tpd is the exception) have the drawback that they cannot assign dynamic internal (virtual) IP addresses by themselves. This is not an issue if you want to assign fixed internal addresses to your users. But this is a problem if you want to assign dynamic IP addresses to users. Three solutions have been proposed: the L2TP servers could be extended so that they hand out IP addresses dynamically. This approach more or less violates the OSI networking layering model but this is how l2tpd does it. Nobody has implemented this solution for the other L2TP daemons (yet). The second solution is to let the PPP server obtain IP addresses from a DHCP server that you already might have on your network. For this to work you need a pppd plugin called ppp-dhcp (for more information read this thread, with additional configuration tips by Ben McKeegan in this thread). The third solution is to use pppd version 2.4.2 or later which supports RADIUS (alternatively, there is a plugin for pppd 2.4.1 by Anton Voronin, see also this post). The RADIUS solution is of course the most flexible but it requires a RADIUS server which adds to the complexity, especially if you have only a few users. Your RADIUS server must support a feature called "IP pools" if you want to use it with PPP (I believe FreeRADIUS does).

Except when you use l2tpns, you will also need a PPP server since L2TP is used to tunnel PPP. Most distributions ship with a PPP server (pppd). No sample PPP configuration files were included with l2tpd, so I made some myself (included with the l2tpd RPM mentioned above). Again, I don't claim that these are the best but they should get you started. Finetuning the l2tpd and pppd configuration and/or switching to a different L2TP implementation may be required for the best results.

According to Wolfgang Hennerbichler, Windows 2000/XP/Vista and Mac OS X also support DHCP in order to retrieve settings such as domain names, static routes etc. from the VPN server. You need a DHCP server that supports "DHCP Informational" messages, such as ISC DHCPD 3.x or higher. Only Mac OS X 10.5 ("Leopard") and Windows 2000/XP/Vista clients support these messages at this time.

Back to Contents

Probably the easiest way to install l2tpd is to get it readily packaged for your distribution.

• Mandrake: there is an RPM in Cooker, the development branch of Mandrake. I have modified Mandrake's RPM and created a new one which can be used with Openswan. You might want to use my RPM listed below, instead of the original.
• Red Hat or SuSE: you can use my RPMs listed below.
• Debian: xl2tpd is in the unstable tree, l2tpd is in the stable tree, and l2tpns is in both. Executing an 'apt-get install xl2tpd' (or likewise for l2tpd) should get you started. Alternative, you can use my RPM processed through alien, as reported by Nicolas Pouvesle:
  
  • apt-get install rpm
  • rpmbuild --rebuild l2tpd-0.69-10jdl.src.rpm
  • alien /usr/src/RPMS/i386/l2tpd-0.69-10jdl.rpm
  • dpkg -i l2tpd-0.69-10jdl.deb
    
• Gentoo: it's in net-dialup.
  
• If you have another distribution that supports RPM, you could try to modify my Source RPM. Please send your changes to me so that I can incorporate them into my spec file.
• If you have a different distribution, you might have to compile l2tpd yourself. Download the l2tpd tarball from the l2tpd website. Also download my tarball (listed below) which contains additional patches. It contains two patches that are mutually exclusive: l2tpd-pty.patch.bz2 and l2tpd-pty.patch2.bz2. Apply only one of these two patches! The second one seems to work better for me, but it may be different for your distribution. Once you have applied the patches, l2tpd should compile by simply typing 'make'. Note that (lacking a startup script for your distribution) you may need to use l2tpd in daemon mode by starting it with the parameter -D.
  

   Source RPM:          l2tpd-0.69-12jdl.src.rpm  (based on the l2tpd version of August 20, 2002)
   Source RPM:          l2tpd-0.69cvs20051030-1jdl.src.rpm  (based on the l2tpd CVS version of Oct 30, 2005)
   Mandrake 10.1 (x86): l2tpd-0.69-11jdl.i586.rpm
   Mandrake 10.0 (x86): l2tpd-0.69-10jdl.i586.rpm
   Mandrake 9.2  (x86): l2tpd-0.69-10jdl.i586.rpm
   Mandrake 9.1  (x86): l2tpd-0.69-10jdl.i586.rpm (no longer updated by Mandrake)
   Mandrake 9.1  (PPC): l2tpd-0.69-12jdl.ppc.rpm  (no longer updated by Mandrake)
   Fedora Core 1 (x86): l2tpd-0.69-10jdl.i386.rpm
   Fedora Core 2 (x86): l2tpd-0.69-11jdl.i386.rpm
   Fedora Core 3 (x86): l2tpd-0.69-11jdl.i386.rpm
   Fedora Core 4 (x86): l2tpd-0.69-12jdl.i386.rpm
   Red Hat 9.0   (x86): l2tpd-0.69-10jdl.i386.rpm
   Red Hat 8.0   (x86): l2tpd-0.69-10jdl.i386.rpm
   Red Hat 7.3   (x86): l2tpd-0.69-10jdl.i386.rpm
   SuSE 9.1:     (x86)  l2tpd-0.69-10jdl.i586.rpm (thanks to Bernhard Thoni)
   Tar ball (v.10jdl) with software, patches, config files (sig)
   Versions no longer supported: SuSE 8.0, Mandrake 9.0, Mandrake 8.1

   You may need to hold the 'Shift' key while clicking these links!

rp-l2tp RPMs by me  (based on the ASP Linux RPM by Alexandr D. Kanevskiy):

   Source RPM:          rp-l2tp-0.4-2jdl.src.rpm
   Mandrake 10.1 (x86): rp-l2tp-0.4-1jdl.i586.rpm
   Fedora Core 2 (x86): rp-l2tp-0.4-1jdl.i386.rpm
   Fedora Core 4 (ppc): rp-l2tp-0.4-2jdl.i386.rpm (l2tpd does not seem to work on FC4-PPC)

The RPMs have been signed with my PGP key. I have built several binary RPMs for your convenience but I recommend you get the source RPM, inspect the SPEC file, download the original tarball and the patches from their original locations, review all source files for backdoors and other security risks and then build the RPM yourself. It's a lot more of a hassle, but security has its price... :-) (At least with open source software you get the chance to inspect the source!). Note that the RPM spec file defaults to Red Hat/Mandrake/Fedora. You will need to set a boole