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 boolean variable for SuSE.

The 'listen-addr' parameter has already been discussed above. By default, l2tpd will listen on all interfaces. The parameter 'ip range' specifies a range of IP addresses on the internal LAN that will be allocated to remote users. With 'local ip' you specify what IP address will be used by the Linux server on pppX interfaces created by l2tpd. Please note: 'local ip' must be an IP address on the internal network (i.e. your intranet). In the example above 'local ip' is 192.168.1.99. You cannot use the IP address of the internal interface for 'local ip', nor can you use the IP address of 'listen-addr' (both are 192.168.1.98 in the example above). 'Local ip' should be a free IP address within the same subnet of the internal interface.

CHAP is enabled and PAP is disabled because otherwise the Microsoft clients will complain that the password is not encrypted (which is of course nonsense because the connection is already encrypted by IPsec). I also had to set 'length bit' to yes, because the connection was unstable without this parameter.

14.1 L2TP authentication and client IP restrictions (not essential)

IPsec supports authentication through Preshared Keys and certificates. PPP also supports authentication e.g. through passwords; see below). It turns out that L2TP also supports authentication. The problem is that you cannot specify those passwords anywhere in the Windows/Mac L2TP clients. I guess none of the vendors thought that L2TP authentication was important. And rightly so, because it does not seem very useful anyway. IPsec and PPP authentication should be enough for anyone.

The confusion comes from the 'require authentication' parameter in l2tpd.conf. This parameter has nothing to do with enabling L2TP authentication. It is actually for PPP authentication (i.e. PAP/CHAP). The Windows clients use this by default, so you should enable PPP authentication by including 'require authentication' in your l2tpd configuration file.

L2TP authentication, on the other hand, can be enabled by specifying the parameters 'auth file' and 'challenge'. But as explained above, normally you do not need L2TP authentication.

l2tpd can also do access control based on IP addresses. This is slightly more interesting than L2TP authentication. However, Openswan already does access control on IP addresses. You could use l2tpd's access control as an extra security measure ('belt and suspenders' approach). There's nothing wrong with that but it only works if you know all the IP addresses of the clients in advance (e.g. they all have fixed IP addresses). This rules out "Roadwarriors" with dynamic addresses. Let's say that you want to restrict l2tpd access to a client with the fixed IP address 234.234.234.234. Then your l2tpd.conf should be extended as follows:

Back to Contents

15.1 PPP authentication: overview

IPsec is used to tunnel L2TP, which on its turn tunnels PPP. Several authentication methods exist for PPP. The most popular ones are PAP (unencrypted passwords) and CHAP (challenge/response based authentication). You are free to choose either one of these but I recommend CHAP. If you use PAP, the Microsoft clients will complain that the password is not encrypted. This is besides the point because IPsec already does encryption. Both PAP and CHAP are IETF standards but Microsoft has 'embraced and extended' CHAP into a new dialect: MS-CHAP (later fixed as MS-CHAPv2).

Windows 2000/XP/Vista clients also support EAP for PPP authentication. This might require a pppd plugin by Michael Heiart which allows you to use a RADIUS server for EAP.

• Use of the "unix authentication" keyword in l2tpd.conf. Accountnames and passwords will then be checked against the Linux user database (/etc/passwd). What it does is add the "login" keyword to the PPP options. Note that you will have to use PAP because (MS-)CHAP cannot be used with pre-encrypted user passwords such as those in /etc/passwd. Accountnames will still have to be specified in /etc/ppp/pap-secrets, but the passwords in that file can be empty strings ("") which will cause pppd to use the Unix password. See man pppd.
• Pppd version 2.4.2 and later includes a RADIUS plugin (radius.so, radattr.so) which allows you to authenticate PPP users against a RADIUS server. This was mentioned above. A sample setup with RADIUS and MySQL can be found on this Poptop webpage. They use PPTP but the same principle can be applied to L2TP as well. Again, if you authenticate against a Unix/Linux back-end server, you may have to use PAP. Alternatively, you can use l2tpns which ships an integrated PPP server and RADIUS support.
• Pppd version 2.4.3 and later includes a Winbind plugin (winbind.so) from Andrew Bartlet of the Samba team, which provides the ability to authenticate users against a Samba or Windows domain controller (Active Directory or NT domains) using MS-CHAP or MS-CHAPv2. Andrew has also released documentation about such a setup. A similar Howto for using MS-CHAPv2, Samba, Kerberos and Active Directory is available from Wing S Kwok. Both authors assume you are using PPTP but for L2TP/IPsec you can use the same procedure. Just skip the PPTP (Poptop) parts and use the regular pppd daemon. Alternatively, you can install a RADIUS server (known as IAS on Windows Server 2003 and NPS on Windows Server 2008) and use it to authenticate users on Windows Server.
  
• Most PPP daemons are now compiled with PAM support. This means you should be able to use all kinds of authentication mechanisms. For instance, instead the Winbind plugin mentioned above you could authenticate with modules such as pam_smb (including pam_smb_auth), pam_winbind or pam_ntdom (discontinued) against Samba or Windows servers.
• To authenticate against an LDAP server, you could use try the pppd-ldap plugin for pppd. Alternatively, there is a pppd patch by Adam Tauno Williams. Or you could use PAM in combination with pam_ldap (see also this Howto). This has not been tested by me. Another setup by Wolfgang Hennerbichler also authenticates against an LDAP server, but it uses RADIUS as an in-between. RADIUS is of course well-supported by PPP. Wolfgang's setup is also based on l2tpns.
  

require-mschap-v2

Less common are:

require-chapms-v2

and:

+mschap-v2

Once the L2TP connection is up, it hands over control to the PPP daemon. Obviously you will need a PPP server. Almost every distribution has one: pppd. Install a recent version, i.e. ppp 2.4.1 or higher. The same PPP software can be used for something else as well (e.g. an analogue modem for dial-up purposes). Fortunately, with the parameter 'pppoptfile' in l2tpd.conf you can specify a separate PPP options file for the L2TP daemon.

Note: The PPP daemon's passwords are shared by all PPP processes, not just the ones started by l2tpd. However, you can restrict the validity of usernames/passwords to certain IP addresses, such as in this example chap-secrets file:

