Virtual Private Networks (8.1.1)

To secure network traffic between sites and users, organizations use virtual private networks (VPNs) to create end-to-end private network connections. A VPN is virtual in that it carries information within a private network, but that information is actually transported over a public network. A VPN is private in that the traffic is encrypted to keep the data confidential while it is transported across the public network.

Figure 8-1 shows a collection of various types of VPNs managed by an enterprise’s main site. The tunnel enables remote sites and users to access the main site’s network resources securely.

In the figure, the following terms are used:

• A Cisco Adaptive Security Appliance (ASA) firewall helps organizations provide secure, high-performance connectivity, including through VPNs and always-on access for remote branches and mobile users.

• With a SOHO—which stands for small office and home office—a VPN-enabled router can provide VPN connectivity back to the corporate main site.

• Cisco AnyConnect Secure Mobility Client is software that remote workers can use to establish client-based VPN connections with the main site.

The first types of VPNs were strictly IP tunnels that did not include authentication or encryption of the data. For example, Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco that does not include encryption services. It is used to encapsulate IPv4 and IPv6 traffic inside an IP tunnel to create a virtual point-to-point link.

VPN Benefits (8.1.2)

Modern VPNs support encryption features such as Internet Protocol Security (IPsec) and Secure Sockets Layer (SSL) to secure network traffic between sites.

Table 8-1 lists the major benefits of VPNs.

Site-to-Site and Remote-Access VPNs (8.1.3)

VPNs are commonly deployed in one of the following configurations: site-to-site or remote-access VPNs.

Site-to-Site VPN

A site-to-site VPN is created when VPN terminating devices, called VPN gateways, are preconfigured with information to establish a secure tunnel. VPN traffic is only encrypted between these devices. Internal hosts have no knowledge that a VPN is being used.

Figure 8-2 shows a site-to-site VPN connection. The client laptop is connected to the network VPN gateway—in this case, a router. The VPN gateway is connected across the Internet, depicted as a cloud, to another VPN gateway (such as an ASA firewall).

Remote-Access VPN

A remote-access VPN is dynamically created to establish a secure connection between a client and a VPN terminating device. For example, a remote-access SSL VPN is used when you check your banking information online.

Figure 8-3 shows a remote-access VPN connection. The client’s laptop is connected through the internet, depicted as a cloud, to a VPN gateway (such as an ASA firewall).

Enterprise and Service Provider VPNs (8.1.4)

There are many options available for securing enterprise traffic. These solutions vary depending on who is managing the VPN. VPNs can be managed and deployed as

• Enterprise VPNs: Enterprise-managed VPNs are a common solution for securing enterprise traffic across the internet. Site-to-site and remote-access VPNs are created and managed by an enterprise using both IPsec and SSL VPNs.

• Service provider VPNs: Service provider–managed VPNs are created and managed over the provider network. The provider uses Multiprotocol Label Switching (MPLS) at Layer 2 or Layer 3 to create secure channels between an enterprise’s sites. MPLS is a routing technology the provider uses to create virtual paths between sites and effectively segregate the traffic from other customer traffic. Other legacy solutions include Frame Relay and Asynchronous Transfer Mode (ATM) VPNs.

Figure 8-4 lists the different types of enterprise-managed and service provider- managed VPN deployments that are discussed in more detail in this chapter.

Remote-Access VPNs (8.2.1)

VPNs have become the logical solution for remote-access connectivity for many reasons. 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 needed. These users can therefore contribute to business productivity without compromising network security.

A remote-access VPN is typically enabled dynamically by the user when required. Remote-access VPNs can be created using either IPsec or SSL. As shown in Figure 8-5, a remote user must initiate a remote-access VPN connection.

The figure shows two ways that a remote user can initiate a remote-access VPN connection:

• 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. 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. A user must initiate a VPN connection by 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.

SSL VPNs (8.2.2)

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 depends on the access requirements of the users and the organization’s IT processes. Table 8-2 compares IPsec and SSL remote-access deployments.

