Virtual Private Networks (VPNs)
The problem of remote access has appeared many times in this book. This problem has actually been an important issue throughout the evolution of TCP/IP. How do you connect computers that are not close enough for a LAN-style cable connection? System administrators have always relied on two important methods for remote connections:
Dial-up— A remote user connects through a modem to a dial-up server, which acts as a gateway to the network.
Wide area network (WAN)— Two networks are connected through a dedicated leased line connection through a phone company or Internet provider.
Both these methods also have disadvantages. Dial-up connections are notoriously slow, and they are dependent on the quality of the phone connection. A WAN connection is also sometimes slow, but, more significantly, a WAN is expensive to build and maintain, and it is not mobile. A WAN connection is not an option for a remote user of uncertain location traveling with a laptop.
One answer to these problems is to connect directly to the remote network over the open Internet. This solution is fast and convenient, but the Internet is so hostile and insecure that such an option simply is not feasible without providing some way of preventing eavesdropping. Experts began to wonder if there were some way to use the tools of encryption to create a private channel through a public network. The solution to this problem emerged in what we know now as a virtual private network (VPN). A VPN establishes a point-to-point “tunnel” across the network through which ordinary TCP/IP traffic can pass securely.
By the Way
Whereas IPSec (described earlier in this hour) is a protocol that supports secure network connections, a VPN is the connection itself. A VPN application is a program that creates and sustains these private remote connections. Some VPN tools use IPSec for encryption, and others rely on other SSL or other encryption techniques. Microsoft systems used to provide VPN tunneling through the Point to Point Tunneling Protocol (which is derived the PPP modem protocol); More recent Microsoft systems use the Layer 2 Tunneling Protocol L2TP for VPN sessions.
The encryption techniques described earlier in this hour would not work well if every router in the delivery chain needed knowledge of the encryption key. Encryption is intended for point-to-point connections. The idea is that the VPN client software on the remote server establishes a connection with a VPN server that is acting as a gateway to the network (see Figure 23.8). The VPN client and server exchange plain, routable TCP/IP datagrams that pass normally through the Internet. However, the payload (the data) sent through the VPN connection is actually an encrypted datagram. The encrypted datagrams (which are unreadable on the open Internet) are enclosed in the plain, readable datagrams forwarded to the VPN server. The VPN server software then extracts the encrypted datagram, unencrypts the datagram using the encryption key, and forwards the enclosed data to its destination address on the protected network.
Figure 23.8. A VPN provides a private tunnel through a public network.
Although it is possible for an eavesdropping cyber thief to intercept a nonencrypted packet sent between the VPN client and server, the useful information is all within the encrypted payload, which the listener will not be able to unencrypt without the necessary key.
With the arrival of VPNs, it is now common for users to establish secure LAN-like connections with remote networks over the Internet. On most systems, the details of establishing and maintaining a VPN connection are handled within the software. The user just has to start the VPN application and enter authentication information. After the connection is established, the user interacts with the network as if connected locally.