# Secrets for authentication using CHAP
# client        server  secret                  IP addresses
jacco           *       "mysecret"              192.168.1.128/25
*               jacco   "mysecret"              192.168.1.128/25
sam             *       "rumpelstiltskin"       192.168.1.5
*               sam     "rumpelstiltskin"       192.168.1.5

The Microsoft clients have an option "Use Windows logon". If you enable this, the client will want to authenticate with the username "\\DOMAINNAME\username". You will have to specify this username format in chap-secrets/pap-secrets as well.

Configuring the PPP server is not explained here. There is lots of documentation on this subject, for instance the PPP Howto. Check out my sample configuration file /etc/ppp/options.l2tpd included with the RPMs mentioned above.

For simplicity, let's assume that the external interface of your Linux server is eth0 and the internal interface is eth1. The PPP server is to provide the remote user with an IP address from the internal (protected) network. Once the user is connected interface ppp0 will be up. My sample L2TP configuration file l2tpd.conf has a line 'local ip'. With this parameter you specify a dedicated IP address for the L2TP daemon on the internal subnet.

Note that options.l2tpd contains the parameter proxyarp. This parameter will set a proxy arp entry on the internal interface (eth1 in the example above) for the remote user. If this keyword is not specified, packets from the L2TP/IPsec clients will arrive at internal servers but those servers will not know where to send responses to because nobody replies to its ARP requests. With the proxyarp parameter, the machines on the internal network are fooled into sending packets for the remote Windows clients to the gateway. The gateway has IP forwarding on, so it knows how to send the packets through to the Windows clients.

16.2 Issue: specified DNS is ignored

As you can see from the sample PPP options file (/etc/ppp/options.l2tpd), you can specify DNS and WINS servers. Remote clients will pick these up automatically once the connection has been established. Normally you will want remote clients to use the same DNS/WINS servers that clients on the internal network use. However, it seems that a native Windows 2000/XP/Vista client will only pick up these DNS/WINS servers when its Internet connection is configured with a dynamic IP address (e.g. through DHCP or PPP's IPCP). This puzzles me and I don't have an explanation or a workaround for this. It could be that the DNS entry is not updated (check with IPCONFIG /ALL on the Windows client) but that nevertheless the correct DNS server (as specified through the ms-dns parameter) is used.

16.3 MTU problems

If you see PAYLOAD_MALFORMED error or if you have intermittent problems with your VPN connection, it could be an MTU problem. What you might see is that you can ping machines on the internal network and you can surf or transfer very small files, but you can't copy large files because the connection stalls. Then try decreasing the MTU to 1410 (or perhaps even lower?) by adding the following parameter to /etc/ppp/options.l2tp:

mtu 1400
mru 1400

In some cases (especially when certificates are used) fragmentation may lead to a problem with IKE. An extension to IKE has been proposed by Cisco. This extension allows fragmented IKE packets pass through (broken) routers which cause the fragmentation. Openswan does not support this extension but ipsec-tools (racoon) does. Fragmentation is less likely with PSKs. Other options might be to reduce the size of certificates (e.g. by reducing the size of the RSA key, shortening the Distinguished Name fields or removing extended attributes) and eliminating (NAT) devices that don't support fragments.

Another option is to "clamp" the Maximum Segment Size (MSS) of the application protocols that are sent through the VPN. This only works with TCP protocols, not with UDP based protocols.

16.4 Tip for multi-homed DSL users

Most DSL users have a static IP address or a dynamic IP address assigned through DHCP. However, some DSL services use PPP for the Internet connection (e.g. through PPTP or PPPoE). If you have such a DSL service, you often use interface ppp0 for your Internet connection. And when you decide to use an L2TP/IPsec VPN over that Internet connection, the PPP daemon spawned by the L2TP daemon will automatically pick the next free interface name, ppp1.

However, a problem might arise when you have multiple DSL links and one of them goes down for some reason and then comes up again. In the mean time, the PPP interface might have been picked up by an L2TP/IPsec client because pppd detected that it was free. This might screw up several of your settings, for instance, your firewall rules might expect the DSL links on fixed PPP interfaces.

A workaround for this problem is adding the parameter 'unit xxxx' to the PPP options file for your DSL links, where xxxx is a high number, say 1000. Each DSL link will have to have a unique PPP interface (ppp1000, ppp1001 resp.) that does not conflict with the lower PPP unit numbers which are reserved for L2TP/IPsec client (ppp0, ppp1, etc.).

You do need ppp-2.4.2 or higher for this particular 'unit' parameter. The pppd man page says that the parameter only works for outbound connections but it works for incoming connections too (looks like an undocumented feature in pppd?). The 'unit' parameter does not have to be used in /etc/ppp/options.l2tpd, only in the PPP options files of your DSL links. This workaround should work as long as the highest PPP unit number assigned to the DSL links is higher than the total number of clients.

Back to Contents

At this point you should have IPsec, L2TP and PPP configured. Try initiating the VPN connection on the Windows or Macintosh client again. The procedure is the same as described above. But this time the L2TP connection should come up as well. If it does, congratulations, you've got a working L2TP/IPsec setup! If it does not work, check and double check your settings. See also 'Troubleshooting'.

There are two final checks that I highly recommend before you consider rolling out to a live network:

1. Put a third machine between the client and the server. You should be then use that machine to sniff the communication between the client and the server with a network monitoring program such as tcpdump or Ethereal. The packets should be encrypted. If you see unencrypted packets (e.g. plain text L2TP), there is something wrong in your setup.
2. Use nmap (or any other good portscanner) on the client and scan for open UDP ports on the server: nmap -sU 123.123.123.123. You should not see the L2TP daemon (UDP port 1701). The only open ports should be UDP 500 (IKE) and optionally UDP 4500 (NAT-T).
   

Back to Contents

At one time during testing, I forgot to enter a default gateway and a hostname in the TCP/IP settings of a Windows workstation. This was not really a problem since the Linux server was on the local network. However, when I set up a connection from the Windows client to the Linux server, l2tpd complained with a rather cryptic error message in /var/log/messages: "Specify your hostname". At first I thought that perhaps l2tpd could not determine the hostname of the Linux server it was running on. I solved the problem by entering a hostname on the Windows workstation. I simply did not expect that l2tpd relied on it.

Back to Contents

19.1 Introduction

If you don't need NAT-Traversal (or if you don't want to deal with the complications at this moment) you can skip this part.

