Interoperating with Microsoft Windows and Apple Mac OS X
From a technical point of view, these Mac OS X versions have the same capabilities, since they all use KAME's Racoon under the hood. However, the Tiger GUI offers functionality not found in the earlier versions, for instance allowing user-friendly configuration of support for X.509 Certificates, VPN dial on demand, and whether to send the default route through the VPN or not. The GUI is geared towards L2TP, but if you manually configure Racoon with your own configuration files, you can also create IPsec tunnels without L2TP. Some third-party software, such as Securitas, is indeed just a GUI for creating Racoon configuration files avoiding Apple's VPN system altogether. Cisco ships its own IPsec client software for Mac OS X.
Always check for the latest updates on third party clients. Tiger especially broke much thirdparty software due to a massive kernel API change. Releases of Mac OS X before Tiger (10.4) do not implement NAT-Traversal, but all versions of Tiger (at least up to 10.4.3) implement NAT-T incorrectly. Due to an error in their IKE daemon, the kernel sends ESP instead of ESP- in-UDP packets.
Mac OS X Tiger Server contains another GUI utility called s2svpnadmin to set up site-to-site tunnels using PSKor X.509-based L2TP/IPsec tunnels.
Layer 2 Tunneling Protocol (L2TP)
One of the limitations of IPsec that we have seen so far, from an end-user point of view, is the automatic configuration of an internal IP address. This is needed for two reasons. Mostly, LANs and WANs are secured against any unauthorized access from the Internet. Generally, firewalls ensure only LAN and WAN IP addresses may access the company's internal servers. The problem is that the IP address of the remote endpoint in an IPsec connection may be some ISP-determined address that would not be known beforehand.
When the firewall is not running on the VPN server, it is impossible to know whether such a connection is an authorized IPsec connection, or a rogue host on the Internet that has managed to get into the network somehow. The easiest solution is to have the VPN server give a connecting IPsec client another IP address, one from the company's IP address pool. Now the client can use that new IP for connections within the company network, and the company network can tell by the IP address that this is a teleworker connecting from home via the VPN server.
Another problem that makes IPsec connections with unknown ISP-assigned IP addresses difficult is NAT and NAT-Traversal. When NAT-Traversal is in use, an IPsec connection is actually established between the private IP address of the roadwarrior and the VPN gateway. The outer IP address of the roadwarrior is not used, except as the envelope around the inner packets. The problem arises when two teleworkers using the same internal IP addressing scheme try to connect to the VPN gateway. The chance of two teleworkers having the same internal IP address becomes pretty high since most ADSL and WiFi routers come with a default internal IP range (usually 192.168.0.0/24 or 10.0.0.0/24), and their DHCP services hand out IP addresses in that range (often 192.168.0.101 and 10.0.0101). The problem is aggravated when the same hardware is used by different teleworkers. Care needs to be taken to ensure everyone has a unique inner IP address.
Openswan 2.5 will support roadwarriors with identical IP addresses (it already does, but this code has not yet been released)
156
Chapter 8
However, the teleworker's computer remains more or less inaccessible by the corporate network, as no one knows its internal IP address. L2TP solves this by handing out an IP address to those teleworker connections. Apart from assigning an IP, it is also often necessary to assign a DNS or WINS server from within the company network, so teleworkers are able to resolve the names of internal servers not published in the public DNS servers. The IKE protocol did not have any capability to relay this information. An extension was needed.
Assigning an IP for VPN Access
Microsoft and SSH worked on the DHCP over IPsec proposal. Though this proposal became an IETF standard, Microsoft never deployed it itself, and only the SSH-Sentinel client supported it. The SSH-Sentinel client was discontinued when it was bought by competitor Safenet. Therefore, DHCP over IPsec is not deployed anywhere, and we will not discuss how to set it up for Openswan.
ModeConfig with XAUTH was mostly a Cisco-driven extension to IKE to solve the IP address assignment issue. Nortel also supported this feature, but added its own proprietary extensions ensuring its client and server products could only interoperate with each other.
Microsoft's Remote Access Service (RAS) provides some of the infrastructure necessary for these features. RAS basically implements a PPP connection, with the typical Microsoft extensions. Microsoft then deployed its own encryption/VPN protocol, which was proven to be insecure on a few occasions. Microsoft ended up using a hybrid of the IPsec protocol and its own protocol called Layer 2 Tunneling Protocol (L2TP). This hybrid is confusingly also called L2TP. We will not delve into the political details of ModeConfig and XAUTH versus L2TP; both schemes are currently deployed on a large scale. Only L2TP, however, does not require one to buy or install a separate VPN client for Microsoft Windows. The same applies to Apple's Mac OS X.
L2TP Properties
L2TP uses IPsec transport mode with ESP. If NAT-Traversal is needed, another layer of ESPinUDP is added on top of that. But L2TP can also use its own encryption method, the one that has been proven insecure, within those packets. Inside the L2TP packets, PPP is used. In some configurations, when the inner Microsoft encryption is not used but the L2TP packets are still encrypted within the IPsec packet, Windows will complain because it is not aware of the outer-layer IPsec encryption. Some system administrators therefore enable this inner encryption layer as well, just to save the end user a bogus warning pop-up window, but not all L2TP daemons support this encryption.
Unlike PPP, which is a point-to-point protocol, L2TP is a routable protocol using UDP port 1701. IPsec connections established for an L2TP connection will request a special IPsec tunnel that limits the protocols and ports that are allowed over the IPsec tunnel to just those needed to transport L2TP packets. The L2TP packets contain the actual PPP packets, which contain the real IP packets with their source and destination addresses and ports. Openswan supports these protocol and port number restrictions using the leftprotoport= and rightprotoport= parameters.
Just like PPP, L2TP can automatically assign various network attributes, such as IP address, netmask, DNS, or WINS servers, just like the traditional PPP-over-RAS protocol can. It also offers better integration with proprietary Microsoft features, making it easier to integrate with the Windows login procedure. For the end user, L2TP is therefore very easy to configure and deploy.
157
Interoperating with Microsoft Windows and Apple Mac OS X
When IPsec is used with L2TP, Microsoft currently only supports 3DES, not AES. PFS is also not supported by Windows clients in L2TP configuration. Openswan version 2.5 will support multiple L2TP clients behind the same NAT.
L2TP has another disadvantage: it adds even more encapsulations to a packet. This is likely to trigger more any PMTU or packet fragmentation issues.
Pure IPsec versus L2TP/IPsec
The question of what type of setup to use is difficult to answer. It depends on a few subjective choices. The easier you make it for VPN clients to connect, the harder your VPN server will be to set up. Ideally, you want to avoid the extra hassle of setting up and maintaining an L2TP infrastructure. And if possible, you want to avoid another layer of packet encapsulation, and even one layer of encryption, especially because these L2TP connections are userland processes on the Linux server. They do not run within the kernel, like IPsec does, and therefore require significantly more CPU power.
However, Windows and Mac OS X support L2TP out of the box. No separate VPN client needs to be installed. If you are installing a separate VPN client anyway, you might as well try to get a client that supports ModeConfig with XAUTH, and avoid the overhead of L2TP altogether. However, be aware that ModeConfig with XAUTH is a fairly recent addition to Openswan, which has not yet been widely tested with Windows clients.
If you are just connecting a handful of users to a single office subnet, then it is recommended that you skip L2TP and ModeConfig with XAUTH altogether. Instead, just ensure your users are set up to use unique LAN IP addresses at home to avoid collisions, and incorporate those ranges into your company firewall rules. Although you will then need to use a third-party VPN client for Windows or Mac OS X, such clients are freely available.
L2TP: PSK or X.509
L2TP's IPsec connection can use either PSK or X.509. We discussed the use of X.509 versus PSK in earlier chapters. In general, X.509 is much preferred over PSK because it is more secure. However, it is far easier to use PSK. Note that Windows 2000 only supports L2TP with X.509. It does not support L2TP with PSK. Mac OS X before Tiger did not support X.509, and with Tiger (10.4.4) it is still hard to configure properly.
In the following sections, we look at how to set up L2TP with either PSK or X.509, but we strongly advise everyone to switch to X.509 as soon as their platform supports it. Remember that PSK does not work too well when NAT-Traversal is involved. Finally, remember that anyone that gets hold of the PSK can pretend to be the VPN gateway and attempt to obtain user credentials. As the PSK needs to be identical for all clients, the larger the company, the larger this risk becomes.
158