---
title: VPN Configuration
tags: Cisco IOS, networking, manual, reference, router, switch, technical, security, vpn
---

<header>
<h6>VPN Configuration</h6>

> [toc]
</header>
---

# Overview

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

:::info
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)**, which does not include encryption services, is used to encapsulate IPv4 and IPv6 traffic inside an IP tunnel to create a **virtual point-to-point link**.
:::

# VPN Topologies

VPNs are commonly deployed in one of the following configurations:

## Site-to-Site

A site-to-site VPN is created when VPN terminating devices, also 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.

## Remote-Access

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.

There are two ways to that an end-user may dynamically intiate a Remote-Access VPN:

### Clientless 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 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.

# VPN Security

The type of VPN method implemented is based on the access requirements of the users and the organization’s IT processes. If support and ease of deployment are the primary issues, consider **SSL**-based VPNs. When security is an issue, **IPsec** is the superior choice.

It is important to understand that IPsec VPNs 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.

## SSL

SSL connections use the public key infrastructure and digital certificates to authenticate peers.

:::success
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.
:::

## Site-to-Site IPsec

Site-to-site VPNs are used to connect networks **across untrusted networks** 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, typically called a **VPN gateway**.

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).

# The IPsec Framework

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**.

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. In the diagram below, the currently available technologies are aligned to their specific security functions. The open slots shown in the framework can be filled with any of the choices that are available for that IPsec function, to create a unique **security association (SA)**.

An SA is the 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.


---

## IPsec Protocol Encapsulations

Choosing the 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 establishes which other building blocks are available.


:::info
In IPv4, AH and ESP are IP protocol headers. IPv6 uses the extension headers with a next-header value of 50 for ESP and 51 for AH.
:::

### Authentication Header (AH)

AH uses **IP protocol 51** and is appropriate only where confidentiality is not required. AH provides data authentication and integrity, but does not provide data confidentiality. The AH encapsulation function is applied to the entire packet, except for any IP header fields that normally change in transit.

AH confirms message integrity by applying a keyed one-way hash function to the packet to create a **message digest**. The message hash is combined with the text and is **transmitted in plaintext**. The receiver then confirms message integrity by recalculating the same one-way hash function on the received packets (minus the attached message digest), and comparing the attached and calculated hashes.

With AH **authenticity is assured**, because the one-way hash also employs a shared secret key between the two systems.

**AH supports MD5 and SHA algorithms. AH may not work if the environment uses NAT.**

### Encapsulation Security Protocol (ESP)

ESP uses **IP protocol 50** and provides both **Confidentiality**, by performing encryption on the IP packet, and **Authentication**, for the inner IP packet and ESP header. Authentication provides non-repudiation and data integrity verification. Although encryption and authentication are each optional in ESP, at least one of them must be selected.

When both authentication and encryption are selected, **encryption is performed first**. One reason for this order of processing is that it **facilitates rapid detection and rejection** of replayed or bogus packets by the receiving device. Prior to decrypting the packet, the receiver can **authenticate inbound packets**. By doing this, it can quickly detect problems and potentially reduce the impact of DoS attacks.

Optionally, ESP can also enforce **anti-replay protection**. Anti-replay protection verifies that **each packet is unique** and not duplicated, by keeping track of packet sequence numbers and using a sliding window on the destination end. This protection ensures that a hacker cannot insert modified packets into the data stream. Anti-replay protection is not supported in AH.

### Transport Mode vs Tunnel Mode

ESP and AH can each be applied to IP packets in **transport mode** or in **tunnel mode**.

#### Transport Mode

In transport mode, security is provided only for the **transport layer and above**, of the OSI model. Transport mode encrypts the payload of the packet but leaves the **original IP address** in plaintext, which is then used to route the packet through the internet.

AH transport mode provides authentication and integrity for the entire packet. It does not encrypt the data, but it is protected from modification.

ESP transport mode is used **between hosts**.

#### Tunnel Mode

In tunnel mode, security is provided for the **complete IP packet**. The original IP packet is encrypted, then is encapsulated in **another IP packet**. This is known as **IP-in-IP encryption**. The **outer IP address** is used to route the packet through the internet.

AH tunnel mode encapsulates the IP packet with an Authentication Header and a new IP header, and signs the entire packet for integrity and authentication. It does not encrypt the data.

ESP tunnel mode is used between a **host and a security gateway**, or between **two security gateways**.

:::info
For host-to-gateway applications, if the home router does not support ESP Tunnel Mode, an IPsec client running on the PC performs the IPsec IP-in-IP encapsulation and encryption.

For gateway-to-gateway applications, it is easier to have the security gateways perform the IP-in-IP encryption and encapsulation.
:::

---

## Packet Encryption