It is important to understand that IPsec and SSL VPNs are not mutually exclusive. Instead, they are complementary; the two 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 (8.2.3)

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 device is typically called a VPN gateway. A VPN gateway device could be a router or a firewall, as shown in Figure 8-6.

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 in one software image.

The VPN gateway encapsulates and encrypts all outbound traffic from a particular site. 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 (8.2.4)

Generic Routing Encapsulation (GRE) is a nonsecure 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; 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 do not exchange routing information over an IPsec VPN. To solve this problem, you 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 shown in Figure 8-7:

• Passenger protocol: This is the original packet that is to be encapsulated by GRE. It could be an IPv4 or IPv6 packet or a routing update.

• 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. It could be IPv4 or IPv6.

For example, in the topology shown in Figure 8-8, 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 (the passenger protocol) packets would be encapsulated by GRE (the carrier protocol) and subsequently encapsulated in an IPsec VPN tunnel.

The Wireshark screen capture in Figure 8-9 shows an OSPF Hello packet that was sent using GRE over IPsec. In this example, the original OSPF Hello multicast packet (the passenger protocol) is encapsulated with a GRE header (the carrier protocol), which is subsequently encapsulated by another IP header (the transport protocol). This IP header can then be forwarded over an IPsec tunnel.

Dynamic Multipoint VPNs (8.2.5)

Site-to-site IPsec VPNs and GRE over IPsec are adequate 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 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 Figure 8-10.

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 Figure 8-11.

IPsec Virtual Tunnel Interface (8.2.6)

Like DMVPN, IPsec virtual tunnel interfaces (IPsec VTIs) simplify the configuration process required to support multiple sites and remote access. IPsec VTI configurations are applied to a virtual interface instead of statically mapping the IPsec sessions to a physical interface.

An IPsec VTI is capable of sending and receiving both IP unicast and multicast encrypted traffic. Therefore, routing protocols are automatically supported without configuration of GRE tunnels, as shown in Figure 8-12.

An IPsec VTI can be configured between sites or in a hub-and-spoke topology.

Service Provider MPLS VPNs (8.2.7)

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 networks. Traffic is forwarded through the MPLS backbone using labels that previously distributed among the core routers. As with 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. Two types of MPLS VPN solutions are 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 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 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.

Figure 8-13 shows a service provider that offers both Layer 2 and Layer 3 MPLS VPNs.

IPsec Technologies (8.3.2)

IPsec is an IETF standard (RFC 2401–2412) that defines how a VPN can be secured across IP networks. IPsec protects and authenticates IP packets between source and destination. IPsec can protect traffic from Layer 4 through Layer 7.

Using the IPsec framework, IPsec provides these essential security functions:

• Confidentiality: IPsec uses encryption algorithms to prevent cybercriminals from reading the packet contents.

• Integrity: IPsec uses hashing algorithms to ensure that packets have not been altered between the source and the destination.

• Origin authentication: IPsec uses the Internet Key Exchange (IKE) protocol to authenticate the source and the destination. Methods of authentication include using pre-shared keys (PSKs), digital certificates, or RSA certificates.

• Diffie-Hellman: Secure key exchange using the DH algorithm.

IPsec is not bound to any specific rules for secure communications. This flexibility of the framework allows IPsec to easily integrate new security technologies without updating the existing IPsec standards. The currently available technologies are aligned to their specific security function. The open slots shown in the IPsec framework in Figure 8-14 can be filled with any of the choices that are available for that IPsec function (see Table 8-3) to create a unique security association (SA).

Figure 8-15 shows examples of SAs for two different implementations.

An SA is a basic building block of IPsec. When establishing a VPN link, the peers must share the same SA to negotiate key exchange parameters, establish a shared key, authenticate each other, and negotiate the encryption parameters. Notice that SA Example 1 in Figure 8-15 is using no encryption.

IPsec Protocol Encapsulation (8.3.3)

IPsec protocol encapsulation is the first building block of the framework. IPsec encapsulates packets using Authentication Header (AH) or Encapsulation Security Protocol (ESP). The choice of AH or ESP in Figure 8-16 establishes which other building blocks are available.

Confidentiality (8.3.4)

