VPN Implementations

Throughout the chapter up to this point, I have repeatedly referred to "VPN implementations," but haven't defined what a VPN implementation actually is. First, let me discuss what a VPN is and what it can encompass. Specifically, the following sections will discuss these popular VPN implementation methods, including how they are implemented, and their basic advantages and disadvantages:

• GRE
• IPsec
• PPTP
• L2TP
• MPLS
• SSL

Other chapters in the book will expand on many of these VPN implementations, so the material you see in the following sections is a basic overview.

GRE

Generic Route Encapsulation (GRE) is a VPN technology originally developed by Cisco and later written up under two Internet Engineering Task Force (IETF) RFCs1701 and 2784. Cisco developed GRE as an encapsulation method to take a packet from one protocol, encapsulate it in an IP packet, and transport the encapsulated packet across an IP backbone.

Figure 1-11 to illustrates the usefulness of GRE tunneling. In many earlier networks, companies had problems moving traffic between various networking locations where the backbone of the network, or the WAN connection, didn't speak the same protocol. In Figure 1-11, two Novell IPX networks need to communicate with each other. In this example, they are connected via the Internet, which is IP-based. Without GRE, the Novell devices would have to speak both IP and IPX: IPX for access internal services and IP for the remote site's services. Cisco developed GRE specifically for this problem. GRE allows you to take a packet from one protocol, such as IPX, and encapsulate it in an IP packet (where the IP protocol number is 47, representing GRE-encapsulated information).

Figure 1-11. GRE Example

In Figure 1-11, the perimeter routers at the two sites perform this encapsulation/de-encapsulation process. From the Internet's perspective, it only sees IP packets; from the corporate and regional offices' perspectives, they see only IPX packetswhich makes everyone happy.

GRE was, and still is, used to connect small pockets of a particular protocol across an IP-based backbone without having to configure the backbone to also run additional protocols. GRE, which is a Layer-3 IP protocol, can encapsulate the following protocols:

• AppleTalk
• Banyan Vines
• Layer-2 bridged traffic
• CLNP
• DECnet
• IP
• IPX

Given its flexibility of encapsulating many protocols, you would think that GRE would be a great VPN solution, at least compared to other VPN solutions with limited protocol support. However, GRE has two main disadvantages:

• From a Cisco-product perspective, GRE works only on Cisco IOS-based routers.
• GRE lacks protection capabilities; in other words, it doesn't perform tasks such as identity authentication, encryption, and packet integrity checking.

Because of these two limitations, GRE is typically not used as a complete VPN solution; however, it can be combined with other solutions, such as IPsec, to create a more robust and scalable VPN deployment.

IPsec

Like GRE, IPsec (short for IP Security) is a Layer-3 protocol. However, there are very few similarities between the two protocols. One advantage of GRE over IPsec is that IPsec only supports TCP/IP protocolsit can't natively transport protocols like IPX or AppleTalk. However, because GRE is an IP protocol, you can deploy a GRE tunnel through an IPsec VPN connection to protect non-TCP/IP traffic.

IPsec is actually a combination of standards defined in IETF RFCs. Where GRE doesn't provide any security, IPsec was designed specifically to deal with moving sensitive data, securely, across an unsecured network. The framework of IPsec deals with the following three main issues:

• Data confidentiality
• Data integrity
• Data authentication

Data confidentiality deals with protecting data from eavesdropping attacks. This is accomplished by using encryption. IPsec supports DES, 3DES, and AES encryption algorithms. Data integrity deals with verifying whether or not packet contents have been tampered with. This is accomplished by using hashing functions such as MD5 and SHA. Data authentication is used to perform packet and device authentication. Hashing functions are used to verify the identity of the device sending the IPsec packets. Device authentication is used to control which remote devices are allowed to establish IPsec connections to a local device. Three types of device authentication are supported: pre-shared keys, RSA encrypted nonces, and RSA signatures (digital certificates). For remote access connections, user authentication is typically employed.

As compared to other VPN implementations, IPsec is the most popular and most widely deployednot because IPsec is easy to set up and troubleshoot, as you'll see later in this book, but because it is a set of open standards and has been pushed most often by networking vendors when the standards were first ratified. Most networking vendors, when offering a VPN solution, will minimally support IPsec. For example, all of the Cisco devices that support VPN functionality support IPsec. I discuss IPsec in more depth in Chapter 3.

PPTP

The Point-to-Point Tunneling Protocol (PPTP) was originally developed by Microsoft. Its operation is published in RFC 2637. Microsoft developed PPTP to provide a VPN solution for Windows-based systems, such as Windows 95, 98, ME, NT, 2000, and XP. Unlike IPsec, which supports all VPN connection types including site-to-site and remote access, PPTP was developed to allow Windows PC clients secure access to a network access server, such as a Windows remote access server (RAS). Therefore, PPTP is used primarily as a remote access protocol, but it does support site-to-site connectivity.

