A virtual private network (VPN) is a method of creating a safe and encrypted connection over a less secure network, such as the public internet. A VPN works by using the shared public infrastructure while maintaining privacy through security procedures and tunneling protocols.
This article has two main sections. The first section introduces the basic concept of a VPN and discusses some details of two main method to build a VPN connection: IP Security (IPsec) and Secure Sockets Layer (SSL).
The second section looks at one of the fundamental building blocks of VPNs, the theory of building a tunnel between two routers, as created by an IP network.
Leased lines like cable or digital subscriber line (DSL) have some wonderful security features. The router on one end knows with confidence the identity of the device on the other end of the link. The receiving router also has good reason to believe that no attackers saw or changed the data in transit.
VPNs provides the same secure features as a leased line while sending data over a network that is open to other parties. In fact, the data often crosses the Internet. Even when sending data over public networks like the Internet, VPNs can provide some beneficial features:
- Confidentiality (Privacy): Preventing anyone in the middle of the Internet (man in the middle) from being able to read the data.
- Authentication: Verifying that the sender of the VPN packet is a legitimate device and not a device used by an attacker.
- Data integrity: Verifying that the packet was not changed while being transited over the Internet.
- Anti-replay: Preventing a man-in-the-middle from copying and later replying the packets sent by a legitimate user, for the purpose of appearing to be a legitimate user.
How VPN works
The cost of a high-speed Internet connection is usually much less than that of many modern leased WAN lines. The Internet is seemingly everywhere, making this kind of solution available worldwide. Incorporating VPN technology in World Wide Web and using the related protocols we can provide a cheap and yet a secure communication.
The figure below shows the general idea of what typically occurs inside a VPN tunnel. The figure shows a VPN created between a branch office router and a security device (ASA). In this case, the VPN is called a site-to-site VPN because it connects two remote sites that belong to a company.
The figure shows that the following steps are needed in order to secure connection to be established:
- Host PC1 (10.2.2.2) on the right sends a packet to the web server (10.1.1.1), just as it would without a VPN.
- The router encrypts the packet, adds some VPN headers, adds another IP header (with public IP addresses) and forwards the packet.
- A man in the middle copies the packet, but cannot change the packet without being noticed, and cannot read the contents of the original packet.
- ASA-1 receives the packet, confirms the authenticity of the sender, confirms that the packet has not been changed, and then decrypts the original packet.
- Server S1 receives the unencrypted packet.
RFC 4301 explains and defines how IPsec is used between two devices connected to the Internet to provide confidentiality, authentication, data integrity, and anti-replay. Building a VPN connection is not the only capability of IPsec but it’s also able to provide several different options as additional features over a VPN connection.
One of IPsec’s strengths is its role as an architecture that allows it to be added to other security functions and bring additional levels of security over time in a network. The complete details of IPsec’s functionality is beyond the scope of this article, but the following section gives you some general idea of how two endpoints in a network encrypt data by using IPsec.
IPsec encryption uses a pair of mathematical algorithms or formulas that are needed to build a secure connection. These algorithms must be identical on both ends:
- One to hide (encrypt) the data
- another to re-create (decrypt) the original data
Beside those obvious functions, the two math formulas were chosen so that if a third party intercepts the encrypted text but doesn’t have the secret password (called an encryption key), decrypting the packet would be nearly impossible.
In addition, the formulas are also chosen so that if an attacker did happen to decrypt one packet, that information would not give the attacker any advantages in decrypting the other packets.
How IPsec works
The four steps highlighted in the figure below show data is delivered after an IPsec connection is established.
- The sending VPN device (like the remote office router in the first figure) feeds the orignal packet and the session key into the encryption formula to calculate and create the encrypted data.
- The sending device encapsulates the encrypted data into a packet which includes the new IP header and VPN header.
- The sending device sends this new packet to the destination VPN device which is ASA-1 (refer to Figure 1).
- The receiving VPN device takes the encrypted data and session key and runs the corresponding decryption formula – the same key value as was used on the sending VPN device – to decrypt the data inside.
algorithms, plus they often use longer encryption keys. These changes make it more difficult for attackers to decrypt any data being transmitted over an unsecured network, like the Internet.
The Secure Socket Layer (SSL) protocol serves as an alternative VPN technology to IPsec. In
particular, today’s web browsers support SSL as a way to dynamically create a secure connection
from the web browser to a web server. The most obvious usage is supporting safe online access to financial transactions.
Web browsers use HTTP as the main protocol to connect to web servers. However, when the communications with the web server need to be secure, the browser switches to use SSL. It uses the well-known port number 443 to send the encrypted data between the browser and the server. This port is also used for authenticating the end user.
The built-in SSL functions of a web browser create a secure web browsing session, but the same SSL technology can be used to create a remote access VPN by using a Cisco VPN client. The
Cisco AnyConnect VPN client is a famous software that can be installed on a user’s PC and uses SSL to create one end of a VPN remote-access tunnel. As a result, all the packets sent to the other end of the tunnel are encrypted.
Finally, note that many types of devices can sit on the server side of an SSL connection as well.
The web server can be the endpoint of an SSL connection that is coming from a web browser but in order to improve server performance, specialized devices like the Cisco ASA are often used on the end of the SSL tunnel.
The device on the endpoint of a VPN takes a normal unencrypted packet and performs several functions before forwarding that packet. One of those functions is to encrypt the packet, and another is to encapsulate the packet in a new IP header.
The new IP header uses addresses that allow the routers in an unsecured network between the two endpoints in a VPN tunnel to forward the IP packet. The original IP packet, including the original IP header, is encrypted and unreadable.
Generic Routing Encapsulation (GRE) is defined in RFC 2784 which adds additional IP header to the packet and encapsulate the original packet. The first part of the following section shows how packets can be routed over a GRE tunnel, much like using a serial link inside a secured enterprise network. The rest of this article then explains how GRE does its job.
Routing over GRE Tunnels
A GRE tunnel exists between two routers, with the tunnel working very much like a serial link
with regard to packet forwarding. So, before discussing GRE tunnels, we’re first going to review
some familiar facts about routers and serial links, using the following figure as an example.
when PC1 sends a packet to destination IP address 10.1.2.2, R1 will encapsulate the packet in the data link protocol. The default encapsulation method for serial link is called High-Level Data Link Control (HDLC) which is shown in the figure above.
GRE uses a concept that works just like the serial link in the last figure, at least with regard to IP routing. Instead of a serial link with serial interfaces, the routers use virtual interfaces called tunnel interfaces. The IP address of both end of the tunnel between the routers are in the same subnet. This subnet is part of a secure enterprise network.
The routers encapsulate the original packet inside a tunnel header, by replacing the serial link’s HDLC header. The routers also keep routes that list the tunnel interfaces. To make use of the GRE tunnel, the routers treat it like any other link with a point-to-point topology.
The routers use routing protocol to become neighbors to exchange routes over the tunnel. The routes learned over the tunnel list the tunnel interface as the outgoing interface, with the IP address of the neighboring router’s tunnel interface as the next-hop. The figure below shows the routes learned by each router listed at the bottom.
All these concepts show how the GRE tunnel acts like just a normal link but with the difference that it adds security on certain part of the internetwork. The last section of this article discusses about how GRE tunnels forward these packets over an unsecured network between the two routers.
GRE Tunnels over the Unsecured Network
GRE specifies the use of two headers to create the tunnel. It defines its own header, used to
manage the tunnel itself. It also defines the use of a complete 20-byte IP header, called the
delivery header. This header will use IP addresses from the unsecured network. As shown in the figure below, the delivery IP header contains R1’s 188.8.131.52 Internet IP address as the source and R2’s 184.108.40.206 Internet IP address as the destination..
While this packet passes through the Internet, the routers in the Internet use this outer GRE delivery IP header to route the packet. The fact that this packet happens to hold another entire IP packet in itself, does not matter to the IP forwarding process between those routers. They just forward the IP packet based on the 220.127.116.11 destination IP address.
When the GRE packet finally arrives on the right side of the Internet, R2 needs to extract the original IP packet. With physical links, R2 would simply remove the old incoming data link header. With a GRE-encapsulated packet, the receiving router (R2) also needs to remove the delivery header and the GRE header, leaving the original packet.