Confidentiality is achieved by encrypting the data, as shown in Figure 8-17.

The degree of confidentiality depends on the encryption algorithm and the length of the key used in the encryption algorithm. If someone tries to hack the key through a brute-force attack, the number of possibilities to try depends on the length of the key. The time to process all the possibilities is a function of the computer power of the attacking device. The shorter the key, the easier it is to break. A 64-bit key can take approximately a year to break with a relatively sophisticated computer. A 128-bit key with the same machine can take roughly 10¹⁹, or 10 quintillion, years to decrypt.

The encryption algorithms highlighted in Figure 8-18 are all symmetric key cryptosystems:

• DES uses a 56-bit key.

• 3DES is a variant of 56-bit DES that uses three independent 56-bit encryption keys per 64-bit block, which provides significantly stronger encryption strength compared to DES.

• AES provides stronger security than DES and is computationally more efficient than 3DES. AES offers three different key lengths: 128 bits, 192 bits, and 256 bits.

• SEAL is a stream cipher, which means it encrypts data continuously rather than encrypting blocks of data. SEAL uses a 160-bit key.

Integrity (8.3.5)

Data integrity means that the data that is received is exactly the same data that was sent. Data could potentially be intercepted and modified. For example, say that, as shown in Figure 8-19, a check for $100 is written to Alex.

The check is then mailed to Alex, but it is intercepted by a threat actor. The threat actor changes the name on the check to Jeremy and the amount on the check to $1,000 and attempts to cash it. Depending on the quality of the forgery in the altered check, the attacker could be successful.

Because VPN data is transported over the public internet, a method of proving data integrity is required to guarantee that the content has not been altered. A hash message authentication code (HMAC) is a data integrity algorithm that guarantees the integrity of the message by using a hash value. Figure 8-20 highlights the two most common HMAC algorithms:

• Message-Digest 5 (MD5) uses a 128-bit shared-secret key. The variable-length message and 128-bit shared secret key are combined and run through the HMAC-MD5 hashing algorithm. The output is a 128-bit hash.

• Secure Hash Algorithm (SHA) uses a 160-bit secret key. The variable-length message and the 160-bit shared secret key are combined and run through the HMAC-SHA-1 algorithm. The output is a 160-bit hash.

Authentication (8.3.6)

When conducting business long distance, you must know who is at the other end of the phone, email, or fax. Similarly, with a VPN network, the device on the other end of the VPN tunnel must be authenticated before the communication path can be considered secure. Figure 8-21 highlights the two peer authentication methods:

• A pre-shared key (PSK) value can be entered into each peer manually. The PSK is combined with other information to form the authentication key. PSKs are easy to configure manually but do not scale well because each IPsec peer must be configured with the PSK of every other peer with which it communicates.

• Rivest, Shamir, and Adleman (RSA) authentication uses digital certificates to authenticate the peers. The local device derives a hash and encrypts it with its private key. The encrypted hash is attached to the message and is forwarded to the remote end and acts like a signature. At the remote end, the encrypted hash is decrypted using the public key of the local end. If the decrypted hash matches the recomputed hash, the signature is genuine. Each peer must authenticate its opposite peer before the tunnel is considered secure.

Figure 8-22 shows an example of PSK authentication.

At the local device, the authentication key and the identity information are sent through a hashing algorithm to form the hash for the local peer (Hash_L). One-way authentication is established by sending Hash_L to the remote device. If the remote device can independently create the same hash, the local device is authenticated. After the remote device authenticates the local device, the authentication process begins in the opposite direction, and all steps are repeated from the remote device to the local device.

Figure 8-23 shows an example of RSA authentication.

At the local device, the authentication key and identity information are sent through the hashing algorithm to form the hash for the local peer (Hash_L). Then Hash_L is encrypted using the local device’s private encryption key. This creates a digital signature. The digital signature and a digital certificate are forwarded to the remote device. The public encryption key for decrypting the signature is included in the digital certificate. The remote device verifies the digital signature by decrypting it using the public encryption key. The result is Hash_L. Next, the remote device independently creates Hash_L from stored information. If the calculated Hash_L equals the decrypted Hash_L, the local device is authenticated. After the remote device authenticates the local device, the authentication process begins in the opposite direction, and all steps are repeated from the remote device to the local device.