NAT changes packets on the fly. The problem is that this kind of 'tampering' is exactly what a VPN tries to prevent! Fortunately, some NAT devices support 'IPsec passthrough' which allows IPsec to be used through the device. However, it seems that IPsec passthrough only works for one user at a time, not multiple concurrent users behind the same NAT device. I have not tested L2TP/IPsec through a NAT device with IPsec passthrough myself, but I received a report by Tim Behrsin about 'UDP: bad checksum' problems. Some NAT devices are broken in the sense that you cannot disable IPsec passthrough (the SMC 2804 comes to mind?). Pure IPsec on the other hand has been reported to work with these devices (i.e. Tunnel Mode, not L2TP/IPsec in Transport Mode).

Instead of modifying the NAT device, you could modify the IPsec standard itself. And this is exactly what has happened. Extensions to IPsec are in development so that you can set up IPsec connections through a NAT device without IPsec passthrough support. This is called "NAT-Traversal" (NAT-T) which was published by the IETF as a Proposed Standard, RFC 3947. Openswan versions 1.0.9+ and 2.3.1+ support this RFC. The NAT-T RFC is based on the NAT-T requirements stipulated in RFC 3715. NAT-Traversal works around the NAT problem by encapsulating IPsec ESP packets within UDP (RFC 3948).

This article by Debra Schinder provides some more background information on NAT-Traversal. And these articles by Stefaan Pouseele provide detailed info on the packet structures and mechanisms behind NAT-T.

NAT-Traversal is considered by Mathieu Lafon to be experimental and unsafe if used with L2TP/IPsec (see section 5 "Security Considerations" of the "IPsec within UDP" IETF document mentioned above). Mathieu is one of the people involved with the implementation of NAT-T on Linux. Linux kernel 2.6 contains a different IPsec implementation (NETKEY) which includes also supports NAT-T. Apparently it has the same security issue as the NAT-T patch for Openswan et al. The NETKEY implementation supports racoon (from ipsec-tools) as well as Openswan/ strongSwan/ FreeS/WAN 2.x. Switching to ipsec-tools won't fix the security issue either.

The NAT-T patch for KLIPS currently does not support connections that authenticate through Preshared Keys (PSKs). If you use a Preshared Key with KLIPS and NAT-T, Openswan will not authorise the connection because the sender's port is not 500 and the NAT-T patch fails to support this. This should be looked into by a programmer. PSKs have some drawbacks so generally you want to use certificates anyway. The NETKEY implementation does support PSKs but you will have to use right=%any and use leftid=someservername and rightid=someclientname. If you do specify an IP address with right=a.b.c.d without leftid=someservername and rightid=someclientname, Openswan will complain about "no connection authorized". If you use Windows Vista with a PSK, and NAT is involved, you are required to use rightsubnet=vhost:%no,%priv. This is probably true for other RFC 3947 compliant clients (such as Mac OS X) as well.

If you have multiple clients behind the same NAT device, only the first client will be able to connect. Openswan logs an error similar to this: Virtual IP 10.0.0.1/32 is already used by 'C=NL, ST=ST, L=L, O=TESTORG, CN=TESTUSER' (or ... used by '@Pocket_PC' in the case of a PSK). Another limitation of Openswan is that clients cannot share the same NAT-ed (internal) address. This is of course difficult to avoid completely, especially when there is little coordination between remote clients. Many users will be using the same 192.168.1.101 address if they are using a Linksys router, for instance. These are limitations of Openswan. Patrick Naubert, the CEO of Xelerance, has released this statement on the subject. He writes that they have implemented a solution for KLIPS but they need $55,000 to recoup their costs before they can release the source code. Paul Wouters of Xelerance has said that perhaps a solution is in the works. A number of alternative solutions exist. For example, OpenL2TP with ipsec-tools (racoon) does support multiple clients behind the same NAT device. Another alternative is the workaround by the Finnish company Stinghorn which is based on modifications to the Linux kernel and ipsec-tools. Some more details can be found here.

If you have multiple users behind the same NAT device and one client connects to the Openswan server, the other users behind that NAT device will not be able to set up non-IPsec connections (WWW, SSH etc.) to that server. You can solve this by adding an extra 'passthrough' section to ipsec.conf as described by Paul Wouters of the Openswan team.

NAT-T is supported by almost all of the L2TP/IPsec clients. Windows Server 2003 also supports NAT-T (a test report can be found here). Microsoft has released IPsec updates (MS KB Q818043) for Windows XP and Windows 2000 Professional, as promised. This update is also included with XP ServicePack 2. However it turned out that the NAT-T update had issues with some third-party applications which caught a lot of bad press. So Microsoft had to recall the NAT-T update. In August 2003 they re-released it. The patch can be installed through WindowsUpdate. If you use Windows 2000 Professional, you will need to install ServicePack 3 or higher first, otherwise the IPsec update will not show up in WindowsUpdate. For XP you will need ServicePack1 or higher. If the update still does not show up in WindowsUpdate, go to the Windows Update Catalog and search for "818043" using the Advanced Search Options feature. If you prefer to download the NAT-T update to disk and then distribute it to multiple clients, you can use Windows Update's Download Basket or Software Update Services.

According to posts by Microsoft employees, updates for Windows 2000 Server and ISA Server would become available as well. I had some doubts when I read this because Microsoft would rather see you upgrade to Windows Server 2003 instead. It turns out I was right. Quoting Microsoft (KB Q818043): "NAT-T server-side support will not be added to Windows 2000 Routing and Remote Access". Fortunately this decision by Microsoft will not affect you if you use Linux on the server...

All clients except SSH Sentinel (and possibly Forticlient) automatically detect if NAT-T has to be enabled. SSH Sentinel has to be manually configured to use NAT-T: in the "Properties" window of a VPN connection, select the "Advanced" tab and enable "NAT-Traversal" (Sentinel 1.4 screenshot). Sentinel 1.4 also has a feature called "UDP encapsulation to port xxxx" but that variant is not supported by Linux. You will have to use the other Sentinel option called "NAT-T". Sentinel 1.3 has only one NAT-T variant but that is the non-supported type so you can't use it. Next, click "OK". Don't enable this option in Sentinel if the NAT device itself already supports "IPsec-passthrough". The documentation of SSH Sentinel states that NAT-T cannot be used in combination with IPCOMP, the IPsec compression protocol. This is a limitation of Sentinel itself, not a limitation of NAT-T or IPCOMP.

