Virtual private network technology is based on the idea of tunneling. VPN tunneling involves establishing and maintaining a logical network connection (that may contain intermediate hops). On this connection, packets constructed in a specific VPN protocol format are encapsulated within some other base or carrier protocol, then transmitted between VPN client and server, and finally de-encapsulated on the receiving side. For Internet-based VPNs, packets in one of several VPN protocols are encapsulated within Internet Protocol (IP) packets. VPN protocols also support authentication and encryption to keep the tunnels secure.


VPN supports two types of tunneling – voluntary and compulsory. Both types of tunneling are commonly used. In voluntary tunneling, the VPN client manages connection setup. The client first makes a connection to the carrier network provider (an ISP in the case of Internet VPNs). Then, the VPN client application creates the tunnel to a VPN server over this live connection.

In compulsory tunnelling, the carrier network provider manages VPN connection setup. When the client first makes an ordinary connection to the carrier, the carrier in turn immediately brokers a VPN connection between that client and a VPN server. From the client point of view, VPN connections are set up in just one step compared to the two-step procedure required for voluntary tunnels. Compulsory VPN tunnelling authenticates clients and associates them with specific VPN servers using logic built into the broker device. This network device is sometimes called the VPN Front End Processor (FEP), Network Access Server (NAS) or Point of Presence Server (POS). Compulsory tunnelling hides the details of VPN server connectivity from the VPN clients and effectively transfers management control over the tunnels from clients to the ISP. In return, service providers must take on the additional burden of installing and maintaining FEP devices.


Several computer network protocols have been implemented specifically for use with VPN tunnels. The three most popular VPN tunneling protocols listed below continue to compete with each other for acceptance in the industry. These protocols are generally incompatible with each other.

Point-to-Point Tunneling Protocol (PPTP)
Several corporations worked together to create the PPTP specification. People generally associate PPTP with Microsoft because nearly all flavours of Windows include built-in client support for this protocol. The initial releases of PPTP for Windows by Microsoft contained security features that some experts claimed were too weak for serious use. Microsoft continues to improve its PPTP support, though.

Point-to-Point VPN
Another site to site VPN is a point-to-point simply put; two or more networks are connected using a dedicated line from an ISP. These are usually T1’s, Metro Ethernet, or OC lines. The main strength of using a leased line is that is a circuit-based point-to-point connection. It does not go out over the public Internet, so there performance is not degraded by routing problems, latency, and external congestion.

Layer Two Tunnelling Protocol (L2TP)
The original competitor to PPTP for VPN tunnelling was L2F, a protocol implemented primarily in Cisco products. In an attempt to improve on L2F, the best features of it and PPTP were combined to create a new standard called L2TP. Like PPTP, L2TP exists at the data link layer (Layer Two) in the OSI model — thus the origin of its name.

Internet Protocol Security (IPSec)
IPSec is actually a collection of multiple related protocols. It can be used as a complete VPN protocol solution or simply as the encryption scheme within L2TP or PPTP. IPSec exists at the network layer (Layer Three) of the OSI model.


OpenVPN is a free and open source software application that implements virtual private network (VPN) solutions for creating secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. It uses Secure Socket Layer (SSL) security for encryption and is capable of traversing network address translators (NATs) and firewalls. It was written by James Yonan and is published under the GNU General Public License (GPL).

OpenVPN allows peers to authenticate each other using a pre-shared secret key, certificates, or username/password. When used in a multiclient-server configuration, it allows the server to release an authentication certificate for every client, using signature and Certificate authority. It uses the OpenSSL encryption library extensively, as well as the SSLv3/TLSv1 protocol, and contains many security and control features.


VPN services can be offered based on two major paradigms:

  1. The overlay VPNs, whereby the service provider furnishes virtual point-to-point links between customer sites.
  2. The peer-to-peer VPNs, whereby the service provider participates in customer routing.

In the following sections, we discuss these two different models in details.

Overlay model
The overlay VPN is deployed via private trunks across a service provider‘s shared infrastructure. These VPNs can be implemented at layer-1 using leased/dialup lines, at layer-2 using X.25/frame relay/ATM Virtual Circuits, or at layer-3 using IP (GRE) tunneling. In the overlay VPN model, the service provider network is a connection of point-to-point links or virtual circuits (VCs). Routing within the customer network is transparent to the service provider network, and routing protocols run directly between customer routers. The service provider has no knowledge of the customer routes and is simply responsible for providing point-to-point transport of data between the customer sites. Figure illustrates the deployment of an overlay VPN. The scenario adopts a hub- and-spoke topology whereby the Paris site is the hub, and both the London and Zurich sites are the spokes. The London site is linked up to the Paris site via a point-to-point VC #1. Likewise, the Zurich site is linked up to the Paris site via a point-to-point VC #2. In this instance, the layer-3 routing adjacencies are established between the CE routers at the various customer sites, and the service provider is not aware of this routing information at all. As illustrated in Figure from the perspective of the CE routers, the service provider infrastructure appears as point-to-point links between Paris–London and Paris–Zurich. The overlay VPN model has two further constraints. One is the high level of difficulty in sizing the intersite circuit capacities. The other is the requirement of a fully meshed deployment of point-to-point links or VCs over the service provider‘s backbone to attain optimal routing.

Peer-to-peer model
The peer-to-peer model adopts a simple routing scheme for the customer. Both provider and customer network use the same network protocol and all the customer routes are carried within the core network (service provider network). The PE routers exchange routing information with the CE routers, and layer-3 routing adjacencies are established between the CE and PE routers at each site. Because peer-to-peer routing has been implemented, routing between sites is now optimal. Fully meshed deployment of point-to-point links or VCs over the service provider backbone is no longer applicable to attain optimal routing. Since there is no overlay mesh to contend with, the addition of new sites is easier, and circuit capacity sizing is not an issue. Because the service provider now participates in customer routing, provider-assigned or public address space needs to be deployed at the customer‘s network, so private addressing is no longer an option.
In this scenario, customer routing information is exchanged between Paris-CE and Paris-PE. The customer routes are then broadcast through the core network to London-PE and Zurich-PE, which in turn, propagate these routes to their respective CE routers.

For any query or issue, feel free to discuss on http://discuss.eduguru.in