Secure Key Exchange with Diffie-Hellman (8.3.7)

Encryption algorithms require a symmetric, shared secret key to perform encryption and decryption. How do the encrypting and decrypting devices get the shared secret key? The easiest key exchange method is to use a public key exchange method, such as Diffie-Hellman (DH), as shown in Figure 8-24.

DH provides a way for two peers to establish a shared secret key that only they know, even though they are communicating over an insecure channel. Variations of the DH key exchange are specified as DH groups:

• DH groups 1, 2, and 5 should no longer be used. These groups support key sizes of 768 bits, 1024 bits, and 1536 bits, respectively.

• DH groups 14, 15, and 16 use larger key sizes with 2048 bits, 3072 bits, and 4096 bits, respectively, and are recommended for use until 2030.

• DH groups 19, 20, 21, and 24, with respective key sizes of 256 bits, 384 bits, 521 bits, and 2048 bits, support elliptic curve cryptography (ECC), which reduces the time needed to generate keys. DH group 24 is the preferred next-generation encryption.

The DH group you choose must be strong enough, or have enough bits, to protect the IPsec keys during negotiation. For example, DH group 1 is strong enough to support DES and 3DES encryption, but not AES. For example, if the encryption or authentication algorithms use a 128-bit key, use group 14, 19, 20, or 24. However, if the encryption or authentication algorithms use a 256-bit key or higher, use group 21 or 24.

VPN Technology

A VPN is virtual in that it carries information within a private network, but that information is actually transported over a public network. A VPN is private in that the traffic is encrypted to keep the data confidential while it is transported across the public network. Benefits of VPNs are cost savings, security, scalability, and compatibility.

Types of VPNs

VPNs are commonly deployed in one of the following configurations: site-to-site or remote-access VPNs. VPNs can be managed and deployed as enterprise VPNs and service provider VPNs.

Remote-access VPNs let remote and mobile users securely connect to the enterprise by creating an encrypted tunnel. Remote-access VPNs can be created using either IPsec or SSL. When a client negotiates an SSL VPN connection with the VPN gateway, it actually connects using TLS. SSL uses public key infrastructure and digital certificates to authenticate peers. Site-to-site VPNs are used to connect networks across an 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 device is typically called a VPN gateway. A VPN gateway could be a router or a firewall. GRE is a nonsecure site-to-site VPN tunneling protocol. DMVPN is a Cisco software solution for easily building multiple dynamic scalable VPNs. Like DMVPN, IPsec VTIs simplify the configuration process required to support multiple sites and remote access. IPsec VTI configurations are applied to a virtual interface instead of statically mapping the IPsec sessions to a physical interface. A IPsec VTI can send and receive both IP unicast and multicast encrypted traffic. MPLS can provide clients with managed VPN solutions; therefore, securing traffic between client sites is the responsibility of the service provider. Two types of MPLS VPN solutions are supported by service providers: Layer 3 MPLS VPNs and Layer 2 MPLS VPNs.

IPsec

IPsec protects and authenticates IP packets between the source and the destination. IPsec can protect traffic from Layer 4 through Layer 7. Using the IPsec framework, IPsec provides confidentiality, integrity, origin authentication, and Diffie-Hellman. The IPsec protocol encapsulation is the first building block of the framework. IPsec encapsulates packets using AH or ESP. The degree of confidentiality depends on the encryption algorithm and the length of the key used in the encryption algorithm. An HMAC is an algorithm that guarantees the integrity of a message by using a hash value. The device on the other end of the VPN tunnel must be authenticated before the communication path is considered secure. A PSK value is entered into each peer manually. The PSK is combined with other information to form the authentication key. RSA authentication uses digital certificates to authenticate the peers. The local device derives a hash and encrypts it with its private key. The encrypted hash is attached to the message and is forwarded to the remote end and acts like a signature. DH provides a way for two peers to establish a shared secret key that only they know, even though they are communicating over an insecure channel.