VPNs (Virtual Private Networks)
IPsec VPNs
We can apply the concepts and architecture provided by IPsec when looking at Virtual Private Networks (VPNs). As probably became apparent to you in the previous chapter, especially if you tried the applet, a VPN is a network architecture that enables the operation of private, i.e., secure, networks over a (most likely) public infrastructure, such as the Internet. The meaning of "private", in this sense, is that no unauthorized entity can decipher or change the network traffic. For a network to be truly private, the entity would need to own all of the equipment and have privately owned, or, at the least, leased, links. Clearly this is beyond the reach of almost every corporation (though many corporations used to have expensive private networks, and some still do) if we are talking about anything other than a LAN.
There are several architectures and protocols that can be used to implement the VPN concept, some of which will be surveyed briefly below, but perhaps the most commonly used architecture is the IPsec VPN architecture, in particular, using ESP. I say "perhaps" because, as we shall see below, there are contenders, and markets change. Further, the literature - especially marketing literature - has different views of what actually constitutes a VPN.
VPNs might be implemented by the communicating entities, themselves, which connect IPsec gateways to the Internet, or by network providers who might set up and maintain IPsec gateways (or other VPN endpoint equipment) at the customer's premises. RFC 4026 offers a foundation for a unified terminology for the various types - IPsec-based and others - of provider-provisioned VPNs for end customers.
All VPNs achieve the privacy goal by using encryption. Encryption renders the organization's private traffic unreadable to eavesdroppers who may have access to the infrastructure. VPNs are ideal for organizations with physically remote branches. Instead of leasing an extremely expensive private link between the branches, each branch can create a VPN endpoint using its (cheap) Internet connectivity to communicate securely with other branches using what might be called a site-to-site VPN. The endpoints would be IPsec gateways, such as seen in Figure 43 in the previous chapter. A tunnel mode SA would be defined in each direction between the gateways. The process is transparent to the hosts on the LANs that are served by these gateways. The gateway would encapsulate an entire IP datagram sent from Host D to Host B. Hosts D and B might even be using IP addresses in the private address space - it doesn't matter if the address is public or private, since a new IP header is used to route between the sending and receiving IPsec gateways.
VPNs are also an ideal solution for an individual, perhaps telecommuting, perhaps traveling on company business, who needs to access the secure private network of his/her organization from anywhere around the world. Such a user can use any Internet connection to establish a VPN connection to the organization's VPN. Such a VPN might be called a client-to-site VPN. The remote computer would need to run VPN client software and establish an IPsec tunnel with the IPsec gateway on the private network, over the public infrastructure. Once the tunnel is established, the remote computer virtually becomes a member of the private network: it is able to send and receive traffic from the other hosts in the corporate LAN as if it were physically connected to their LAN. The VPN client can connect from practically anywhere and have any network address.
Other VPN Protocols
In the discussion thus far, we basically assume that the public network used as the transport for a VPN is the Internet. This has certainly become a common implementation. However, we could have a VPN running over other public wide area networks, such as an ATM or other packet switched network, or over the more fashionable layer-two type infrastructure, IP/MPLS. In fact, currently, VPN is one of the popular services that providers provide over MPLS. RFC 4364 describes a method by which a service provider may use IP/MPLS to provide IP VPNs for its customers. The VPN Consortium differentiates between secure VPNs, which typically use IPsec, and trusted VPNs, which typically use MPLS.
The convergence of all types of network services over the Internet, the lower cost of using the Internet, and the ubiquitous nature of the Internet has made the Internet the most common transport for VPNs. Unless there is a need for performance or response time levels or bandwidth guarantees (say for e-learning or collaborative high-powered research) that only a separate data network, or a service like MPLS, could provide, users have little motivation to use more expensive alternative infrastructures. The most popular inter-site applications, such as email and web applications, do not ususally demand better service than the Internet provides.
L2TP (Layer 2 Tunneling Protocol), similar to an IPsec tunnel, encapsulates the users' packets into a standard IP datagram, to be routed through the Internet (or any standard IP network). Therefore, L2TP is transparent to the public IP network. What makes L2TP different from IPsec is that is can be used to encapsulate any kind of data - not just IP. MPLS, on the other hand, is not transparent, and requires MPLS support within the provider network. Clearly, then, this is not a solution for a roaming user, who wants VPN access to his/her home network from anywhere. But, MPLS might be selected for a site-to-site VPN for the purpose of obtaining higher performance than the public Internet might provide. And, like L2TP, it can provide both layer 2 service (called VPLS - Virtual Private LAN Service) and layer 3 service, which means that it can be used for IP traffic or for non-IP traffic.
A contender for IPsec in providing VPN services over the Internet to IP traffic is the TLS VPN (or SSL VPN, but I prefer to use the term that represents the updated standard protocol). One reason that it is a strong contender is that a TLS VPN is considered easier to implement than an IPsec VPN. Though in a previous chapter we looked at TLS as a layer to provide secure services to an application, such as HTTP, TLS can tunnel an entire network stack, and thus provide VPN services.
What is also considered an advantage of TLS VPNs is that the end-user can use a web browser, which already supports TLS, to use TLS VPN services. But this would mean that a TLS VPN is limited to applications that will work in a browser. It also means that it works on an application by application basis, which is not really what a VPN is about. Further, we would not consider a typical secure HTTP connection using TLS a VPN! The claim that a TLS VPN is good because every user already has a browswer appears to be a marketing gimmick. This paper discusses these concepts in greater detail and explains the difference between a true TLS VPN and what are actually TLS gateways. VPNs provide security between hosts on a "virtual link" basis, which means that all the traffic, regardless of the application, would be secured. A TLS tunnel might be used to support a variety of applications.
OpenVPN (which is advocated in the paper that I mentioned in the last paragraph), an open source TLS VPN software package, accommodates a wide range of VPN configurations, including remote access and site-to-site VPNs (plus many other options that are listed on the website). This link has a video of a presentation about and demonstration of OpenVPN, which has become a de facto standard TLS VPN solution.
If you didn't yet take a look at the VPN applet, you can advance and do so now. The applet demonstrates IPsec VPNs, but not TLS VPNs.