• Windows XP Home/Professional: requires the IPsec update Q818043 or ServicePack 2. If you are using XP with SP2 and the Openswan server is behind NAT, you need to modify a registry setting.
  
• Windows 2000 Professional: requires the IPsec update Q818043 (this update is not included in any Service Pack for Windows 2000).
• Windows Vista. If the Openswan server is behind NAT, you need to modify a registry stetting. Vista supports RFC 3947, the first Microsoft operating system to do so. If a PSK is used for authentication, you need to add a rightsubnet= line.
• Windows 2000 Server (used as a client): is reported to work but only through an unsupported hack. (The IPsec update Q818043 does not show up on WindowsUpdate for this version of Windows. But what you can do is download the NAT-T patch for Windows 2000 Professional and install that one. This is probably not supported by Microsoft, i.e. it might break your support contract. On WindowsUpdate, go to the Windows Update Catalogue and select "Windows 2000 Professional SP3" and your language version. In the "Advanced Search" options, select "Contains these words: 818043". Add the update to the Download Basket, download and install).
• Windows Server 2003 used as a client: has built-in NAT-T draft-02 support ("draft-ietf-ipsec-nat-t-ike-02"). Does not support RFC 3947.
  
• MSL2TP client connecting to a KLIPS-based Linux server.
  
• SafeNet SoftRemote versions 7.0.5 and 9.2.1 (KLIPS only?)
  
• SSH Sentinel version 1.4.1 build 98 connecting to a KLIPS based server. There is however a problem with disconnecting. Sentinel does not seem to send "Delete SA" packets. Openswan still thinks there is an IPsec connection, so the client will not be able to access services on the external interface of the Linux machine until the IPsec connection times out. (Note: SSH Sentinel has been discontinued, but an upgrade from full version 1.4 to 1.4.1 is still available here).
• Windows Mobile 6, Windows Mobile 5.0 and Pocket PC 2003 connecting with a certificate: works, but only if the certificates are small in size (fragmentation problem?).
• Windows Mobile 6, Windows Mobile 5.0 and Pocket PC 2003 connecting with a Preshared Key to a NETKEY based server.
• Mac OS X 10.4 Tiger: preferably use Mac OS X 10.4.4 or higher because these support RFC 3947. If you still have 10.4.0-10.4.3, use at least Openswan 2.4.5.
  
• Mac OS X 10.3 Panther: get Mac OS X 10.3.6+ and Openswan 2.4.5+. Mac OS X 10.3 only supports PSK authentication. It does not support certificates with L2TP/IPsec.

• Mac OS X 10.5 Leopard.
  
• Windows Mobile based Smartphones. I can create an L2TP/IPsec VPN connection but I don't know how to initiate this connection.
  

• Mac OS X 10.3 Panther connecting to a server that requires certificate authentication. Panther's GUI does not support certificates with the L2TP/IPsec protocol.
• MSL2TP client connecting to NETKEY based server. (Client rejects packets with an "INVALID_SPI" error. Floating port confuses client?).
• Pocket PC 2003 or Windows Mobile connecting with a Preshared Key to a KLIPS based server: the NAT-T patch does not support PSKs on KLIPS.
• SSH Sentinel version 1.4.1 build 98 connecting to a NETKEY based server. (Client rejects packets?).
  
• SSH Sentinel version 1.4 build 177 (discontinued, but evaluation version still available at CyProtect): 'Diagnostics' works. 'Select VPN' fails: no tunnel is set up. In fact, Sentinel does not send any (IPsec) packets at all (routing bug?).
• SSH Sentinel version 1.3 or lower (discontinued): uses a non-standard NAT-T protocol which is not supported by the NAT-T patch.

19.5.3 Mandrake 10.x, Mandriva 2005+

Mandrake 10.x and Mandriva 2005+ ship with a 2.6 kernel so it supports NAT-T out of the box. Mandrake 10.0 ships with a FreeS/WAN 2.04 userland utilities RPM which does not support NAT-T. The FreeS/WAN 2.06 included with Mandriva 2005+ and Mandrake 10.1 does not support Transport Mode so L2TP/IPsec with or without NAT-T will not work. Mandrake 10.0+ and Mandriva 2005-2006 ship with a SuperFreeS/WAN RPM but it does not support NETKEY so it will not work either. One solution is to use the Openswan or strongSwan userland RPM from the contrib directory or Mandriva Cooker. Reminder: Mandrake 10.1 and Mandriva do not support Legacy PTYs so you need a recent l2tpd RPM version.

Mandrake 9.2 supports SuperFreeS/WAN out of the box which contains the NAT-T patch for KLIPS. I suggest you do not use any older Mandrake version than 9.2. Unfortunately the FreeS/WAN userland RPM included with Mandrake 9.2 does not work. You will need the updated SuperFreeS/WAN 1.99.8 userland RPMs made available by Mandrake employee Florin Grad. Florin's RPMs do not contain two patches that are required for NAT-T support in Transport Mode. Those two patches need to be copied over to your RPM SOURCES directory. The first patch enables NAT-T support in Transport Mode (this is considered unsafe by Mathieu Lafon). The second patch (version 3) by Mikael Lönnroth works around a problem with the NAT-T implementation in Windows 2000/XP/Vista. The patch doesn't actually add support for this implementation, it is only a hack and probably a security risk. Then you apply this diff against Florin's original SPEC file which ties the two patches into the original SRPM. You can get the whole lot from me with this modified SRPM (super-freeswan-1.99.8-7jdl.src.rpm). Suggested build command: rpmbuild -ba super-freeswan.mdk.spec. Or, if you really want, you could download the binary RPM (super-freeswan-1.99.8-7jdl.i586.rpm) and the documentation RPM (super-freeswan-doc-1.99.8-7jdl.i586.rpm) from my webpage. You may need to hold the 'Shift' key while clicking these links!