The encryption algorithm chosen for the IPsec framework determines the **resilience** and **confidentiality** of the connection.


:::info
The encryption algorithms highlighted in the figure are all symmetric key cryptosystems.
:::

---

## Data Integrity Verification

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. The **Hashed Message Authentication Code (HMAC)** guarantees the integrity of the message using an algorithmically derived **signature-hash**.

The figure highlights the two most common HMAC algorithms.


:::success
SHA-1 is considered a legacy algorithm. SHA-256 or above is recommended for current data integrity needs.
:::

---

## Access Authentication Mode

Devices on either end of a VPN tunnel must be authenticated before the communication path is considered secure.

The figure highlights the two peer authentication methods.


* **pre-shared secret key (PSK)** uses authentication codes entered into each peer manually. PSKs are easy to configure, but do not scale well, because each IPsec peer must be configured with the PSK of every other peer with which it wishes to communicate.
* **Rivest, Shamir, and Adleman (RSA)** uses digital certificates (public/private key pairs) to authenticate peers. Each gateway must authenticate its opposite before their tunnel is considered secure.

---

## Key Exchange

Symmetric encryption algorithms require a shared secret key to perform encryption and decryption. The easiest key exchange method is to use a public key exchange method, such as **Diffie-Hellman (DH)**.

DH provides a way for two peers to establish a shared secret key that only they know, even when 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 a key size 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 Elliptical Curve Cryptography (ECC), which reduces the time needed to generate keys.


:::warning
The DH group you choose must be strong enough to protect the IPsec keys during negotiation.
* If you choose **AES 128-bit key**, use **DH group 14, 19, 20 or 24**.
* If you choose **AES-256 or higher**, use the **DH group 21 or 24**.
:::

---

## IKE Protocol

The **Internet Key Exchange (IKE) protocol** is a key management protocol standard. IKE is used in conjunction with the IPsec standard, and enhances IPsec communcation by adding features and simplifying IPsec configuration.

IKE **automatically negotiates** IPsec security associations and enables IPsec secure communications between two remote peers.

Instead of transmitting keys directly across a network, IKE calculates **shared keys** based on the exchange of **a series of data packets**. This disables a third party from decrypting the keys even if the third party captured all of the exchanged data that was used to calculate the keys. IKE uses **UDP port 500** to exchange IKE information between the security gateways.

### Key Negotiation Phases

IKE uses the **Internet Security Association Key Management Protocol (<abbr title='pronounced "Ice-a-camp"'>ISAKMP</abbr>)** framework for phase 1 and phase 2 of key negotiation. Phase 1 negotiates a security association (a key) between two IKE peers. The key negotiated in phase 1 enables IKE peers to communicate securely in phase 2. During phase 2 negotiation, IKE establishes keys (security associations) for other applications, such as IPsec.

#### Phase 1 – Tunnel Initation

The basic purpose of Phase 1 is to negotiate ISAKMP policy, authenticate the peers, and set up a secure tunnel between the peers. This tunnel will then be used in Phase 2 to negotiate the IPsec policy.

Phase 1 can be implemented in **main mode** or **aggressive mode**. When main mode is used, the identities of the two IKE peers are **hidden**. Aggressive mode **takes less time** than main mode to negotiate keys between peers. However, since the authentication hash is sent **unencrypted** before the tunnel is established, **aggressive mode is vulnerable** to brute-force attacks.

#### Phase 2 – SA Negotiation

The purpose of IKE Phase 2 is to negotiate the IPsec security association (SA) that will be used to secure communcation across the IPsec tunnel. IKE Phase 2 is called **quick mode** and can only occur after IKE has established a secure tunnel in Phase 1.

Quick mode also renegotiates a new IPsec SA when the IPsec SA lifetime expires.

:::info
The SAs that IPsec uses are unidirectional; therefore, a separate key exchange is required for each data flow.
:::

**IKE version 2** is an enhancement of the IKE protocol. Version 2 supports NAT detection and NAT Traversal (NAT-T) during Phase 1 negotiation. If both VPN devices are NAT-T capable, and if they detect that they are connecting to each other through a NAT device, NAT-T is auto detected and auto negotiated. NAT-T encapsulates ESP packets inside UDP and assigns both the Source and Destination ports as 4500. Now ESP packets can traverse NAT.

# IPsec VPN Configuration (Site-to-Site)

Implementing a site-to-site VPN requires configuring settings for both IKE Phase 1 and Phase 2. In the phase 1 configuration, the two sites are configured with the necessary ISAKMP security associations to ensure that an ISAKMP tunnel can be created. In the phase 2 configuration, the two sites are configured with the IPsec security associations to ensure that an IPsec tunnel is created within the ISAKMP tunnel. Both tunnels will be created only when interesting traffic is detected.

The steps for IPsec VPN configuration are as follows:

