Types Of Tunnel

Types of Network Tunnels If all you want to do is run a tunnel using Windows, you can ignore this page. It's for people who want to learn more about tunnels.

Overview Each of the tunnel types we support is described in a section of it own below. The types we support are: MPPE/PPTP (Microsoft VPN) - Windows, UNIX/Linux, and Mac clients. • CIPE - Linux clients and Windows (2000 & NT) clients • OpenVPN - UNIX/Linux clients • SSL-wrapped PPP - Linux clients (other UNIX clients?) • GRE and IP/IP - Linux clients, Cisco routers • IPSec, tunnel mode - Windows (2000 & NT) and UNIX/Linux clients • IPSec/PPTP - Windows (2000 & NT) and UNIX/Linux clients • IPSec/L2TP - Windows (2000 & NT) and UNIX/Linux clients •

Because the software comes with Windows, the most common tunnel type is MPPE/PPTP (Microsoft VPN). MPPE/PPTP tunnels also are very easy to configure and use. In the past, MPPE/PPTP tunnels from Windows clients have had marginal performance, but performance is no longer much of an issue with Windows 2000 and Windows XP. CIPE, OpenVPN, and SSL-wrapped PPP tunnels are primarily for clients in the UNIX family. CIPE and OpenVPN sport particularly good performance.

VPNs (Virtual Private Networks) Our most common use of tunnels is for purposes other than VPNs. However, the tunnel technologies we make use of were originally developed for VPNs, so we take a brief look at VPNs. To make part of a VPN, a tunnel does three basic things: 1. It provides a virtual link. 2. It provides data encryption - it transmits the data in a secret code. 3. It provides remote end authentication - it guarantees who is doing the sending and receiving.

Tieing together several virtual links makes a virtual network. Encryption and authentication make the virtual network a private network, a VPN. Some tunnels bundle all three aspects into a single technology suite and make tunnels that are inherently encrypted and authenticated. Others have two components, one to establish a basic virtual link and another to provide private communication across it.

MPPE/PPTP (Microsoft VPN) MPPE/PPTP is Microsoft Point-to-Point Ecryption on tunnels using Microsoft's Point-toPoint Tunnel Protocol. Authentication uses Microsoft's version 2 enhanced CHAP, MSCHAPv2. MPPE comes in both 40-bit and 128-bit versions. (There's a 56-bit version as well, but we've never seen it.) Windows 95 and Windows 98 clients normally use 40-bit encryption. They can be upgraded to 128-bit, but the upgrade can be hard to find. More recent Windows versions normally use 128-bit encryption, known as Microsoft Strong Encryption. MPPE/PPTP client software is available for other systems, including an open source PPTP client for Linux, FreeBSD and NetBSD, and a commercial PPTP client for Macs called "DigiTunnel" from Gracion, Inc. As of Jan 2003, Gracion's compatibility list still says (incorrectly) that their software is not compatible with UNIX/Linux server software. The incompatibility was resolved more than six months ago and requires only a minor configuration change that can be made at either the UNIX/Linux end or the Mac end.

While MPPE/PPTP tunnels are a reasonable, easy-to-use solution for Windows clients and Mac clients, we do not recommend MPPE/PPTP tunnels for Linux/UNIX users unless they need compatibility with Windows-based tunnel servers. Otherwise, the effort needed to get MPPE/PPTP installed and running on a Linux/UNIX platform is better spent on a better tunnel technology, such as CIPE or OpenVPN (see below). MPPE/PPTP performance depends a great deal on the client system. With Windows clients more recent than Windows 98, performance is good but not excellent. Data transfer rates run at about 80% to 85% of the speed of the underlying connection. MPPE/PPTP performance with Windows 95 and Windows 98 clients is not nearly as good, particularly in the download direction. Until recently there was often a problem just getting an MPPE/PPTP tunnel from Windows 95/98 clients established at all. However we've found a way to eliminate this problem.

CIPE (Cryptographic IP Encapsulation) CIPE is a type of tunnel developed specifically for Linux. It has superior performance, with measured data transfer rates consistently within one or two percent of the rates for the same transfers done without using a tunnel.

