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.
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 transmit 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 certificates. 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 encrypted and authenticated.