SuSE 9.x uses kernel 2.6 so it supports NAT-T out of the box. SuSE 9.2 ships with an Openswan 2.2.0 userland utilities RPM. Alternatively, you can download Openswan RPMs for SuSE 9.x from the Openswan website. Alternatively, SuSE employee Kurt Garloff has made Openswan packages and KLIPS enabled kernels for older SuSE versions.

Debian uses kernel 2.4 with the backported NETKEY implementation. It should work. Openswan packages are available.

19.5.7 Other distributions

See if there are any Openswan packages (kernel and userland RPMs, deb, whatever) available. If none are available, you might have to create them yourself but that may be a lot of work.

19.6 Procedure for enabling NAT-T (server not NATed)

Once you have a kernel that supports NAT-T, you can follow the procedure below to enable NAT-T. If your Openswan server is behind NAT, see the next section. The procedure assumes that your setup looks like this:

                   NAT-        Internet      Openswan
Client  --------- device  =================== Server ... 192.168.1.0/24
192.168.0.2      /     \                      /     \
                /       \                    /        192.168.1.1  
     192.168.0.1/24   234.234.234.234   123.123.123.123                               

The internal subnet behind your Openswan server is 192.168.1.0/24. Note that l2tpd.conf's local ip (and ip range) must be an IP address (and subrange) within this internal network (in my example above they are 192.168.1.99 and 192.168.1.128--192.168.1.254, respectively). The IP address of the client is 192.168.0.2. Often the NAT device assigns this IP address to the client through DHCP. The client is on a subnet behind the NAT device, in this example 192.168.0.0/24. Openswan needs to know what remote subnets the clients use. You specify these subnet(s) with the virtual_private= parameter in ipsec.conf. Most people prefer to enumerate all network subnets that are defined in RFC 1918 because there can be many clients with many different subnets. But of course you can also specify only the 192.168.0.0/24 network if there is only one client. You should however always exclude the subnet(s) that are behind the Openswan server. An exclamation mark is used for this purpose (see the example below). In this example we assume that the internal IP address of the NAT device is 192.168.0.1. The external (public) IP address of the NAT device (in this case 234.234.234.234) is specified with the right= parameter. For Road Warriors you would probably want to use right=%any instead of right=234.234.234.234. The %no option of the rightsubnet= parameter allows the same configuration to be used for other clients that are not behind NAT.

The procedure is as follows:

• Make sure that your clients support NAT-T. That often means they will have to get the latest version or install an update (see above).
• If a client is behind a NAT device (Sitecom, Netgear, etc.) which supports IPsec passthrough: change the configuration of that NAT device so that IPsec passthrough is disabled. (Note: Linksys and Draytek routers do require IPsec passthrough to be enabled. In these routers "IPsec passthrough" does not mean: "use the broken built-in IPsec passthrough support that is incompatible with NAT-T" but: "allow any and all IPsec packets through the device".)
  
• Extend your existing ipsec.conf file with the following parameters:
  
    config setup
      # ...Existing parameters
      nat_traversal=yes
      virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.1.0/24
  
    conn L2TP-CERT
      # ...Existing parameters
      left=123.123.123.123
      rightsubnet=vhost:%no,%priv
  
  
• Restart Openswan.
• You should now be able to connect with a NATed client.

19.7 Procedure for enabling NAT-T (server NATed)

If your Openswan server itself is behind NAT, the procedure is slightly different. You can use almost the same setup as described in the previous section but it now looks like this:

                   NAT-        Internet        NAT-
Client  --------- device  =================== device -------------+-------- ... 192.168.1.0/24
192.168.0.2      /     \                      /     \             |
                /       \                    /   192.168.1.1   Openswan
     192.168.0.1/24   234.234.234.234   123.123.123.123         Server
                                                             192.168.1.2

• Use Openswan 2.4.5 or higher (or apply a patch if you are using an older version).
• Make sure that your clients support NAT-T. That often means they will have to get the latest version or install an update (see above).
• If you have clients running XP with ServicePack 2, you need to modify a registry setting on these XP SP2 clients. Windows Vista requires a similar registry modification.
  
• If a client is behind a NAT device (Sitecom, Netgear, etc.) which supports IPsec passthrough: change the configuration of that NAT device so that IPsec passthrough is disabled. (Note: Linksys and Draytek routers do require IPsec passthrough to be enabled. In these routers "IPsec passthrough" does not mean: "use the broken built-in IPsec passthrough support that is incompatible with NAT-T" but rather: "allow any and all IPsec packets through the device".)
  
• Extend your existing ipsec.conf file with the following parameters:
  
    config setup
      # ...Existing parameters
      nat_traversal=yes
      virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.1.0/24
  
    conn L2TP-CERT
      # ...Existing parameters
      left=192.168.1.2
      leftnexthop=192.168.1.1
      rightsubnet=vhost:%no,%priv
  


• Restart Openswan.
• You should now be able to connect with a NATed client.

With older Openswan versions there is a problem when the server itself is behind NAT (or when both the client and the server are behind NAT). The Openswan team was notified of this problem by Bernd Galonska. It has been fixed in Openswan 2.4.5 and higher. For older versions you can download Bernd's experimental patch from this webpage which I have modified slightly so that it applies cleanly to Openswan 2.3.0 and 2.3.1--2.4.4 respectively.

Back to Contents

In many cases VPNs are used to tunnel NetBIOS/SMB/CIFS network traffic ("Windows Networking"). Unfortunately, Windows Networking is a terrible protocol (ask the Samba guys) and it often results in all kinds of problems. This is not a tutorial on Windows Networking so I can't help you with that. But I can provide some hints.

If you want to browse the Network Neighbourhood across subnets (this includes WANs and VPNs), a WINS server is highly recommended. If you don't have a Windows NT/2000/2003 server available or if you don't want to buy one, you can download Samba and configure it as a WINS server. The important part to remember is that all computers should be configured to use this WINS server. Otherwise some computers might have trouble seeing other computers.

I also noticed that for the best results all clients should be configured to use the same workgroup/domain name, namely that of the office network. Out of the box, many clients have a default workgroup/domain name such as WORKGROUP or MSHOME which is different from the office network's workgroup/domain name. It is better to change these to a common name. Similar tips can be found on the ISA Server.org website.

The Microsoft clients have a stetting "Log on to network". Enable this if you want to log on to a domain server.

Note that Windows XP Home cannot join a domain. This is also the case for some versions of Windows Vista. You should be able to access resources in the domain, however.

