This topic describe different types of VPNs. Start learning CCNA 200-301 for free right now!!
Note: Welcome: This topic is part of Module 8 of the Cisco CCNA 3 course, for a better follow up of the course you can go to the CCNA 3 section to guide you through an order.
Table of Contents
In the previous topic you learned about the basics of a VPN. Here you will learn about the types of VPNs.
VPNs have become the logical solution for remote-access connectivity for many reasons. As shown in the figure, remote-access VPNs let remote and mobile users securely connect to the enterprise by creating an encrypted tunnel. Remote users can securely replicate their enterprise security access including email and network applications. Remote-access VPNs also allow contractors and partners to have limited access to the specific servers, web pages, or files as required. This means that these users can contribute to business productivity without compromising network security.
Remote-access VPNs are typically enabled dynamically by the user when required. Remote access VPNs can be created using either IPsec or SSL. As shown in the figure, a remote user must initiate a remote access VPN connection.
The figure displays two ways that a remote user can initiate a remote access VPN connection: clientless VPN and client-based VPN.
Clientless VPN connection -The connection is secured using a web browser SSL connection. SSL is mostly used to protect HTTP traffic (HTTPS), and email protocols such as IMAP and POP3. For example, HTTPS is actually HTTP using an SSL tunnel. The SSL connection is first established, and then HTTP data is exchanged over the connection.
Client-based VPN connection – VPN client software such as Cisco AnyConnect Secure Mobility Client must be installed on the remote user’s end device. Users must initiate the VPN connection using the VPN client and then authenticate to the destination VPN gateway. When remote users are authenticated, they have access to corporate files and applications. The VPN client software encrypts the traffic using IPsec or SSL and forwards it over the internet to the destination VPN gateway.
When a client negotiates an SSL VPN connection with the VPN gateway, it actually connects using Transport Layer Security (TLS). TLS is the newer version of SSL and is sometimes expressed as SSL/TLS. However, both terms are often used interchangeably.
SSL uses the public key infrastructure and digital certificates to authenticate peers. Both IPsec and SSL VPN technologies offer access to virtually any network application or resource. However, when security is an issue, IPsec is the superior choice. If support and ease of deployment are the primary issues, consider SSL. The type of VPN method implemented is based on the access requirements of the users and the organization’s IT processes. The table compares IPsec and SSL remote access deployments.
Extensive – All IP-based applications are supported.
Limited – Only web-based applications and file sharing are supported.
Strong – Uses two-way authentication with shared keys or digital certificates.
Moderate – Using one-way or two-way authentication.
Strong – Uses key lengths from 56 bits to 256 bits.
Moderate to strong – With key lengths from 40 bits to 256 bits.
Medium – Because it requires a VPN client pre-installed on a host.
Low – It only requires a web browser on a host.
Limited – Only specific devices with specific configurations can connect.
Extensive – Any device with a web browser can connect.
It is important to understand that IPsec and SSL VPNs are not mutually exclusive. Instead, they are complementary; both technologies solve different problems, and an organization may implement IPsec, SSL, or both, depending on the needs of its telecommuters.
Site-to-Site IPsec VPNs
Site-to-site VPNs are used to connect networks across another untrusted network such as the internet. In a site-to-site VPN, end hosts send and receive normal unencrypted TCP/IP traffic through a VPN terminating device. The VPN terminating is typically called a VPN gateway. A VPN gateway device could be a router or a firewall, as shown in the figure. For example, the Cisco Adaptive Security Appliance (ASA) shown on the right side of the figure is a standalone firewall device that combines firewall, VPN concentrator, and intrusion prevention functionality into one software image.
The VPN gateway encapsulates and encrypts outbound traffic. It then sends the traffic through a VPN tunnel over the internet to a VPN gateway at the target site. Upon receipt, the receiving VPN gateway strips the headers, decrypts the content, and relays the packet toward the target host inside its private network.
Site-to-site VPNs are typically created and secured using IP security (IPsec).
GRE over IPsec
Generic Routing Encapsulation (GRE) is a non-secure site-to-site VPN tunneling protocol. It can encapsulate various network layer protocols. It also supports multicast and broadcast traffic which may be necessary if the organization requires routing protocols to operate over a VPN. However, GRE does not by default support encryption; and therefore, it does not provide a secure VPN tunnel.
A standard IPsec VPN (non-GRE) can only create secure tunnels for unicast traffic. Therefore, routing protocols will not exchange routing information over an IPsec VPN.
To solve this problem, we can encapsulate routing protocol traffic using a GRE packet, and then encapsulate the GRE packet into an IPsec packet to forward it securely to the destination VPN gateway.
The terms used to describe the encapsulation of GRE over IPsec tunnel are passenger protocol, carrier protocol, and transport protocol, as shown in the figure.
Passenger protocol – This is the original packet that is to be encapsulated by GRE. It could be an IPv4 or IPv6 packet, a routing update, and more.
Carrier protocol – GRE is the carrier protocol that encapsulates the original passenger packet.
Transport protocol – This is the protocol that will actually be used to forward the packet. This could be IPv4 or IPv6.
For example, in the figure displaying a topology, Branch and HQ would like to exchange OSPF routing information over an IPsec VPN. However, IPsec does not support multicast traffic. Therefore, GRE over IPsec is used to support the routing protocol traffic over the IPsec VPN. Specifically, the OSPF packets (i.e., passenger protocol) would be encapsulated by GRE (i.e., carrier protocol) and subsequently encapsulated in an IPsec VPN tunnel.
The Wireshark screen capture in the figure displays an OSPF Hello packet that was sent using GRE over IPsec. In the example, the original OSPF Hello multicast packet (i.e., passenger protocol) was encapsulated with a GRE header (i.e., carrier protocol), which is subsequently encapsulated by another IP header (i.e., transport protocol). This IP header would then be forwarded over an IPsec tunnel.
Dynamic Multipoint VPNs
Site-to-site IPsec VPNs and GRE over IPsec are adequate to use when there are only a few sites to securely interconnect. However, they are not sufficient when the enterprise adds many more sites. This is because each site would require static configurations to all other sites, or to a central site.
Dynamic Multipoint VPN (DMVPN) is a Cisco software solution for building multiple VPNs in an easy, dynamic, and scalable manner. Like other VPN types, DMVPN relies on IPsec to provide secure transport over public networks, such as the internet.
DMVPN simplifies the VPN tunnel configuration and provides a flexible option to connect a central site with branch sites. It uses a hub-and-spoke configuration to establish a full mesh topology. Spoke sites establish secure VPN tunnels with the hub site, as shown in the figure.
DMVPN Hub-to-Spoke Tunnels
Each site is configured using Multipoint Generic Routing Encapsulation (mGRE). The mGRE tunnel interface allows a single GRE interface to dynamically support multiple IPsec tunnels. Therefore, when a new site requires a secure connection, the same configuration on the hub site would support the tunnel. No additional configuration would be required.
Spoke sites could also obtain information about other spoke sites from the central site and create virtual spoke-to-spoke tunnels as shown in the figure.
DMVPN Hub-to-Spoke and Spoke-to-Spoke Tunnels
IPsec Virtual Tunnel Interface
Like DMVPNs, IPsec Virtual Tunnel Interface (VTI) simplifies the configuration process required to support multiple sites and remote access. IPsec VTI configurations are applied to a virtual interface instead of static mapping the IPsec sessions to a physical interface.
IPsec VTI is capable of sending and receiving both IP unicast and multicast encrypted traffic. Therefore, routing protocols are automatically supported without having to configure GRE tunnels.
IPsec VTI can be configured between sites or in a hub-and-spoke topology.
Service Provider MPLS VPNs
Traditional service provider WAN solutions such as leased lines, Frame Relay, and ATM connections were inherently secure in their design. Today, service providers use MPLS in their core network. Traffic is forwarded through the MPLS backbone using labels that are previously distributed among the core routers. Like legacy WAN connections, traffic is secure because service provider customers cannot see each other’s traffic.
MPLS can provide clients with managed VPN solutions; therefore, securing traffic between client sites is the responsibility of the service provider. There are two types of MPLS VPN solutions supported by service providers:
Layer 3 MPLS VPN – The service provider participates in customer routing by establishing a peering between the customer’s routers and the provider’s routers. Then customer routes that are received by the provider’s router are then redistributed through the MPLS network to the customer’s remote locations.
Layer 2 MPLS VPN – The service provider is not involved in the customer routing. Instead, the provider deploys a Virtual Private LAN Service (VPLS) to emulate an Ethernet multiaccess LAN segment over the MPLS network. No routing is involved. The customer’s routers effectively belong to the same multiaccess network.
The figure shows a service provider that offers both Layer 2 and Layer 3 MPLS VPNs.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.