## Step 1 – Confirm ACLs

Confirm that any existing ACLs do not block traffic necessary for IPsec negotiations. The ACL commands to permit ISAKMP, ESP, and AH traffic are shown here:

Router(config)# ip access-list extended {name}
Router(config-ext-nacl)# permit udp {source} {mask} {destination} {mask} eq isakmp
Router(config-ext-nacl)# permit esp {source} {mask} {destination} {mask}
Router(config-ext-nacl)# permit ahp {source} {mask} {destination} {mask}

## Step 2 – ISAKMP Policy

The next step is to configure the ISAKMP policy for **IKE Phase 1**. The ISAKMP policy **lists the SAs** that the router is willing to use to establish the **IKE Phase 1 tunnel**. The Cisco IOS comes with default ISAKMP policies already in place.

To view the default policies, enter the <code><b>show crypto isakmp default policy</b></code> command:

R1# show crypto isakmp default policy 
! 
! Default IKE policy
! Default protection suite of priority 65507
!     encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
!     hash algorithm:         Secure Hash Standard
!     authentication method:  Rivest-Shamir-Adleman Signature
!     Diffie-Hellman group:   #5 (1536 bit)
!     lifetime:               86400 seconds, no volume limit
!
!  <...output truncated...>
! 
R1# 

### Configure the ISAKMP Policy

To configure an **ISAKMP policy**, use the <code><b>crypto isakmp policy</b> <i>priority</i></code> global configuration command. This will enter the **ISAKMP policy sub-configuration** mode.

:::success
Peers will attempt to negotiate using the policy with the **lowest number** (highest priority). Peers do not require matching priority numbers.
:::

When in ISAKMP policy sub-configuration mode, the SAs for the IKE Phase 1 tunnel can be configured.

R1(config)# crypto isakmp policy 1
R1(config-isakmp)# encryption aes 256
R1(config-isakmp)# hash sha
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 24
R1(config-isakmp)# lifetime 3600
R1(config-isakmp)# end
R1# 
R1# show crypto isakmp policy 
! 
! Global IKE policy
! Protection suite of priority 1
!      encryption algorithm:   AES - Advanced Encryption Standard (256 bit keys).
!      hash algorithm:         Secure Hash Standard
!      authentication method:  Pre-Shared Key
!      Diffie-Hellman group:   #24 (2048 bit, 256 bit subgroup)
!      lifetime:               3600 seconds, no volume limit
! 
R1#

**There are five ISAKMP policy values that can be configured:**
1. **Hash** — hash algorithm used to sign the ISAKMP-tunnel traffic.
1. **Authentication** — authentication method for the ISAKMP tunnel.
1. **Group** — Diffie-Hellman group to be used for ISAKMP key exchange.
1. **Lifetime** — lifespan of this ISAKMP security association.
1. **Encryption** — encryption algorithm used to encode the ISAKMP-tunnel traffic.

### Define Interesting Traffic

Although the ISAKMP policy for the IKE Phase 1 tunnel is configured, the tunnel does not yet exist. **Interesting traffic** must be detected before IKE Phase 1 negotiations can begin. Interesting traffic consists of any **permitted communications** between site-to-site peers.

To define **interesting traffic**, configure each peer with an ACL to **permit acceptable traffic** from the local LAN to the remote LAN. The ACL will be used in the **crypto map** configuration to specify what traffic will **trigger** the start of **IKE Phase 1**.

### Configure Pre-Shared Key (optional)

Some ISAKMP policy implementations may require that a **pre-shared key** be used for authentication between site-to-site peers. In this case, the administrator can manually configure a **key association** for a given peer:

Router(config)# crypto isakmp key <keystring> address <peer-address>
Router(config)# crypto isakmp key <keystring> hostname <peer-hostname>

## Step 3 – Configure IPsec Policy

The third step is to configure the set of encryption and hashing algorithms that will be used to transform the data sent through the IPsec tunnel. This is called the **transform set**. During IKE Phase 2 negotiations, the peers agree on the IPsec transform set to be used for protecting interesting traffic.

Configure a transform set using the <code><b>crypto ipsec transform-set</b></code> command. After the transform set is named, the encryption (cipher) and hashing (auth) algorithm can be configured:

R1(config)# crypto ipsec transform-set <name> <cipher> <auth> 
R1(config)#

## Step 4 – Configure Crypto Maps

Once interesting traffic is defined, and an IPsec transform set is configured, it is time to bind those configurations with the rest of the IPsec policy in a crypto map.

The following command will enter the **crypto map sub-configuration** mode:

Router(config)# crypto map <name> <num> { ipsec-isakmp | ipsec-manual }

:::warning
The sequence number is important when configuring multiple crypto map entries.
:::