I have not really tried to get logon scripts (batch files) to work. In theory it should work, since L2TP/IPsec is a Microsoft "approved" protocol. Perhaps the following procedure works. At the end of the New Connection Wizard, you are asked if this connection is for "Me only" or for "Anyone who uses this computer". Select anyone. You might prefer to not enter the password. The next time you logon, click the "Options >>" button. You will notice that a checkbox "Logon through Dial-up Networking" appears. Tick off this checkbox. Logon with your Windows Networking username and password. You will be presented with a window from which you can select the VPN connection that you just created. Select it and (hopefully) you will logon over the VPN connection, and the logon script will start.

Back to Contents

If you have a VPN connection to the office, normally all packets will be sent through the VPN tunnel. This includes not only traffic to internal servers but also Internet traffic, for instance when you surf to an Internet website. This has the disadvantage that the Internet traffic goes through the office's Internet link twice: once from your location to the office site and a second time from the office site to the Internet.

If you use 'split tunnelling' on the other hand, all internal traffic will be tunnelled through the VPN but all Internet traffic will be sent to the Internet directly, i.e. not through the office Internet connection. The problem is that this is less secure. Client users will then have two connections at the same time: one to the office and one to the Internet. Hackers could in theory break into the user's home machine and access the office from there. With split tunnelling disabled, this is more difficult to do. See also this Cable Guy article on the Microsoft website for more information about split tunnelling.

Here is how to enable split tunnelling:

• Windows 2000/XP
• Windows Vista
• The MSL2TP client
• Mac OS X
  
• Linux
• SSH Sentinel 1.4 or higher