CIPE also has stronger encryption than MPPE/PPTP, and it supports public/private keypairs for authentication. Overall it is an excellent choice for people actually building VPNs, and its performance makes it a good choice for people whose use of a tunnel is just to obtain a static IP. CIPE has been ported to Windows NT and Windows 2000, but we have no experience yet with non-Linux clients. Part of CIPE's performance comes from its use of UDP as the underlying transport protocol. This avoids several types of subtle interactions that can come from multiple TCP layers. These interactions are part of what keeps MPPE/PPTP performance 15% to 20% below that of the underlying connection. CIPE tunnels also are very robust, often staying up for weeks at a time if the tunnel user's non-virtual (carrier) IP address isn't changed. CIPE must be configured into the Linux kernel, usually as a module. Adding it is easy for anyone familiar with building kernels, and at least two distributions, RedHat 7.x/8.x and Mandrake 8.x/9.x, come with CIPE. The CIPE that comes with RedHat is version 1.4, which uses fixed keys for authentication. A newer version 1.5 supports authentication using a utility (pkcipe) for public-key exchange. We run version 1.5 and support pkcipe key exchange, but we also support version 1.4 tunnel clients and fixed keys. More information on CIPE can be found at the CIPE website and the CIPE for Windows NT/2000 website.

OpenVPN OpenVPN is a relatively new multi-platorm tunnel type with excellent performance. OpenVPN runs on Linux, Solaris, OpenBSD, FreeBSD, NetBSD, and Mac OS X. A Windows version is under development. Like CIPE, OpenVPN uses UDP for the underlying transport protocol and has performance almost equal to that of the underlying connection. OpenVPN also includes optional compression, and with compression enabled OpenVPN tunnels can be even faster than the underlying connection, although any speed gain from compression depends a great deal on the type of data being transfered. Unlike CIPE, OpenVPN itself does not need to be configured into the kernel. The daemon runs in user space. However, it does require support in the kernel for the TUN/TAP driver. This is normally included with Linux distributions based on release 2.4 kernels (for example, RedHat 7.1 and later) and is easily added to the release 2.2 kernels of older Linux distributions.

OpenVPN is proving to be a very robust tunnel technology, especially in the face of frequent dynamic-IP changes. Our demonstration tunnel between NetHeaven in the eastern US (upstate NY) and a small web server in Auckland, New Zealand uses OpenVPN. More informtion on OpenVPN is available at the OpenVPN website.

SSL-wrapped PPP These tunnels are based on the open source UNIX stunnel and pppd programs. These make tunnels with good performance that are easy to use with a wrapper script we provide. Although our own experience with these tunnels is only with Linux, they should run equally well on any recent UNIX. Virtually all Linux/UNIX distributions include more or less the same PPP daemon and have PPP support in the kernel. Some Linux distributions include stunnel. If not included, both PPP and stunnel are available on the net in both tarball and RPM formats. The way SSL is used for these tunnels is similar to the way SSL is used for secure web access in that only servers need certificates. However, tunnel clients do need SSL libraries. The SSL we use and recommend is OpenSSL, which is open source and readily available. It is included with some Linux distributions. Whereas MPPE/PPTP first uses PPTP to set up a network-capable tunnel without encryption and then uses MPPE to add encryption, SSL-wrapped PPP tunnels first set up an encrypted channel with stunnel and then use pppd to add network capability. SSL-wrappped PPP tunnels have performance approaching but not quite matching that of CIPE and OpenVPN. In general they are robust and are up weeks at a time, but we have seen one noisy cable connection over which SSL-wrapped PPP could not keep a tunnel up but both CIPE and OpenVPN could.

GRE (Generic Routing Encapsulation) and IP/IP GRE and IP/IP are unencrypted tunnels. They provide virtual connections and static-IP assignment without hiding the communication. For connecting a server to the internet there is little point to encrypting the tunnel anyway, so these can be attractive alternatives due to their simplicity. However, IP/IP tunnels do not provide any authentication, and GRE tunnels provide only weak authentication. IP/IP tunneling is very simple-minded tunneling. The IP payload packet becomes the entire data payload for an IP tunnel carrier packet. Because the payload can be only IP packets, this kind of tunnel can carry only IP traffic.

Because internet traffic is all IP traffic, this limitation is of no significance for tunneling internet traffic. However, people who want to tunnel other protocols (mostly IPX) need a more general tunnel protocol. GRE is essentially a packaging protocol, intended to be able to package any protocol's packets into generic data packages that can be carried by any other protocol. GRE is a foundation protocol for other tunnel protocols. For example, MPPE/PPTP uses GRE to form the actual tunnel. Although GRE has generic tunneling capability, its most common use is for tunnels that carry IP and are carried by IP, and the term "GRE" is often meant to be shorthand for this kind of tunnel. It's this IP-in-GRE-in-IP kind of tunnel that we mean when we say we support "GRE" tunnels. Due to their lack of good authentication, GRE and IP/IP tunnels generally are not very suitable for our users' tunnels uses. However, we do support them, and we have considerable experience with GRE tunnels for our own use. They have excellent performance. When good encryption and authentication are needed, IPSec can provide them.

