Configuring VPN connections with Linux clients

Close and Secret

Article from Issue 97/2008

Author(s): James Stanger

Linux clients sometimes need a little help to connect to Windows VPN servers.

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.

Account Lockout

As you experiment with your VPN connection, make sure your account doesn't get locked out. Most VPNs have a hard time differentiating between legitimate experimentation with VPN settings and someone trying to break in. If you're locked out, you won't be able to get in, even if you have finally specified the correct settings.

If you find yourself unable to connect, pay close attention to logfile and debug file messages to see whether authentication and connection messages have changed in any way; a subtle change might indicate that you are, in fact, locked out of the account. If this is the case, you'll have to wait until the account gets unlocked. Hopefully, the lockout is temporary. (My account is re-enabled automatically after 30 minutes.) Otherwise, you'll have to contact your network administrator each time you get locked out in order to get your account enabled again.

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.

Troubleshooting Issues

When troubleshooting connections, make sure you have the right modules installed and running. For example, I have the modules from the following list running on my Linux system (Ubuntu 8.04.1) when I connect as a client to a PPTP VPN:

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

First, check your VPN documentation to determine which modules are necessary; then, use the insmod command to install these modules. Also, you can take the necessary steps to have them added to the /etc/modules file.

The Maximum Transmission Unit (MTU) is another important setting, and I've never had to change it for my VPN connections. However, a friend of mine who has worked with VPNs for about 15 years has found that, in some cases, a VPN user might need to change the client MTU from the standard 1500 to a smaller value, such as 1490.

When you encounter troubles, remember to enable debugging options in your client – you can always disable them later. In one case years ago, I found that enabling the debugging options in a client caused problems with the connections, but this is quite rare. Debugging options can include specifying ICMP packets in order to test a connection, as well as determining the size of the echo interval. I've found that the ping command is just as good, if not better.

A strange but sometimes useful troubleshooting option is to disable encryption. Of course, if you do this, you'll lose one of the key benefits of having a VPN connection. Most servers reject unencrypted connections; however, I have seen cases in which an unencrypted VPN connection is a possible option. I'm not saying this makes any sense; I'm just saying I've seen it. So, if none of the possible encryption options work, try disabling encryption and seeing if you can make the connection. A successfully connection without encryption narrows the list of possible problems.

IP masquerading and other forms of Network Address Translation (NAT) pose a number of additional problems for VPN connections. If you're using ESP and Authentication Headers (AH), for instance, you will have problems with NAT because AH runs a checksum that includes values such as the IP address for the connection. Because masquerading/NAT modifies the IP address, the checksum run by AH will be different. Because most NAT firewalls/masquerading schemes can't forward the AH keys, the checksums won't be correct.

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.

1 2 3 Next »