PPTP is actually a combination of two standards:

• Point-to-Point Protocol (PPP) This standard is used to define the encapsulation process: PPTP encapsulates PPP packets, containing the payload, within an IP packet, which is transported across a network.
• Microsoft Point-to-Point Encryption (MPPE) This standard is used to provide for data confidentiality (encryption) for PPTP.

Unlike IPsec, which only supports TCP/IP protocols, PPTP supports multiple protocols: TCP/IP, IPX, and NetBEUI. Many of the Cisco products, including IOS routers, PIX firewalls, and VPN 3000 concentrators, support PPTP. I'll discuss PPTP in more depth in Chapter 4, "PPTP and L2TP."

L2TP

One problem with using PPTP is that even though the process was defined later in an IETF RFC, PPTP was a semi-open standard. In other words, if you worked in a Microsoft environment, or with vendors that worked closely with Microsoft, deploying PPTP worked well. However, PPTP typically would not work in a mixed-vendor networking environment.

At that time, other vendors also had semi-open VPN types, including Cisco. The Cisco VPN type was called Layer-2 Forwarding (L2F). To provide an alternative solution to IPsec that fit better into smaller Windows PC-based environments, Microsoft, Cisco, and other vendors worked together to develop a VPN standard that would allow all network vendors to produce compatible VPN products.

Basically, L2TP (Layer 2 Tunnel Protocol) is a combination of Cisco L2F and Microsoft's PPTP. L2TP tunnels PPP over a public network, providing services such as data confidentiality. And like GRE, L2TP supports multiple Layer-3 protocols. L2TP incorporates a modified version of Multi-chassis Multilink PPP, which allows a client to stack VPN gateways, making them appear as a single virtual VPN gateway device. L2TP can use MPPE for protection, but like PPTP, this is not as robust as IPsec's protection mechanisms. Because of this, L2TP typically uses IPsec as a protection transport, while still providing some of the same services that Windows environments might need via PPTP.

Cisco no longer supports L2F, but currently supports L2TP on the router, PIX, and concentrator platforms. I'll discuss L2TP in more depth in Chapter 4.

MPLS

Multi-Protocol Label Switching (MPLS) specifies how packets are sent to a destination in an efficient manner, similar to how traffic is managed in a Frame Relay or ATM network, where QoS is supported. MPLS VPNs are sometimes referred to as an enhancement to MPLS; however the term "MPLS VPN" can be very confusing because an MPLS VPN isn't encrypted and the actual data circuit doesn't even traverse a public network such as the Internet!

MPLS circuits are commonly referred to as a VPN. Where IPsec creates a secure connection (tunnel) across a public network, MPLS uses a virtual circuit (VC) across a private network to emulate the VPN function. If you think about the term "virtual private network," a PVC or SVC emulates this type of function in a Frame Relay or ATM network. With MPLS, the tagging information in the MPLS label added to the data provides the segregation function. MPLS can even provide this function in Ethernet backbones. In other words, your traffic is segregated from other people's traffic in the MPLS network. Therefore, your traffic in the carrier's network can be considered "private." Of course, if you're concerned about whether the carrier is eavesdropping on your traffic, an MPLS solution won't solve this problem; you'll have to complement it with another VPN solution, such as IPsec over MPLS.

MPLS is similar to VLAN tagging in Ethernet networks; however, unlike Ethernet VLANs, MPLS supports multiple protocols. In other words, you can use MPLS to tag IP packets, Ethernet frames, IPX packets, and much more. And unlike VLAN tagging, MPLS supports broad QoS abilities. Other than the information discussed in this section, MPLS and MPLS VPNs are beyond the scope of this book.

SSL

Secure Socket Layer (SSL) is an existing technology to encrypt data sent via a web browser connection. Until recently, it was used solely to secure web connections and transactions. However, networking vendors have enhanced SSL to provide SSL-based VPNs. SSL VPNs are used as a remote access VPN solution. One issue with other types of VPNs, such as IPsec, PPTP, and L2TP/IPsec, is that they require special client software to be installed on the remote access client. This requires special configuration and additional management.

With clientless SSL VPNs, a user uses a web browser as the client software. And because most users have a web browser already installed on their PCs and are very comfortable with web browser applications, there is basically no special client software nor any learning curve involved to use the SSL VPN. SSL VPNs, however, have one limitation: because they are implemented at the application layer, only web-based applications (those via a web browser) can be protected. Other applications, by default, are not protected. In some instances, an SSL VPN vendor can write special code on the SSL VPN gateway device to handle additional applications. But as to what applications are actually supported, this will vary from vendor to vendor. In this instance, a Layer-3 VPN solution, such as IPsec or L2TP/IPsec, would be better because they can protect all traffic from the network layer and above; in other words, these VPNs are not application-specific. SSL VPNs are discussed in more depth in Chapter 5, "SSL VPNs."