Virtual private networks, or VPNs, allow you to use public networks, such as the Internet, as your own private, secure network connection. Many companies use VPNs to connect branch offices to headquarters via the Internet. VPNs rely on data encapsulation and encryption to work and provide reliable, secure connectivity options for remote access.
Understanding how a VPN works requires you to first understand the basic nature of modern networking. Networks use layered protocols, called stacks, to perform various functions. Users interact most directly with the application layer, which is located at the top of the network stack. A web browser, for example, uses the application-level protocol HTTP.
The collection of wires and electrical signals that form a network exists at the bottom layer of the stack. In between the high- and low-level protocols are midlevel protocols that package data for delivery to specific machines and make sure the data arrives safely at its destination.
When your web browser transmits an HTTP request, your computer's IP stack packages, or encapsulates, that request in a packet that uses the TCP protocol. The TCP packet is then encapsulated within a lower-level IP packet, then again within an Ethernet packet. The Ethernet packet contains the information necessary for the data to be translated into electrical signals and placed onto the network. The IP and TCP protocols contain information necessary for routers to get the data to the correct destination. Once the packet arrives at its destination, its various layers are stripped away by the recipient's network stack, revealing the original HTTP request. Figure 14-7 shows a logical diagram of how encapsulation works.
VPN protocols step in before packets are handed off to your computer's network hardware. They encapsulate the data one more time, within a VPN packet. In fact, your computer often sees a VPN as a "virtual network adapter" and passes packets to that "adapter" for final transmission. The VPN adapter encapsulates the data and passes it to your computer's real network interface card (NIC), which places the packet onto the network. Figure 14-8 shows the virtual adapter in action.
Once the data arrives at its destination, the recipient's network adapter passes the data to another virtual network adapter, which strips off the VPN packet information and passes the remaining data to the computer's TCP/IP stack, where the data is processed normally.
Because your computer treats the virtual adapter as a real network adapter, your computer thinks that it has established a private, point-to-point connection with the computer on the other end of the VPN. In effect, a virtual tunnel exists between the two computers. All data entering the tunnel is packaged by the VPN protocol and sent directly to the other end of the tunnel, where the data can be unpackaged and read.
There are two common VPN protocols, which are supported by Windows Server 2003.
PPTP was originally created by Microsoft and introduced in Windows NT 4.0's Routing and Remote Access Services. PPTP encrypts the data it encapsulates, but it does not encrypt the VPN's header data. That means an eavesdropper can detect that a PPTP tunnel is in use and can identify the packets "contained" within the tunnel. However, the eavesdropper would still have to break the decryption on the tunnel's contents to read the data moving through the tunnel. PPTP is widely supported within the Windows product line all the way back to Windows 95.
L2TP is the newest VPN protocol and provides only the tunneling aspect of a VPN, not encryption. However, L2TP is usually used in conjunction with IPSec, which encrypts the entire L2TP packet. A primary advantage of L2TP over PPTP is that eavesdroppers cannot tell that a VPN is in use, because IPSec encrypts even the L2TP header information. L2TP also enjoys wider industry support outside of Microsoft. Within the Microsoft product line, L2TP is supported natively on Windows 2000, Windows XP, and Windows Server 2003.
VPNs are inherently rather secure end-to-end connections, simply because of the way they work. However, the way you build a VPN solution into your network can enhance the security of your overall network as well. Here are some tips:
Use remote access policies to restrict the users who can use the VPN, just as you would restrict users who can dial in to your network. VPN connections can be authenticated through RADIUS, allowing you to use IAS for centralized policy management, even if you aren't using Windows-based VPN servers. Instructions for restricting the users of VPNs are provided later in this chapter.
Use L2TP VPNs whenever possible, since they encrypt more of the packets passing through the tunnel. They also provide much stronger encryption than earlier VPN security models.
Where your VPN server is placed on your network is an important security consideration. One technique is to place the VPN server behind your firewall, as shown in Figure 14-9.
That placement works only under a small number of circumstances, though. Depending on the age and patch level of your clients, they may not be able to access the VPN server through the firewall. You may, however, need to configure the firewall to allow the ports and protocols required for RAS. PPTP uses TCP port 1723 and IP Protocol 47. L2TP uses UDP port 1701. If you're using IPSec with L2TP, you must allow IP Protocols 50 and 51 and TCP and UDP port 500.
More commonly, administrators place their VPN server directly on the Internet, as shown in Figure 14-10.
This placement avoids the problems caused by firewalls, but makes your VPN server a target for attackers, who will try and access your corporate network by exploiting security vulnerabilities in the VPN server itself. If the VPN server runs Windows Server 2003, you can lock it down by enabling VPN filters. As shown in Figure 14-11, you can configure the network interface connected to the Internet so that it drops all packets unrelated to the VPN protocol in use (in this example, PPTP, which uses a destination TCP port of 1723). These settings are available as properties of the RAS interface.