Virtual private network

A virtual private network (VPN) "is simply defined as the 'emulation of a private Wide Area Network (WAN) facility using IP facilities' (including the public Internet, or private IP backbones). As such, there are as many types of VPNs as there are types of WANs, hence the confusion over what exactly constitutes a VPN..."

Motivations for VPNs

Before the term VPN came into general use, other terminology was used. Some authors discourage the terms, but others find they are a valuable complement to the more technical VPN terminology, as they emphasize business relationships.

The most basic motivation to have a VPN is financial: if the customer does not have to build a private network but can map it onto a commodity IP service, both the capital and operational costs drop. Small users, who might not be able to fund highly skilled networking personnel, can outsource that cost. Indeed, cloud computing technology is a superset of VPNs, which outsources servers as well as the network.

It is a wise provider that arms its sales personnel with a set of basic questions to determine the customer requirement. The customer usually can articulate a set of requirements:

• Availability & Performance
• Security
• Compatibility with existing networks and servers
• Network management approach
• Budget

Providers also speak informally of "clue factor", or the knowledge level of the customer. Some VPN technologies are too complex for customers, or, indeed, service providers. For example, it has been easier for many traditional telephone companies to use "layer 2 VPN" technology to emulate existing Frame Relay or dedicated line services, rather than train technicians in routing.

Administrative control

If all the sites are under the control of a single network administration authority, such as an enterprise, the VPN is called an intranet. If the sites are under the control of multiple administrators that have agreed to technical and operational policies, the VPN is called an extranet.

The global Internet is under the control of multiple administrators that agree to exchange reachability to a set of addresses under the authority of the Internet Assigned Numbers Authority (IANA), using the Border Gateway Protocol. A number of large SPs are treating their customers' public Internet connectivity as "just another VPN", yet one that is totally isolated from the intranets and extranets. Modern VPN technology lets the same addresses appear, without conflict, in multiple VPNs.

Frequent misconceptions

• "VPNs can directly replace frame relay or private line facilities at much lower cost." VPNs, unless contractually required to do so, will not have the guaranteed performance of these older facilities, and indeed may be less reliable.
• "VPNs are necessary to do business on the Internet." Since VPNs require their members to be registered before they can connect, they are useless for consumer-to-business sales, where the customer is not known before the transaction. They are, however, very useful for business-to-business.

User experience

When a computer end user brings up the local VPN software, called the VPN client, on a computer that has previously had general Internet connectivity, that connectivity will cease, or be under the control of the VPN.

Technical framework

General Internet connectivity onto which VPNs will be overlaid. Note that while all nodes interconnect, they are not necessarily adjacent

In almost all cases a VPN is an overlay network onto a lower-level connectivity network, such as the Internet, a non-public set of IP nodes over a private routed network, or IP over on-demand services such as dialup.

Two VPNs and a set of sites. VPN A is 1-6-2-4 and VPN B is 1-5-3

Implementation architecture

Customer organizations may have a network support group that runs a backbone, through which multiple, administratively isolated, VPNs can run. For example, an enterprise with multiple physical sites, connected by satellite links, might have separate VPNs for finance, manufacturing, research, and human resources. When a backbone is administered in this manner, the VPNs are called customer-provisioned VPNs (CPVPN).

Alternatively, the enterprise(s) can contract with a SP to operate the VPNs. The customer needs to tell the SP how many isolated VPNs are needed, the address spaces that each will use, and the quality of service, availability, and bandwidth that will be required. In this case, if the customer has no involvement in the SP backbone, the VPNs are called provider-provisioned VPNs (PPVPN)s.

In PPVPNs, the customer sites interconnect to a backbone is operated by a service provider, who provides VPN service to the customers. A customer may be a single enterprise, a set of enterprises, an Internet Service Provider (ISP), an Application Service Provider (ASP), another SP that offers the same kind of VPN service to its own customers (i.e., a VPN "wholesaler"), etc.

Initially, think of the sites speaking to the backbone through some mutually agreed protocol; the concept of a VPN works with a wide variety of protocols, as long as they are mutually agreed among the sites and compatible with the backbone infrastructure. The backbone providing connectivity is typically overlaid onto some physical or logical infrastructure, so that the "provider backbone" can contain multiple VPNs. Another way to phrase this relationship is that the VPNs are tunneled through the provider backbone.

Sites connect to the "(inter-site) backbone" through customer edge (CE) devices or functions. The CE need not be a physical device. A CE may be aware of multiple VPNs.

There are many situations where a given enterprise, or set of enterprises forming an extranet, may use a combination of CPVPNs and PPVPNs.

Customer provisioning

Two customer-provided VPNs

In a customer-provided VPN, the customer manages connectivity among the CE. It is possible and common to have CPVPNs tunnel among customer sites using a secure tunneling protocol, such as IPSec, over physical connections to Internet Service Providers. The ISP, in such cases, will be completely unaware of the VPNs.

Provider provisioning

Two VPNs via provider facilities

In a provider-provisioned VPN, the CE provide reachability information to provider edge (PE) devices or functions that are aware of both the VPN, and the provider backbone onto which the VPNs are mapped. Again, a PE need not be a physical device. Most often, however, it is a router.

