VPN Basics

A VPN is a connection that is established over an existing "public" or shared infrastructure using encryption or authentication technologies to secure its payload. This creates a "virtual" segment between any two entities that have access. This might occur across the shared infrastructure of a local area network (LAN), WAN connections, or the Internet. In this chapter, we focus predominately on VPNs that traverse the Internet as a means to create a secure channel over its public infrastructure. Such channels make for an inexpensive and effective remote networking solution that anyone with Internet access can take advantage of.

VPNs can be categorized into three basic configuration types: host-to-host, host-to-gateway, and gateway-to-gateway. Any of these scenarios could be used with a VPN that is traversing the Internet, although host-to-host VPNs are also popularly used as a means to communicate privately on local network segments.

Regardless of which media the VPN uses, which type of configuration it represents, or what shared infrastructure it crosses, the VPN is a powerful tool that can be used in many different ways to create a secure communication channel.

Note

If you would like to brush up on cryptography fundamentals, take a look at Appendix B, "Crypto 101," where we review key topics in cryptography that you need to know to effectively plan and implement VPNs.

Basic VPN Methodology

The basic concept behind a VPN is securing a communication channel with encryption. Communication can be safeguarded through encryption at many different layers of the network, such as the following:

• Application

• Transport

• Network

• Data link

At the application layer, encryption can be applied with programs such as Pretty Good Privacy (PGP) or through channels such as Secure Shell (SSH). In addition, remote single-session programs such as pcAnywhere and multisession programs such as Terminal Server can be used with encryption to protect remote communications. Most of these programs work from host to host, meaning that they only offer protection for the packet's payload and not the packet. The exception is SSH, which can be used in a port-forwarding mode to create a tunnel. We will cover this in greater detail in Chapter 16.

At the transport layer, protocols such as Secure Sockets Layer (SSL) can be used to protect the contents of a specific communication between two parties. This is typically used via web browser communications. As with application layer protection, the contents of the communication are protected, but the IP packets that carry this information are available for inspection. SSL can also be used as a tunneling facilitator for other communication session types using a product called Stunnel (http://www.stunnel.org/). SSL and its use are covered in greater detail in Chapter 16.

At the network layer, protocols such as IPSec not only encrypt the payload of the packet, but they also encrypt the TCP/IP information. Although the IP address information for the parties that are encrypting and decrypting the packet is necessary to facilitate proper routing, higher-level information, including transport protocols and associated ports, can be completely obfuscated. Endpoint station IP address information can also be hidden if a gateway device such as a router, firewall, or concentrator is doing the encryption, using a concept called tunneling. We will cover IPSec's implementation, its inner workings, and sample configuration in detail in the "IPSec Basics" section, later in this chapter.

Layer 2 Tunneling Protocol (L2TP) is an addition to Point-to-Point Protocol (PPP), which allows the encryption of packets sent over PPP on the data link layer (Layer 2). We cover L2TP and its predecessor PPTP (Point-to-Point Tunneling Protocol) in greater detail later in this chapter, in the "Other VPN Protocols: PPTP and L2TP" section.

Despite the fact that these encryption technologies occur at many different network layers, they all could be part of a VPN. However, some might not be able to handle all the duties of a VPN without some help from other applications or protocols. In this chapter, we predominately discuss the use of network and data link layer encryption technology for VPNs.

What Is Tunneling?

Tunneling is the process of encapsulating one type of packet inside another to facilitate some sort of transport advantage. For example, tunneling could be used to send broadcast traffic across a routed environment or SNMP traffic across the Internet, or to secure IP packets with encryption. One effective demonstration of tunneling as a means of encryption can be illustrated by using a gateway-to-gateway VPN example. The two networks in Figure 7.1 are interconnected via a VPN that is terminated at either end by a firewall.

Figure 7.1. A virtual tunnel is formed across the Internet, connecting the two remote networks.

The firewall in our example translates any packet that is destined for the remote network into encrypted form, and it adds a new IP header to the resultant payload with its own IP address as the source address and the remote firewall's address as the destination IP address of the packet. Encryption hides the actual IP information of the original packet. When the remote firewall receives the packet, it decrypts the packet back to its original form and passes it to the host for which it was originally intended. The virtual segment being created between the two gateway endpoints is called a tunnel. The hosts have no knowledge of the fact that the packets are being encrypted or that they are being sent over a public network. No special software or configuration is required for the hosts. When a host sends a packet that is destined for a host on the remote subnet, the VPN process is handled completely by the gateway devices.

When tunneling is used, even though host system IP addresses are masked from the outside world, they don't have complete anonymity. Because the IP addresses of the gateway devices are available, eavesdroppers can still determine who is communicating with whom. Maybe this won't give away communication streams on a host-to-host level, but it might on a network-to-network level, which could tell an outsider a lot. For example, what if it is rumored that Mr. X is a spy from Switzerland? The government immediately starts to monitor his Internet connection and determines that he is using a VPN. We can't tell what his communications are about. However, if we know Mr. X owns the source address and the destination is somewhere in Switzerland, we might want to investigate further.

Encryption, encapsulation, and tunneling do not make the packets that are being sent inaccessible. The packets can still be gathered and analyzed. However, if a properly implemented, adequately strong encryption algorithm is used, your payload should still be safe. In the next section, we take a closer look at what a gateway-to-gateway tunnel transaction looks like in packet form.

Packet-Level View of Tunneling

The concept of tunneling can be more clearly understood by taking a look at it at the packet level. The following code, which uses tcpdump, shows a packet as it would appear without going through an encrypted tunnel:

[View full width]
 00:05:18.671517 192.168.44.129 > 172.16.1.128: AH(spi=580532459,seq=0x3): 1232 > 80: P 1 :260(259) ack 1 win 17520 (DF) 

This is actually an IPSec packet that uses the Authentication Header (AH) security protocol, which we will cover in greater detail in the IPSec section of this chapter. This packet is sent in a mode that does not require tunneling. The packet traverses directly from one host to the other, without being translated in any way by the gateway devices. Make note of the IP addresses. They represent the addresses of the two hosts. In addition, notice that the transport layer information is available and that this is an HTTP transaction, as signified by the use of TCP port 80. (It is actually the contacting of a web server.) Because the TCP flags are available, we can tell that this is actually the end of the three-way handshake. Host 192.168.44.129 is sending a lone ACK back to the web server at IP address 172.16.1.128.

The following code shows a similar packet that has been encapsulated. It is the same transaction as listed previously, but it is translated by a gateway-to-gateway VPN tunnel. Notice that the IP-level information appears much the same. Also note the lack of Layer 4 TCP information:

 00:01:30.057912 192.168.44.1 > 172.16.1.1: ESP(spi=1302500357,seq=0x3) (DF) 

The source and destination IP addresses changed from the previous packet to this one. This address switch is because the tunneled packet took on the addressing of the source and destination VPN gateways. Layer 4 information (in this case, TCP information) is missing because it, along with the original IP information and higher-level information, is actually encapsulated into the payload of this packet. All we have available is the IP information and the information of the protocol doing the encapsulation (ESP, the Encapsulating Security Payload protocol).