IPSec (IP Security) IPSec is a developing Internet standard. It has two modes, tunnel mode in which it provides its own tunnels and transport mode in which it provides encryption and authentication on tunnels created some other way (or on real network links). IPSec is the probable long-term direction for tunnels and secure data transmission in general due to its (intended) interoperability and its evolution toward an Internet standard. However, that interoperability is so far still hit-or-miss, mostly miss. IPSec communication has access controls as well as encryption and authentication. Whereas a normal network connection will transmit anything it's asked to, an IPSec tunnel will only tranmit what its configuration specifies. This makes it considerably more complex to use than other types of tunnels. IPSec comes with Windows 2000 and is available as free open source for Linux (as FreeSWAN) and for BSD UNIXes (as KAME). These should all interoperate, but the world isn't quite there yet. We are using Linux FreeSWAN and have had it working with a Windows 2000 client, but we don't regard the combination as robust. Linux IPSec involves changes in the kernel's IP stack and must be built into the kernel. Linux users who build their own kernels will find adding IPSec easy. Those who are not comfortable compiling their own kernels should master that before considering IPSec or should wait for kernel distributions including IPSec. FreeSWAN IPSec authentication/encryption can use SSL, RSA public/private key pairs, or static PSK (Pre-Shared Keys). We support all three. We use IPSec in-house, and for our own use we prefer SSL. When using SSL with IPSec, both ends of the tunnel must

have certficates. We can provide our users with certificates suitable for this use. (Users with OpenSSL also can learn to generate their own private-use certificates.) IPSec tunnels can be any of several types. The three most commonly mentioned are: IPSec tunnel mode tunnels have lower overhead and higher performance compared to running IPSec on tunnels created some other way. However, they are usable only for IP. If a connection that can carry IPX is required, some other form of tunnel is needed. (We do not provide any support for use of IPX. It is mentioned here because we are discussing technologies.) The Windows 2000 implementation of IPSec requires that both ends' carrier IP addresses be known in advance. This makes Microsoft's implementation of tunnel-mode IPSec unusable (or at least not easily usable[*]) for tunnels to give static IPs to clients that don't have them. Linux clients do not need a fixed carrier address in their tunnel configuration, so this type tunnel can be used to give them a static IP. However, we have found this use troublesome, and we recommend using CIPE or OpenVPN instead. IPSec/PPTP tunnels use the same Microsoft PPTP tunnel protocol as MPPE/PPTP tunnels but with IPSec encryption. Windows 2000 includes support for PPTP. Older Windows versions support PPTP but not IPSec, so they cannot use this type of tunnel. Open source PPTP client software for Linux is available on the net. It is easy to build and does not require any kernel modifications, but IPSec does need to be built into the kernel. IPSec/L2TP tunnels use L2TP (Level-2 Tunnel Protocol) to establish the tunnel and then run IPSec encryption on it. L2TP is very similar to PPTP but has a multi-vendor origin. Windows 2000 includes L2TP, but older Windows versions do not. An open source L2TP implementation is available on the net for Linux and BSD UNIX, is simple to build, and requires no kernel modification. However, Linux and BSD do need IPSec built into the kernel. L2TP/IPSec isn't a tunnel type, but it is a different way of using L2TP and IPSec together that has become common and is described in RFC 3193. It's not relevant to this page, but we've added this paragraph to stop people from saying our IPSec/L2TP description is wrong. The RFC 3193 use is analogous to using a conduit to run wires through a hazardous area, with the internet being the hazard zone, an ordinary IPSec tunnel being the conduit, and L2TP tunnels being the otherwise unprotected wires. IPSec/GRE tunnels layer IPSec directly onto plain GRE tunnels as mentioned above under GRE and IP/IP tunnels. IPSec can be layered onto any kind of tunnel, just as it can be used over physical network connections. However, in most cases there isn't much point to running IPSec over a tunnel that's already encrtypted and authenticated.

Other There are other types of tunnels as well. We are still looking into some of them and may support them in the future, especially if there are requests. We began supporting OpenVPN because a prospective user asked for it.