Two benefits of tunneling are encrypted connections and access to resources behind the firewall. When it comes to interoperability, however, establishing these connections is sometimes difficult for Linux clients. Linux distributions often have issues with establishing virtual private network (VPN) connections with servers based in other environments, mainly because the GUI applications used to establish those connections have trouble staying in sync with the pace of Linux development. It is often two steps forward, and once step back: When each distribution ships, the shared libraries often get changed, and your favorite VPN application that used to work no longer succeeds with cross-platform connections. Recently the situation has improved. In this article, I look at some tips for establishing VPN connections from the Linux desktop.

A VPN creates a point-to-point tunnel over a public network. A number of protocols support VPN connections, including the following popular options:

• L2TP over IPsec – Cisco's primary tunneling protocol. L2TPv3 is the latest version, but make sure you choose a version appropriate for your network. Remember that two major implementations of IPsec are available in Linux systems. For example, older systems use FreeS/WAN or Openswan for IPsec. Newer systems with any version of the standard 2.6 kernel have native IPsec support.
• Point-to-Point Tunneling Protocol (PPTP) – An older protocol that still is used in many Microsoft environments.
• Secure Sockets Layer/Transport Layer Security (SSL/TLS) – One of the most powerful interoperability protocols available SSL/TLS supports many types of VPN connections. OpenVPN [1], for example, is an SSL/TLS-based tunneling solution.

Over the years, I've followed many discussions about which protocol is the most secure or open source--friendly. Many of these discussions border on the quasi-religious. As I've grown older, I've discovered that such discussions are less useful than simply finding out which protocol works best for your particular network and adopting it.

Whatever protocol you use to establish your tunnel, it's possible to place packets through this tunnel, and those packets will be regarded by the firewall as internal packets. The key, as you will see below, is making sure the right packets go through the right interface and tunnel.

The Linux environment provides several tools for configuring and managing VPN connections. KDE's KVpnc utility supports various VPN techniques (from Cisco, to Microsoft, to OpenVPN). Vpnc is a command-line VPN client for Cisco systems. Many Linux distributions use Red Hat's NetworkManager [2], which allows you to add VPN plugins for Cisco and Microsoft networks. For the VPN you want to use, you will have to install the appropriate NetworkManager plugin.

Pptpconfig [3] is an older client that works especially well for many Red Hat and Novell Linux implementations, along with BSD and various others. As the name suggests, pptpconfig is used for managing Microsoft-based VPNs.

Creating a Tunnel

Regardless of which client or protocol you use, you'll need to gather some basic information to establish a connection. For instance:

• Authentication information – Depending on what your network administrator wants, you'll have to provide user-specific information to authenticate yourself to the VPN server. The least secure (yet most common) option remains providing a username and password. Additional options include secret keys and certificates. Cisco, for example, prefers keys or certificates.
• Gateway (also known as the VPN server name) – The IP address or hostname of the VPN device that provides the tunnel once you authenticate.
• Protocol type – As discussed above, you will need to choose between protocols such as L2TP, PPTP, OpenVPN, and so forth. The configuration tool will ask you to specify options specific to the protocol(s) your network administrator has chosen for the VPN.
• Universal settings – With any authentication protocol, you'll need to provide information specific to your connection. For example, some networks require you to set a specific Maximum Transmission Unit (MTU); your application will allow you to make such connection-specific changes.
• Routing information – No matter what protocol or authentication setting you choose, you will often have to take specific steps to make sure the right packets are sent across the right interface.

Also, you will need a cooperative network administrator to help you get the information listed above.

ppp_mppe   8068 2
ppp_async  13312 1
crc_ccitt   3072 1 ppp_async
ppp_generic  29588 6
ppp_mppe
ppp_async
slhc       7040 1 ppp_generic
ppdev      10372 0

Configuring Microsoft PPTP Connections

Even though PPTP is often considered less secure than Cisco or OpenVPN connections, it is nevertheless popular. When configuring Microsoft PPTP, you are presented with quite an array of authentication, compression, and encryption options.

One of the challenges is to decide on an authentication method. Peer authentication means that the server will ask the host to identify itself. Options include:

• Challenge Handshake Authentication Protocol (CHAP): The RFC-compliant standard protocol. All you need to provide to CHAP is a username and a password. The protocol uses this information to enable authentication. MS-CHAP is Microsoft's implementation of the CHAP protocol. If you can't get definitive word from a network administrator, use MS-CHAP to connect to a Microsoft VPN server.
• EAP: An extension of the original PPP authentication protocol that allows the use of a certificate instead of a username and password. EAP is not as common as MS-CHAP and CHAP.

Many clients provide the option of refusing each of these authentication techniques. If you want to work and play well with the remote VPN server, you might need to do this explicitly for the PPP daemon on your system.

VPN connections generally compress packets to tunnel them more efficiently. Generally, you have three compression options:

• Microsoft Point-to-Point Compression (MPPC) – An older protocol based on a Lempel-Ziv (LZ) algorithm and usually reserved for ancient Windows clients (e.g., Windows 95 or NT). However, you might find that this form of compression works for your VPN connection.
• Deflate compression – A patentless protocol similar to MPPC. It is more universal than MPPC, but most Microsoft-oriented VPNs won't use it.
• BSD compression: Explained in RFC 1977, BSD compression is the traditional compression protocol.

I've found that compression often causes problems in connections. If you can't get definitive word from your admin, specify no compression at all at first, then experiment with these settings later.

The encryption setting is also an important consideration. Microsoft Point-to-Point Encryption (MPPE) is a subset of MPPC. You can use two different key levels: 40-bit or 128-bit. Companies in many countries use only 40-bit encryption. As you configure your PPTP client, either ask your network administrator for the key length, or else experiment with the key length setting.

Stateful MPPE is usually the best encryption option in that it provides the fastest network connections. As I discuss later in this article, you must enable the MPPE module for any of these settings.

DNS Issues

Most DNS clients will ask you whether you want to use the standard DNS information found in /etc/resolv.conf or the DNS server information provided by the VPN server. This, of course, is up to you. But many times, I've found that establishing a VPN connection causes unexpected changes to my DNS resolution, mainly because the VPN client will still make changes to my /etc/resolv.conf file, even if I tell it not to.

The best solution is to use a VPN client that works the way in which I expect. But failing that, I simply create a script that copies the right /etc/resolv.conf file. If your VPN client asks you whether you want to "peer DNS through the tunnel," this is simply the client asking you whether you want it to update your /etc/resolv.conf file with DNS server information. Make your own choice here, depending on the information from your network administrator. If you don't use information from the VPN server, chances are that the host using the VPN won't have access to the DNS names of your internal sources. However, make sure that if the VPN server provides the DNS information, the client's routing tables are updated to access the internal VPN server. Otherwise, the client host will experience a DNS resolution problem for internal resources – and possibly external resources.