Generally, I would recommend against enabling split tunnelling. You gain a bit of extra bandwidth but you also introduce a security problem. If you are worried that users might secretly enable split tunnelling without your permission, you could consider assigning "off-subnet" virtual IP addresses to the VPN clients. This is not a water tight solution but it would keep away most users. With off-subnet I mean that the virtual IP addresses (specified with l2tpd's "ip range" parameter) are not within the internal subnet (192.168.1.0/24 in my example configuration files). You will have to do some extra routing on the VPN server so that the client on the virtual IP subnet can still reach resources on the internal subnet. Let's assume you have configured off-subnet virtual IP addresses. So what happens when a user connects? When the user has disabled split tunnelling, the default route will be to the VPN server. The user can access internal resources because of the extra routing on the VPN server. Internet sites are also routed through the VPN server and thus accessible. When the user has enabled split tunnelling, however, things are a bit different. The VPN client's default route will be to the Internet. So Internet sites will be accessible. But resources on the internal subnet are not accessible. The client has an off-subnet virtual IP address so packets to the internal subnet will be sent to the default route (the Internet), not to the VPN server. If you use private non-routable IP addresses on your internal subnet (following RFC 1918, e.g. 192.168.1.0/24), then the ISP will drop those packets. In other words, the VPN client will not be able to access resources on the internal subnet when split tunnelling is enabled, which was the whole objective. Unfortunately this method can be circumvented by users who define a static route to the internal subnet on their workstation. There is no cure for negligent users, except not using a VPN at all...

Back to Contents

The very nature of a VPN makes it difficult to troubleshoot. VPN servers do not want to give away much information to a potential 'attacker' in case of a problem. Packets may be silently dropped by the server. Error messages sent to the client might not be very helpful. That said, here are some tips in case of problems with your L2TP/IPsec connection.

Use the command ipsec verify. Not every "[Failed]" error that it reports is a real problem but it can be helpful in certain circumstances. If you don't use Opportunistic Encryption you should ignore the error messages about missing reverse DNS entries, for instance.

Sometimes the IPsec packets get blocked. For instance when there is a too restrictive firewall on the route or when an ISP actively blocks VPN protocols. Verify with tcpdump that the IPsec packets (UDP ports 500/4500 and IP protocol 50) actually arrive at your Linux server. You can also use Openswan's ipsec ikeping command for that. Problems can be debugged by tracing packets layer by layer:

Where eth0 is the hostile network, ipsec0 is the IPsec connection running over the hostile network (only if you use KLIPS; if you use NETKEY there is no ipsec0), ppp0 is the L2TP/PPP connection through the IPsec tunnel, and eth1 is the internal network. If your network devices are named or numbered differently, change accordingly.

If you use KLIPS you should not see any unencrypted packets (e.g. pure L2TP) on the eth0 interface. If you do see unencrypted packets with KLIPS, you don't have a secure VPN (make sure that the automatic L2TP/IPsec policy has been activated on the Windows client). But if you use NETKEY there is no ipsec0 interface. If you use NETKEY and do a tcpdump on the external interface eth0, you might see unencrypted packets in one direction. The best (and authoritative) solution is to check with a third system between the client and the server. If you sniff the communication between these two with run tcpdump /Ethereal/etc. you should see encrypted packets all around.

Use ping to test the flow of packets:

Openswan logs its error messages to /var/log/secure. There can be various reasons why you don't get a working IPsec connection:

• a firewall might be blocking packets somewhere (L2TP/IPsec requires only UDP 500 and IP protocol 50, and UDP 4500 when NAT-T is involved).
  
• the server is not running or you typed a wrong IP address / hostname.
• there is an authentication failure.
• there is a policy mismatch (the IPsec parameters in ipsec.conf differ from what the client expects)
• there are Path MTU issues
  

This Openswan troubleshooting guide by Michael Richardson may be of help, although it assumes that the Openswan system is the initiator of the connection (in most L2TP/IPsec cases it is the responder because a Windows or Mac client is the initiator).

You might be tempted to enable full Pluto debugging by adding plutodebug=all to ipsec.conf. This will force Pluto (the IKE daemon) to log in much more detail. In most cases this should not be necessary because your problem is likely to be caused by some configuration error. Only when there are serious issues you may need to enable Pluto debugging. For example, when a brand new version of Openswan or the Linux kernel has been released and a problem was introduced in this version. Or when you want to interoperate with an IPsec product that has not yet been tested with Openswan. When you have such advanced implementation or interoperability problems, you may even have to enable KLIPS (kernel) debugging with klipsdebug=all. This will also show packets silently dropped by the kernel. To activate these changes Pluto will have to be restarted. More information can be find in the FreeS/WAN Troubleshooting Guide. Do not use these settings in production setups because they make it very easy for the bad guys to perform a Denial Of Service.

If you have got IPsec working but still you cannot log in, you might want to have a look at the L2TP and PPP error messages. If the L2TP and/or PPP phase fails, the IPsec connection will be terminated, eventually. The PPP and L2TP error messages are typically logged to /var/log/messages. But not all debug messages are logged there. Mandrake logs verbose debug messages to /var/log/daemons/*. For Red Hat you might have to increase the debug level by editing /etc/syslogd.conf and adding *.debug; to the line containing /var/log/messages. Then you'll have to restart syslogd with service syslog restart. On Debian/Ubuntu etc. you have to look in /var/log/debug for L2TP messages and /var/log/auth.log for IPsec messages.

22.3 Gateway not reachable

You are using KLIPS and you get the following error:

route-host output: /usr/lib/ipsec/_updown: doroute `ip route add x.x.x.x/32 via x.x.x.x dev ipsec0 ' failed
(RTNETLINK answers: Network is unreachable)

This means that the packets are not routed to the proper ipsecN interface so they are not processed
by KLIPS. This may be a bug which should be solved in Openswan 2.3.1+. You can work around this problem by adding an extra parameter to the Openswan configuration file, e.g.:

conn L2TP-CERT
        authby=rsasig
        pfs=no
        left=123.123.123.123
        leftnexthop=<IP_address_of_your_gateway>
        leftrsasigkey=%cert
        leftcert=/etc/ipsec.d/ssl/localCERT.pem
        etc.

22.4 Mars Attacks!

If a tcpdump shows that the Linux server does not seem to respond to packets from the Windows/Mac client, then you might not have disabled Reverse Path filtering. If you see lines like this in /var/log/messages:

martian destination 127.0.0.1 from 192.168.0.222, dev ipsec0
martian source 192.168.0.200 from 192.168.0.222, on dev eth0
ll header: 00:00:00:00:00:00:00:40:33:2c:70:c8:08:00

... then you need to clear rp_filter. If you scroll back in /var/log/messages, you will see that FreeS/WAN had complained about it (Openswan by default clears this parameter):

ipsec_setup: (/proc/sys/net/ipv4/conf/eth0/rp_filter = `1', should be 0)

A quick echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter fixes the problem, if eth0 is the device. Alternatively, you could add net.ipv4.conf.default.rp_filter = 0 to /etc/sysctl.conf. Openswan supports the parameter rp_filter in the config setup section of ipsec.conf. Possible values are %unchanged (to leave it alone) or 0, 1, 2. It defaults to 0, i.e. disable for all interfaces used by Openswan.

• Windows 2000/XP
• Windows Vista
• Microsoft L2TP/IPSec VPN Client (Windows 9x/NT/Me)
• Mac OS X
  

X.509 certificates can be used as an alternative to Preshared Keys. As mentioned above, certificates require Strongsec's certificate patch. You will need to set up some kind of Public Key Infrastructure (PKI) for creating the private keys and X.509 certificates for the Openswan host and the Windows IPsec clients.

Don't forget to disable the PSK configuration files once you start using certificates. Openswan will get confused if there are PSK and certificate configuration files for the same client / IP address. The PSK configuration will get the upper hand. If you do need certificates and PSKs working at the same time for Road Warriors, check out the instructions by Sverre Gunnersen.

OpenSSL is a popular choice for generating certificates because it is Open Source and freely available. This page is not a tutorial on using OpenSSL or certificates in general. Excellent documentation on generating certificates is available elsewhere:

• Strongsec's documentation. This is the manual accompanying the X.509 certificate patch included with Openswan and strongSwan. (Unfortunately not all X.509 certificate parameters are discussed in man ipsec.conf. The Strongsec documentation is simply the definitive guide for that).
  
• Nate Carlson's webpage. Information on using Windows 2000/XP with Openswan with L2TP. Includes instructions on manually generating certificates.
• The "FreeS/WAN IPSec Interoperability Guide" by SSH Communications Security Corp. It is geared towards usage with the SSH Sentinel client, but chapters 1.3-1.6 ("Setting up an OpenSSL CA") can be used for L2TP/IPsec connections as well.

Either way, you will have to end up with certificates in PKCS#12 form. PKCS#12 is a standard for distributing keys and certificates. A PKCS#12 file with extension .p12. or .pfx contains the client's private key, its corresponding certificate and the root CA's certificate (possibly even a chain of CA certificates). Since it contains the client's private key, the PKCS#12 file is encrypted with a password. Note that client certificates have to be signed by the same Certificate Authority (CA) as Openswan's certificate!

You import certificates for L2TP/IPsec into Windows 2000/XP/Vista using the Microsoft Management Console (see these instructions). Windows 95/98/Me do not ship with MMC. Instead, you import the PKCS#12 file into Internet Explorer,  or to be more precise, the certificate store found under "Tools -> Internet Options" (see these instructions).

The CA included with Windows 2000/2003 Server supports Extended Key Usages properties (in ASN.1 Object Identifier notation) for certificates. These EKUs restrict certificates so that they can only be used for IPsec connections. Other uses (say, for a webserver) are not allowed. This adds a little bit of extra security to the server's PKI. If you use OpenSSL, you can probably create certificates with these EKU properties too, but I haven't looked into it.

There has been a report to the Bugtraq mailinglist by Thor Lancelot Simon about a potential Man-in-the-Middle vulnerability (mirror) with certain IPsec implementations. If one client certificate is compromised (which is not too difficult: a laptop can get stolen, for instance), it could be used by an attacker to masquerade as a server certificate to a second client. After all, the compromised certificate of the first client is a valid certificate issued by the CA. The issue is only true for Windows clients if no EKUs are used. If you do use EKUs (as described above) then the issue is mitigated. Windows Vista and Mac clients are also not vulnerable to this issue because they require the server's hostname or IP address in the certificate's ID (can be disabled on Vista as an option).

23.2 Troubleshooting: Windows 2000/XP/Vista picks the wrong certificate

Some people reported the following problem. They have a Windows 2000, XP or Vista client that should connect to 2 or more Openswan L2TP/IPsec servers that each have their own CA. Different certificates were installed on the client. But when the client connects to a server, it always presents the same certificate to the server. So the client can connect correctly to one server but not to the other VPN server(s). This is not what you want. The client should be able to connect to all servers.

The short story is that adding rightca=%same to the configuration should solve the problem. The long story is described here.

23.3 Certificates on smartcards, two-factor authentication

Certificates can be stored on smartcards (including USB tokens) for extra security. I have tested this with the MSL2TP client and it works. When I started the connection, it asked for the PIN number of my IKey 2032 token and only then the connection was set up. SSH Sentinel should work too (it comes with a separate smartcard application called Accession Lite) but I had a bit of a fight with the IKey driver.

Using smartcards with the built-in IPsec client of Windows 2000/XP/Vista may be a problem. Microsoft distinguishes between 'machine certificates' and 'user certificates'. A machine certificate is only used for IPsec and cannot be installed on a smartcard or token (as mentioned above). A user certificate on the other hand is used in the PPP phase when EAP authentication is selected. I could not find a way to store the 'machine certificate' (also called 'local computer certificate') on my USB token. Please correct me if I am wrong! According to the Microsoft documentation, it is possible to specify a different CSP (Cryptographic Service Provider), such as the one supplied with your smartcard/USB token, but only when you apply for the certificate through the web interface ("web enrolment"). Not when you import your certificate through a file in PKCS#12 format.

So if you want to users to authenticate with certificates using the built-in Windows L2TP/IPsec client, you will need a Linux PPP server with EAP support (or a PPP server with a RADIUS plugin so that it can authenticate against a RADIUS server through EAP-TLS). This is outside the scope of this webpage, but FreeRADIUS should be able to do this. Check out the EAP-TLS support in FreeRADIUS. An extension for the pppd RADIUS plugin by Michael Heiart may also be needed. An alternative is to switch to a third-party Windows IPsec client with smartcard support such as SSH Sentinel.

Back to Contents

conn L2TP-PSK
  dpddelay=40
  dpdtimeout=130
  dpdaction=clear

conn L2TP-PSK-CLIENT
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear

Back to Contents

Could Microsoft also be trying to commoditise the IPsec protocol, while extending/embracing the (Microsoft/Cisco co-developed) L2TP protocol? Microsoft likes to write about L2TP as if it were a VPN protocol. For instance here: "Q. Do I want to use PPTP or L2TP? A. L2TP is considered more secured than PPTP and will allow you interoperability with 3rd parties". What they mean with 'L2TP' is actually 'L2TP/IPsec'. It is IPsec that provides the confidentiality and authentication in L2TP/IPsec connections. They seem to be shifting public attention from IPsec (several implementations by multiple vendors) to L2TP (not that many products available). Another thing is that not everyone is happy with L2TP. It results in 'double tunnelling' (extra overhead) and might very well be only a vehicle for doing extra authentication (of course, preferably against an NT SAM user database, which means buying more Windows client access licences).

I am a bit puzzled why Microsoft released the MSL2TP client. They have recently stopped support for 'old' Windows versions, and here they are releasing software which runs even on Windows 95. Interesting also is that SafeNet is eating into its own third-party Windows IPsec client market, to some extent, by releasing the free MSL2TP client. Why would they do this? An offer by Microsoft "they could not not refuse"?

I would also like to make the following observation. The MSL2TP client was developed for Microsoft by SafeNet. The IKE/IPsec support in Windows 2000/XP and Pocket PC was "jointly developed with Cisco". It appears that IPsec is not a high enough priority for Microsoft to do all development in-house...

Back to Contents

• An 'executive summary' of this page has been made by Nate Carlson.
• l2tpd example configuration (without IPsec) by Shashank Khanvilkar.
• IPSec/L2TP Tunnelling with Linux-2.6 and Racoon by Chris Andrews.
• Howto for a VPN solution based on Linux 2.6 and Openswan/Racoon by Wolfgang Hennerbichler.
• VPN guide by Nasim Mansurov.
• Howto for Fedora with Strongswan by Dale Hartung.

Apr 7, 2008: Openswan L2TP/IPsec setup available on OpenL2TP website.
Mar 12, 2008: Added remarks about DHCP Inform.
Jun 27, 2007: Apple iPhone ships with L2TP/IPsec client.
Jun 2, 2007: Stinghorn no longer available?
Dec 27, 2006: Added info on OpenL2TP, with thanks to James Chapman.
Nov 22, 2006: Moved Linux as an L2TP/IPsec client to a separate page.
Nov 9, 2006: Vista NAT-T issue resolved.
Nov 5, 2006: Added page for Windows Vista.
Jan 7, 2006: Added link to Xelerance's xl2tpd.
Dec 6, 2005: Updated info on Linux as an L2TP/IPsec client.
Nov 15, 2005: Updated sample Openswan configuration files (rekey=no etc.)
Nov 15, 2005: Openswan 2.4.2 partially supports NATed Mac clients.
Jul 6, 2005: EU Parliament rejects software patents! (For now, at least).
Jun 25, 2005: Uploaded l2tpd-0.69-12jdl (S)RPM that compiles and works on for FC4. Added ppp 'unit' info.
Jun 14, 2005: Added reference to the Securepoint Personal Firewall & VPN Client.
Jun 2, 2005: I consider removing support for ancient versions such as Mandrake 9.1 and older.
May 31, 2005: l2tpd is now in maintenance mode. The l2tpd.org domain has been hijacked. Website has moved.
May 3, 2005: Mac OS X v10.4 ("Tiger") Client and Server support certificates for L2TP/IPsec but I have not read reports of anyone using this method successfully.
Mar 17, 2005: Uploaded l2tpd-0.69-11jdl RPMS for FC2/3 and MDK10.1. These contain Unix98 pty support.
Mar 17, 2005: Uploaded experimental patch to fix server-side NAT-OA bug.
Mar 16, 2005: Found out about another L2TP server, l2tpns.
Jan 21, 2005: Nate Carlson has made an L2TP/IPsec Howto.
Jan 8, 2005: NAT-T standard approved by the IETF as RFC 3947.
[Old revision history]
July 20, 2002: Added report of preliminary l2tpd success.
July 15, 2002: Changed <h4> headings since Opera does not display them. Added PSK remarks.

Jacco de Leeuw