Observe, however, that the CE at Site 1 is multihomed, for fault tolerance, to two diverse PE. Not shown in this level of diagram, but a CE also could be fault tolerant, with redundant components.

The PEs are aware of the VPNs, but also of the interconnection of PEs, which is hidden from the customers. PEs can require significant control plane processing power both to route and to maintain VPN information.

Internal to the provider backbone may be provider (P) devices or functions that maintain connectivity in the provider backbone, but are themselves unaware of the VPNs.

PPVPN environment with P core

A routing protocol runs among them, but simply passes the reachability of the P's and PE's. Links to and among P devices usually are very high capacity. In most large provider, they are multigigabit optical facilities. The physical devices on which the P function is implemented does not need a powerful control plane but is optimized in the forwarding plane.

Connectivity to the CE and PE

While the first VPNs used Internet Protocol version 4 (IPv4) for connectivity to the CE if the CE was an onsite physical device operated by the SP, or from the CE to the PE if the CE belongs to the customer, the VPN is not limited to running as a routed network. In a given environment, there may be:

• Routed (OSI Layer 3) VPNs using IPv4 or Internet Protocol version 6 (IPv6). IPv4 address space is becoming scarce, so a very practical application may be to run IPv4 VPNs over an IPv6 backbone; only CEs and PEs would need to support IPv6.
• Layer 2 VPNs (L2VPN), which present frame relay or Asynchronous Transfer Mode (ATM) interfaces to the customer equipment. This is very useful to keep supporting old equipment that only has FR or ATM interfaces. "Layer 2.5" VPNs can present Multi-Protocol Label Switching (MPLS) interfaces to customer-owned equipment that understands that protocol; even commercial FR and ATM services frequently run over MPLS internal to the SP backbone. It is also possible for the VPN to run a local area network protocol such as IEEE 802.3 or a virtual LAN protocol such as IEEE 802.1Q.
• Layer 1 VPNs, where the VPN interface appears as an 802.3 or serial communications interface that accepts bit streams.

Some L2 offerings are called virtual private LAN service, while other L1 offerings are called virtual private line service, both having the abbreviation VPLS. Using L2VPN and L1VPN is much less likely to lead to confusion.

L2VPNs and L1VPNs usually need a routing protocol to pass VPN administration information, although there are provider-provisioned autodiscovery mechanisms that will isolate the customer from this requirement.

Communicating policies and reachability between customer and provider

Depending on the type of VPN in use, the customer may run a routing protocol internal to the customer sites, of which the SP need not be aware.

If the customer needs to tell the PE what VPNs exist, what address spaces each support, and even if there are restrictions on connectivity within a single VPN, then this needs to be manually configured, which is maintenance-intensive, or the information can be sent through extensions to a routing protocol such as the Border Gateway Protocol (BGP) or Open Shortest Path First (OSPF)

Secure VPNs

The policies and procedures for any virtual private network must include some means of ensuring privacy. One definition runs:

A virtual private network (VPN) is a private data network that makes use of the public telecommunication infrastructure, maintaining privacy through the use of a tunneling protocol and security procedures. ...

There are many ways to manage the privacy requirements. Security requirements, policies and procedures can all be different in various applications, and several different tunneling protocols are available.

In a trusted VPN, the security is part of the service; in effect the customer trusts the service provider to maintain data integrity and privacy.

Before the Internet became nearly-universal, a virtual private network consisted of one or more circuits leased from a communications provider. ... The VPN customer trusted the VPN provider to maintain the integrity of the circuits and to use the best available business practices to avoid snooping of the network traffic. Thus, these are called trusted VPNs.

Of course this can be done over virtual circuits as well as over physical ones. In a fairly common example, Asynchronous Transfer Mode connections support an Internet Protocol service.

In a secure VPN, encryption is used to achieve privacy.

As the Internet became more popular ... Seeing that trusted VPNs offered no real security, vendors started to create protocols that would allow traffic to be encrypted at the edge of one network or at the originating computer, moved over the Internet like any other data, and then decrypted when it reached the corporate network or a receiving computer. This encrypted traffic acts like it is in a tunnel between the two networks: even if an attacker can see the traffic, they cannot read it, and they cannot change the traffic without the changes being seen by the receiving party and therefore rejected. Networks that are constructed using encryption are called secure VPNs.

A number of different encrypting protocols may be used to construct a secure VPN. IPsec is most often used for secure VPNs between an organisation's offices and may also be used for "road warriors", individuals connecting to the organisation's network from home or from laptops. VPNs based on SSL are also common; for example, many companies (e.g. [1] [2]) offer a single user VPN service for users who need to circumvent the Great Firewall of China or other censorship. A similar service may also be provided using PPTP or SSH.

A hybrid VPN has elements of both the other types.

A secure VPN can be run as part of a trusted VPN, creating a third type of VPN that is very new on the market: hybrid VPNs. The secure parts of a hybrid VPN might be controlled by the customer (such as by using secure VPN equipment on their sites) or by the same provider that provides the trusted part of the hybrid VPN.