Use the <code><b>crypto map</b> <i>name seq-num</i></code> command without any keyword to modify the existing crypto map entry or profile.

### Create the Crypto Map

To define a crypto configuration, complete the following tasks:

<ol class='step-list' style="--step-separator: '. '">
<li>Bind the ACL to the map: <code><b>match address</b> <i>ACL-identifier</i></code></li>
<li>Bind the transform set: <code><b>set transform-set</b> <i>transform-name</i></code></li>
<li>Specify the VPN peer’s IP address: <code><b>set peer</b> <i>address</i></code></li>
<li>Configure the DH group: <code><b>set pfs</b> group{<i>#</i>}</code></li>
<li>Configure the IPsec security-association lifetime: <code><b>set security-association lifetime seconds</b> <i>lifespan</i></code></li>
</ol>

R1(config)# crypto map R1-R2_MAP 10 ipsec-isakmp
R1(config-crypto-map)# match address 101 
R1(config-crypto-map)# set transform-set R1-R2
R1(config-crypto-map)# set peer 172.30.2.2
R1(config-crypto-map)# set pfs group24
R1(config-crypto-map)# set security-association lifetime seconds 900 
R1(config-crypto-map)# exit
R1(config)#

### Apply the Crypto Map

To apply the crypto map, enter interface configuration mode for the outbound interface and configure the <code><b>crypto map</b> <i>map-name</i></code> command.

R1(config)# interface serial0/0/0
R1(config-if)# crypto map R1-R2_MAP
R1(config-if)#
! *Mar 19 19:36:36.273: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R1(config-if)# 

### Verify the Map

Use the <code><b>show crypto map</b></code> command to verify the crypto map configuration

R1# show crypto map
! Crypto Map IPv4 "R1-R2_MAP" 10 ipsec-isakmp
!     Peer = 172.30.2.2
!     Extended IP access list 101
!         access-list 101 permit ip 10.0.1.0 0.0.0.255 192.168.1.0 0.0.0.255
!     Security association lifetime: 4608000 kilobytes/900 seconds
!     DH group:  group24
!     Mixed-mode : Disabled
!     Transform sets={ 
!             R1-R2:  { esp-aes esp-sha-hmac  } , 
!     }
!     Interfaces using crypto map R1-R2_MAP:
!             Serial0/0/0
!
R1#

## Step 5 – Verify IPsec Tunnel

Once both the ISAKMP and IPsec policies are configured, and the crypto map is applied to the appropriate outbound interfaces, test the IKE Phase 1 and Phase 2 tunnels by sending interesting traffic across the link.

R1# ping 192.168.1.1 source 10.0.1.1
!  Type escape sequence to abort. 
!  Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout !  is 2 seconds: 
!  Packet sent with a source address of 10.0.1.1  
!  .!!!! 
!  Success rate is 80 percent (4/5), round-trip !  min/avg/max = 1/2/4 ms 
R1#

Sending interesting traffic **does not guarantee** that the tunnels are established. To **fully verify** that the tunnels have been established, use the <code><b>show crypto isakmp sa</b></code> and <code><b>show crypto ipsec sa</b></code> commands.

R1# show crypto isakmp sa 
! IPv4 Crypto ISAKMP SA
! dst          src           state      conn-id status
! 172.30.2.2   172.30.2.1    QM_IDLE       1005 ACTIVE
! 
! IPv6 Crypto ISAKMP SA 
! 
R1#
R1# show crypto ipsec sa
! 
! interface: Serial0/0/0
!     Crypto map tag: R1-R2_MAP, local addr 172.30.2.1
!
! <...output truncated...>
! 
!    current_peer 172.30.2.2 port 500
!      PERMIT, flags={origin_is_acl,}
!     #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
!     #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
!     #pkts compressed: 0, #pkts decompressed: 0
!     #pkts not compressed: 0, #pkts compr. failed: 0
!     #pkts not decompressed: 0, #pkts decompress failed: 0
!     #send errors 0, #recv errors 0
! 
! <...output truncated...>
R1# 

# Handling Broadcast and Multicast Traffic

IPsec only supports unicast traffic. To enable **broadcast** or **multicast** traffic, such as routing protocol packets, the peers in a site-to-site IPsec VPN implementation need to be configured with a **Generic Routing Encapsulation (GRE)** tunnel for the multicast traffic.

GRE supports multiprotocol tunneling. It can encapsulate multiple OSI Layer 3 protocol packet types inside an IP tunnel. Adding an additional GRE header between the payload and the tunneling IP header provides the multiprotocol functionality. GRE also supports IP multicast tunneling. Routing protocols that are used across the tunnel enable dynamic exchange of routing information in the virtual network. GRE does not provide encryption.

---
---

{%hackmd 7PGmjAHeTXak2VUM3iw5Wg %}