IPSec VPN on Cisco ASA

Understanding IPSec VPN

IPSec VPNs play a crucial role in securing IP communications over untrusted networks such as the internet. When implemented on Cisco ASA (Adaptive Security Appliance), IPSec provides a robust and flexible method for encrypting data traffic, ensuring secure communication between peers.

Key Features of IPSec VPN

IPSec VPN on Cisco ASA offers multiple security features designed to protect the integrity, confidentiality, and authenticity of data as it travels across insecure channels:

Confidentiality: IPSec ensures that data remains confidential by encrypting it using symmetric encryption algorithms such as DES, 3DES, and AES. This prevents unauthorized users from reading the content even if they intercept the traffic.
Integrity: To ensure that data is not altered during transmission, IPSec uses hash algorithms like MD5 and SHA. This guarantees that the information received is exactly what was sent, without tampering.
Data Origin Authentication: IPSec authenticates both endpoints of the connection before any data is exchanged. This is typically done using either pre-shared keys or Public Key Infrastructure (PKI), ensuring both parties are legitimate.
Anti-Replay Protection: IPSec includes mechanisms to prevent replay attacks, where a malicious actor resends previously captured packets. If a packet arrives too late or outside the acceptable window, it will be dropped. This window can be defined in terms of kilobytes or seconds.

IPSec Protocol Suite

To deliver its security features, IPSec uses a collection of protocols, each serving a specific purpose:

IKE (Internet Key Exchange): IKE provides the framework for negotiating and establishing secure tunnels between two IPSec peers. It handles the exchange of cryptographic parameters and policy settings.
ESP (Encapsulating Security Payload): ESP is responsible for providing encryption and optional authentication for the data payload, protecting the confidentiality and integrity of transmitted information.
AH (Authentication Header): AH ensures data integrity and authentication but does not offer encryption. It is used in scenarios where verifying the identity and contents of the packets is sufficient without needing to hide them.

IKE Modes and Phases

A critical part of establishing an IPSec VPN tunnel is the Internet Key Exchange (IKE) process, which negotiates the parameters and keys used in securing traffic between peers. Cisco ASA supports various IKE modes and phases, each playing a unique role in establishing secure communication.

IKE Modes

IKE operates in different modes depending on how quickly or securely the tunnel needs to be established. The most common are Main Mode, Aggressive Mode, and Quick Mode:

Main Mode:
This mode uses six messages to establish the connection. It emphasizes security by negotiating each element of the security association in a protected and step-by-step manner:

The initiator sends a proposal to the responder.
The responder replies with its own proposal.
The initiator sends its Diffie-Hellman (DH) key.
The responder sends its DH key in return.
The initiator authenticates the session.
The responder finalizes the process by authenticating the session.

This mode ensures complete negotiation and identity protection.

Aggressive Mode:
In contrast, Aggressive Mode uses only three messages, prioritizing speed over confidentiality of identity:

The initiator sends its proposal and key together.
The responder authenticates the proposal and replies with its own.
The initiator authenticates the session.

While faster, this mode exposes some identity information early in the process. However, either Main Mode or Aggressive Mode can be used depending on the security and speed requirements.

Quick Mode:
After the initial tunnel is established, Quick Mode negotiates the parameters for the IPSec tunnel. It uses the Security Parameter Index (SPI) to recheck and confirm security settings. Each peer sends the SPI with every packet to identify the correct SA (Security Association) for decryption and validation.

IKE Phases

The IKE process is divided into distinct phases that incrementally establish and secure the communication channel.

Phase 1:
This phase creates a secure, bidirectional IKE tunnel. A single key is used to authenticate the session, and the phase may operate in either Main or Aggressive Mode, depending on the configuration and VPN type (e.g., site-to-site or remote access). The key goal is to authenticate both peers and protect subsequent negotiations.
Phase 1.5 (Optional):
Cisco ASA can also implement an optional step known as Phase 1.5, which introduces Extended Authentication (Xauth). This step prompts users for credentials (like username/password) before granting access. It’s particularly useful for remote access VPNs where user-level authentication is required in addition to device-level trust.
Phase 2:
Once Phase 1 is complete, Phase 2 begins. This stage establishes the actual IPSec tunnels that carry the encrypted data. Multiple tunnels may be created, and depending on the configuration, each protocol (ESP or AH) can have two tunnels. Phase 2 cannot proceed unless Phase 1 completes successfully.

These IKE modes and phases work in tandem to ensure that Cisco ASA can deliver both robust and flexible VPN solutions, whether for site-to-site connectivity or secure remote access. Understanding this process is essential for anyone deploying or troubleshooting IPSec VPNs on ASA firewalls.

IKE, IPSec Modes, and Security Association Components

To successfully implement IPSec VPNs on Cisco ASA, it’s essential to understand how Internet Key Exchange (IKE), ISAKMP, IPSec modes, and Security Associations (SAs) work together to secure traffic.

IKE Mode Selection Based on VPN Type

IKE operates in different modes depending on the VPN deployment scenario:

Site-to-Site VPNs typically use Main Mode for its thorough negotiation process.
Remote Access VPNs often rely on Aggressive Mode when using pre-configured VPN clients, prioritizing speed over identity protection.
DMVPN and GET VPN both leverage Main Mode due to their dynamic nature and reliance on scalable key exchange.

ISAKMP and Port Usage

IKE is not a standalone protocol, it is a management protocol that relies on ISAKMP (Internet Security Association and Key Management Protocol) for negotiating and establishing Security Associations. ISAKMP handles key exchanges, policy agreements, and peer authentication, using UDP port 500 by default.

IPSec Modes: Transport vs. Tunnel

Cisco ASA supports two primary IPSec operation modes, each with a distinct use case:

Transport Mode is used primarily in DMVPN environments. It encrypts the payload (Layer 4 and above), leaving the original IP header intact. This mode is efficient but less secure for public-facing networks.

Tunnel Mode is commonly used in site-to-site, remote access, and GET VPN configurations. It encrypts the entire IP packet (Layer 3 and above), encapsulating it within a new IP header, offering stronger protection across untrusted networks.

Understanding Security Associations (SAs)

A Security Association is a negotiated agreement between two IPSec peers. It includes all the cryptographic and policy parameters needed to establish and maintain a secure connection. These parameters are stored and maintained in two key data structures:

SAD (Security Association Database):
The SAD contains runtime information like:
- Peer IP addresses
- SPI (Security Parameter Index): A unique identifier generated using a hash of the Security Policy Database (SPD) contents
- IPSec protocol selection (e.g., ESP or AH)
SPD (Security Policy Database):
The SPD defines how traffic is protected. It contains:
- Encryption algorithms such as DES, 3DES, or AES
- Hashing algorithms like MD5 or SHA-1
- IPSec mode (Tunnel or Transport)
- Key lifetime, expressed in seconds or kilobytes

Together, the SAD and SPD guide the firewall in encrypting, decrypting, and verifying traffic passing through the VPN tunnel.

Diffie-Hellman Groups and Encryption

The Diffie-Hellman (DH) Group is an essential part of the key exchange process. It allows two peers to securely agree on a shared secret over an untrusted channel. The chosen DH group determines the cryptographic strength of the key.

Encryption is then applied to make the transmitted data unreadable to any unauthorized party. Only devices that possess the correct keys—agreed upon during the IKE phase—can decrypt and interpret the data.

Encryption Algorithm Types

Encryption is the backbone of secure communication in IPSec VPNs. Cisco ASA uses both symmetric and asymmetric encryption algorithms to ensure data confidentiality and secure key exchanges between peers.

Symmetric Encryption

Symmetric encryption relies on a single shared key that is used for both encryption and decryption of the data. This method is computationally efficient and well-suited for bulk data encryption within established IPSec tunnels. Common symmetric encryption algorithms used in Cisco ASA VPNs include:

DES (Data Encryption Standard):
Uses a 56-bit key. Though historically important, DES is now considered weak by modern standards and generally avoided in favor of stronger options.
3DES (Triple DES):
Applies DES three times using three different 56-bit keys—one for encryption, one for decryption, and another for a second encryption pass. While more secure than DES, it has been largely superseded by AES due to performance and security concerns.
AES (Advanced Encryption Standard):
The current industry standard for secure symmetric encryption. AES supports key lengths of 128, 192, or 256 bits, with 128-bit and 256-bit being the most commonly used. It provides a strong balance of speed, efficiency, and cryptographic strength.

Asymmetric Encryption

Unlike symmetric encryption, asymmetric encryption uses a pair of keys: one to encrypt and the other to decrypt. Typically, the sender encrypts data using the recipient’s public key, and the recipient decrypts it with their private key. This mechanism is used primarily during the initial key exchange process (such as during IKE Phase 1), rather than for encrypting large volumes of data.

Common forms of asymmetric encryption in Cisco ASA include:

Digital Certificates:
These are issued by trusted Certificate Authorities (CAs) and used to verify the identity of VPN peers during tunnel establishment. Certificates include the peer’s public key and are part of the PKI infrastructure.
RSA Signatures:
RSA provides a secure way to sign and verify data. During IKE authentication, RSA signatures ensure that the message originated from a trusted source and was not tampered with in transit.

Together, symmetric and asymmetric encryption provide layered security. Asymmetric encryption initiates the secure exchange of symmetric keys, which are then used to encrypt the actual traffic over the VPN tunnel.

PKI, AH, and ESP

Beyond encryption algorithms, a secure IPSec VPN relies on robust frameworks and protocols to establish trust and protect data in transit. Cisco ASA supports multiple mechanisms including PKI, Authentication Header (AH), and Encapsulating Security Payload (ESP) to fulfill this goal.

Public Key Infrastructure (PKI)

PKI provides a scalable framework for managing digital certificates and cryptographic keys, enabling secure communication over untrusted networks. It’s especially valuable for large deployments where managing pre-shared keys manually becomes impractical.

The PKI message exchange process on Cisco ASA typically follows these steps:

The host generates an RSA signature and requests the public key of a trusted Certificate Authority (CA).
The CA responds with its public key.
The host creates a certificate signing request (CSR) and submits it to the CA.
The CA signs the certificate request using its private key and sends back a digitally signed certificate.
The host saves this certificate locally.
The certificate is then used for secure authentication and encrypted communication with other peers.

This process ensures that the identity of each device can be verified using digital signatures, reducing the risk of impersonation.

Authentication Header (AH)

The Authentication Header is one of two core IPSec protocols, focused primarily on ensuring integrity and authenticity of IP packets:

AH provides data integrity, data origin authentication, and anti-replay protection.
It uses IP protocol number 51.
AH includes the external IP header when calculating the Integrity Check Value (ICV), which is used to detect packet tampering.
However, it does not include the Time-To-Live (TTL) value from the external IP header in the ICV.
A major limitation of AH is that it does not work with NAT, since NAT modifies the IP header, which breaks the integrity validation.

Because of its incompatibility with NAT, AH is less commonly used in modern VPN deployments where NAT traversal is required.

Encapsulating Security Payload (ESP)

ESP is the most widely used IPSec protocol, offering a more complete security solution:

ESP provides confidentiality, integrity, data origin authentication, and anti-replay protection.
It uses IP protocol number 50.
Unlike AH, ESP does not include the external IP header in the ICV calculation, making it compatible with NAT.
ESP supports NAT traversal (NAT-T), a key feature that encapsulates ESP packets in UDP to pass through NAT devices effectively.

Thanks to its support for encryption, compatibility with NAT, and broader feature set, ESP is the preferred choice for most IPSec VPN configurations on Cisco ASA.

NAT Traversal (NAT-T)

In many real-world deployments, VPN traffic must traverse NAT (Network Address Translation) devices. This introduces a challenge for IPSec, particularly with certain protocols like AH, which depend on static IP header information. Cisco ASA supports NAT Traversal (NAT-T) as a solution to maintain VPN connectivity even through NAT boundaries.

Why NAT-T is Necessary

NAT devices modify IP header fields such as source or destination IPs. This behavior interferes with IPSec protocols that rely on consistent header information for validation.

AH (Authentication Header) includes the external IP address in its Integrity Check Value (ICV). When a NAT device alters the IP address, it causes an ICV mismatch on the receiving peer, resulting in the AH packet being dropped. For this reason, AH is not compatible with NAT.
ESP (Encapsulating Security Payload) does not include the IP header in its ICV, which avoids that particular problem. However, ESP encrypts the Layer 4 (transport layer) information, such as port numbers, that NAT devices rely on to manage state. Without access to this info, NAT cannot function properly with native ESP traffic.

To solve this, NAT-T encapsulates ESP packets within a UDP header (using port 4500), making them NAT-friendly.

How NAT-T Works

NAT-T adds a UDP header between the outer IP header and the ESP header. This makes ESP packets appear as standard UDP packets to NAT devices, allowing proper translation and routing. This process is automatic and negotiated during IKE Phase 1.

NAT-T Process Breakdown

NAT-T Support Negotiation:
- During IKE Phase 1, both peers exchange vendor IDs and system information to identify whether they support NAT-T.
NAT Detection:
- The peers send their external IP addresses in a special payload.
- Each device hashes the payload and the IP, and the results are compared. If the hashes match, no NAT is detected. If they differ, the presence of a NAT device is confirmed in the path.
NAT-T Activation:
- If NAT is detected, a UDP header on port 4500 is inserted in front of the ESP header.
- This allows ESP to traverse NAT devices, and the traffic is handled as if it were regular UDP.

NAT-T ensures robust VPN connectivity even when clients or peers are behind NAT gateways, such as in home networks, hotel Wi-Fi, or cloud environments.

IKE Versions, Hashing, and Key Exchange

As the IPSec VPN process continues, Cisco ASA provides flexibility and backward compatibility through its support for both IKEv1 and IKEv2 protocols. Each version offers unique features and advantages in terms of security and functionality.

IKE Versions

IKE Version 1 (IKEv1):
IKEv1 uses 6 messages and is based on ISAKMP. It supports NAT-T and follows a fire-and-forget model, meaning it doesn’t wait for confirmation of delivery. However, IKEv1 lacks support for VoIP and doesn’t include built-in cryptographic mechanisms for proposal protection.
IKE Version 2 (IKEv2):
IKEv2 reduces overhead by using 4–6 messages and also builds upon ISAKMP. It includes full NAT-T support, can check peer liveness using cookies, and adds support for VoIP traffic. IKEv2 also uses Suite B cryptography, which meets modern compliance standards and provides stronger security.

Hashing

Hashing is a critical security function in the IPSec process. It’s a one-way operation used to ensure the integrity of data by creating a fixed-size output (hash) from variable-size input data. Common hashing algorithms include:

MD5
SHA (Secure Hash Algorithm)

These hashes are compared during negotiation and data transmission to ensure that no tampering has occurred.

ASA Tooling: vpnsetup

Cisco ASA includes a powerful utility called vpnsetup, which guides administrators through the configuration steps for setting up a VPN tunnel. It simplifies the process by prompting for key inputs like encryption algorithms, hashing methods, and peer IPs.

ISAKMP Phase 1: Key and Encryption Setup

During Phase 1, Cisco ASA uses ISAKMP (UDP 500) to establish a secure control tunnel. This tunnel doesn’t yet carry actual user data but instead negotiates and exchanges session keys using Diffie-Hellman key exchange.

To configure this phase, three core components are required:

A Key (the shared secret or dynamically exchanged value)
An Encryption Mechanism
A Hashing Mechanism

Both peers must agree on these parameters. Once the Phase 1 tunnel is up, the devices exchange session keys.

For IKEv1, the following Diffie-Hellman groups can be selected based on required key strength:

Group 1 – 768-bit
Group 2 – 1024-bit
Group 5 – 1536-bit

Phase 2: Finalizing the Tunnel

The session key derived in Phase 1 is used to establish Phase 2, where ESP is employed to encrypt actual user data. These tunnels are what carry the “interesting traffic”—the specific subnets or flows that the administrator defines as worth protecting via the VPN.

To ensure secure communication, it’s essential to define the interesting traffic explicitly, usually through access-lists or crypto maps, so that only authorized and necessary traffic flows through the tunnel.

VPN Tunnel Interfaces, ACLs, and Traffic Handling

As IPSec VPNs are deployed in increasingly complex environments, it’s important to consider not just encryption, but how traffic is routed, filtered, and prioritized across VPN tunnels. Cisco ASA offers several configuration options to enhance flexibility, performance, and maintainability.

Anti-Tampering and Hashing

To ensure data integrity and protect against tampering, VPNs use hashing algorithms. These hashes verify that the contents of a packet haven’t been altered in transit. If even a single bit is modified, the hash check fails and the packet is discarded, ensuring end-to-end trust.

Crypto Map Limitations

While crypto maps are a foundational method for defining VPN parameters, they are static in nature. This becomes problematic when new subnets are introduced. If access control lists (ACLs) are used to define “interesting traffic,” then both ends of the VPN tunnel must be updated with matching ACLs each time a new subnet is added. This is where virtual tunnel interfaces (VTIs) shine—they allow dynamic routing protocols to manage subnet awareness, reducing administrative overhead.

Tunnel Interfaces and IP Addressing

Tunnel interfaces should use private IP addresses. These interfaces operate as internal, logically defined links and are not meant to be directly exposed. Using private addressing also helps avoid overlap with public IP space and simplifies NAT considerations.

If NAT is running on the firewall and you’re using a tunnel interface, having a private IP subnet on the tunnel interface ensures you won’t run into conflicts or route overlaps with public IPs.

Tunnel Groups and Group Policies

In Cisco ASA, site-to-site VPN (L2L) configuration includes unique components not found in IOS. A Tunnel Group is used to define tunnel-level attributes such as the authentication method, while a Group Policy is used to define user-specific or connection-specific parameters like DNS, split tunneling, and idle timeouts. This separation of roles provides modularity and simplifies management.

ACLs, sysopt, and vpn-filter Behavior

For tunnels that terminate on the ASA itself, you don’t need to manually allow IKE or IPSec traffic using ACLs. This is thanks to the sysopt connection permit-vpn setting, which, when enabled, automatically permits all protected (tunneled) traffic. If this is disabled, you must manually permit tunneled traffic in the ACLs.

To filter or control which VPN traffic is permitted, use the vpn-filter command. This allows fine-grained control over tunneled packets, similar to how an access list filters non-VPN traffic.

QoS and IPSec Interactions

When applying Quality of Service (QoS) on IOS routers, keep in mind that IPSec processing occurs before QoS classification. If you attempt to classify traffic after it has been encrypted by ESP or AH, you’ll only see encrypted blobs.

To classify traffic before it’s encrypted, use the qos pre-classify command. This allows the router to inspect and prioritize traffic based on its original headers before applying IPSec encryption. This step is not needed on ASA, which supports classifying unencrypted traffic by default.

Static Reverse Routing for VPNs

Finally, to simplify routing on the ASA, you can use the reverse-route static feature. When applied to a crypto map, this option automatically creates a static route to the destination network defined in the Proxy ACL. This makes it easier to manage return paths for VPN traffic, especially when route injection via dynamic protocols is not used.

Tunnel Overhead and Transport Mode Optimization

When configuring IPSec VPNs, understanding tunnel overhead is key to optimizing performance and MTU efficiency. Overhead occurs when additional headers are applied to encapsulate the original packet, especially when GRE and IPSec encryption are combined.

Tunnel Overhead with GRE and IPSec

In typical configurations where GRE tunnels are secured with ESP encryption, the ESP header encapsulates the entire GRE packet, including its original source and destination IPs. For example:

ESP | 199.1.1.1 | 200.1.1.1 | GRE | 199.1.1.1 | 200.1.1.1 | EIGRP | 192.168.1.1 | 224.0.0.10 | Data

Here, you can see both the ESP outer IP header and the GRE tunnel’s inner IP header, which increases packet size and may impact throughput or cause fragmentation in constrained networks.

Tunnel vs. Transport Mode

By default, IPSec operates in Tunnel Mode, which encrypts and encapsulates the entire original packet—including both the IP header and the payload. This is necessary when the inner and outer IP headers differ.

However, in situations where the inner and outer IP headers are the same—such as with GRE tunnels or native IPSec tunnel interfaces—you can switch to Transport Mode. In Transport Mode, IPSec identifies the duplication between the two headers and removes the redundant outer IP header, reducing overhead.

To configure Transport Mode, use the following transform set:

crypto ipsec transform-set tset esp-3des esp-sha
mode transport

Switching to Transport Mode saves 16 bytes of overhead, streamlining packet structure like this:

ESP | 199.1.1.1 | 200.1.1.1 | GRE | EIGRP | 192.168.1.1 | 224.0.0.10 | Data

Native IPSec Tunnel Interfaces (No GRE)

Originally, tunnel interfaces could only operate using GRE, but Cisco ASA introduced support for native IPSec tunnel interfaces roughly a decade ago. Running IPSec natively on tunnel interfaces offers better performance, improved security, and full routing protocol support—without the added GRE overhead.

To enable this, simply define:

tunnel mode ipsec ipv4

This change removes the 8-byte GRE header, resulting in a more efficient packet structure:

ESP | 199.1.1.1 | 200.1.1.1 | EIGRP | 192.168.1.1 | 224.0.0.10 | Data

Adopting native IPSec tunnel interfaces wherever possible allows for greater throughput, cleaner configurations, and compatibility with dynamic routing protocols like EIGRP and OSPF.

Configuring IKEv1 VPN Between an ASA and a Router

To establish an IKEv1 VPN tunnel between a Cisco ASA and a router, both devices must be configured with compatible Phase 1 and Phase 2 parameters, an access list for interesting traffic, and a properly applied crypto map. Below are step-by-step instructions outlining the configuration on both ends.

Router Configuration

Start by configuring the IKEv1 Phase 1 ISAKMP policy. This includes setting the authentication method, encryption algorithm, hash function, and Diffie-Hellman group:

crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2

Next, define the pre-shared key and the peer’s IP address:

crypto isakmp key cisco123 address 192.1.20.10

Proceed to Phase 2 by configuring the transform set, which determines the IPSec encryption and hashing algorithms:

crypto ipsec transform-set ABC esp-3des esp-md5-hmac

Define the interesting traffic using an access list. This ACL specifies which traffic should be encrypted and protected by the VPN:

access-list 101 permit ip 10.3.3.0 0.0.0.255 10.11.11.0 0.0.0.255

Now configure the crypto map and associate it with the transform set and the remote peer:

crypto map ABC 10 ipsec-isakmp
match address 101
set peer 192.1.20.10
set transform-set ABC

Finally, apply the crypto map to the router’s interface:

interface g1
crypto map ABC

ASA Configuration

On the ASA, begin by enabling IKEv1 on the appropriate interface:

crypto ikev1 enable outside

Then, configure the Phase 1 IKEv1 policy to match the router’s parameters:

crypto ikev1 policy 10
auth pre-share
encryption 3des
hash sha
group 2

Create a tunnel group for the router peer and specify the pre-shared key:

tunnel-group 192.1.23.3 type ipsec-l2l
tunnel-group 192.1.23.3 ipsec-attributes
ikev1 pre-shared-key cisco123

For Phase 2, define the IPSec transform set:

crypto ipsec ikev1 transform-set ABC esp-3des esp-md5-hmac

Specify the interesting traffic using an access list that mirrors the router’s ACL:

access-list 101 permit ip 10.11.11.0 255.255.255.0 10.3.3.0 255.255.255.0

Configure the crypto map to tie everything together:

crypto map ABC 10 match address 101
crypto map ABC 10 set peer 192.1.23.3
crypto map ABC 10 set ikev1 transform-set ABC

Finally, apply the crypto map to the ASA’s interface:

crypto map ABC interface outside

This configuration ensures that both the ASA and the router have matching Phase 1 and Phase 2 parameters and that traffic between the specified subnets is protected. If VPN connectivity fails, double-check ACLs, pre-shared keys, and ISAKMP policies on both ends.

Configuring IKEv2 VPN Between an ASA and a Router

Following the IKEv1 VPN deployment, we will walk through how to configure an IKEv2-based VPN between a Cisco ASA firewall and a Cisco router. IKEv2 offers improved security and flexibility over IKEv1, and this walkthrough ensures both sides are properly aligned for tunnel establishment.

Router-Side Configuration

Begin by configuring the router for IKEv2 Phase 1. Start with defining an IKEv2 proposal which outlines the encryption, integrity, and DH group:

crypto ikev2 proposal IKEV2_PROP
integrity sha1
encryption 3des
group 2

Next, assign this proposal to a policy:

crypto ikev2 policy IKEV2_POL
proposal IKEV2_PROP

Then, configure the IKEv2 keyring to store the pre-shared keys for the remote peer (ASA):

crypto ikev2 keyring IKEV2_KEY
peer ASA-2
address 192.1.30.10
pre-shared-key local cisco111
pre-shared-key remote cisco222

After defining the keyring, create an IKEv2 profile. This profile binds the identity match, authentication methods, and keyring together:

crypto ikev2 profile IKEV2_PROF
match identity remote address 192.1.30.10 255.255.255.255
authentication local pre-share
authentication remote pre-share
keyring local IKEV2_KEY

With Phase 1 complete, proceed to Phase 2 by defining the IPSec transform set:

crypto ipsec transform-set ABC esp-3des esp-md5-hmac

Create an access list to define the interesting traffic for encryption:

access-list 101 permit ip 10.99.99.0 0.0.0.255 10.40.40.0 0.0.0.255

Now configure the crypto map to tie everything together. Specify the peer, transform set, and link the IKEv2 profile:

crypto map ABC 10 ipsec-isakmp
set peer 192.1.30.10
set transform-set ABC
set ikev2-profile IKEV2_PROF
match address 101

Finally, apply the crypto map to the router’s interface:

interface g1
crypto map ABC

ASA-Side Configuration

On the ASA, start Phase 1 by enabling IKEv2 on the outside interface:

crypto ikev2 enable outside

Create a matching IKEv2 policy to mirror the router’s parameters:

crypto ikev2 policy 10
integrity sha
encryption 3des
group 2

Define the tunnel group with peer address, type, and shared keys:

tunnel-group 192.1.100.72 type ipsec-l2l
tunnel-group 192.1.100.72 ipsec-attributes
ikev2 local-authentication pre-shared-key cisco222
ikev2 remote-authentication pre-shared-key cisco111

In Phase 2, configure the transform-set, which is referred to as an IPSec proposal on the ASA:

crypto ipsec ikev2 ipsec-proposal ABC
protocol esp encryption 3des
protocol esp integrity md5

Define an ACL that mirrors the router’s interesting traffic:

access-list 101 permit ip 10.40.40.0 255.255.255.0 10.99.99.0 255.255.255.0

Now configure the crypto map with all associated elements:

crypto map ABC 10 match address 101
crypto map ABC 10 set peer 192.1.100.72
crypto map ABC 10 set ikev2 ipsec-proposal ABC

Lastly, bind the crypto map to the external ASA interface:

crypto map ABC interface outside

This completes the IKEv2 VPN configuration. When correctly implemented, this tunnel will securely transport traffic between the defined networks. IKEv2’s streamlined negotiation process and native NAT traversal support make it ideal for modern site-to-site VPN deployments.

Configuring IKEv1 VPN with PSK

Continuing from the previous configurations, this section covers how to set up an IKEv1-based site-to-site VPN on a Cisco ASA using a pre-shared key (PSK) for authentication. This approach is commonly used for static IP peers and provides a simple, effective method for establishing secure communication.

1. Configure the IKEv1 Policy

Begin by creating an IKEv1 policy that specifies the authentication method, encryption, hashing, and Diffie-Hellman group. You can also define the lifetime for the IKE SA:

crypto ikev1 policy 1
authentication pre-share
encryption des
hash sha
group 5
lifetime 1800

You must also define the peer as a tunnel group of type IPsec-L2L:

tunnel-group x.x.x.x type ipsec-l2l

2. Define IPSec Attributes

Next, set up the IPSec attributes under the tunnel group configuration. This includes defining the pre-shared key and the transform set that determines how traffic will be encrypted and authenticated:

tunnel-group x.x.x.x ipsec-attributes
ikev1 pre-shared-key key
crypto ipsec ikev1 transform-set word esp-des esp-sha-hmac

3. Configure the Security Association

Optionally, you can tune the IPSec Security Association (SA) lifetime to suit your organizational policies. This affects how frequently SAs are renegotiated:

crypto ipsec security-association lifetime seconds x

4. Create the VPN Access List

Define the traffic that will be encrypted using an extended ACL. This ACL designates which local and remote subnets will participate in the VPN tunnel:

access-list num permit ip x.x.x.x mask x.x.x.x mask

5. Configure the Crypto Map

The final step involves tying everything together using a crypto map. This includes referencing the transform set, peer IP, and ACL, and then applying the crypto map to the correct ASA interface:

crypto map word num set ikev1 transform-set set-name
crypto map word num set peer x.x.x.x
crypto map word interface nameif
crypto ikev1 enable nameif

This setup completes the configuration of a PSK-based IKEv1 VPN on the Cisco ASA. It provides a basic but robust encryption scheme suitable for most static site-to-site VPN scenarios. While this example uses DES encryption and SHA hashing, it’s recommended to upgrade to AES and SHA-256 or better in production environments to align with modern security standards.

Site-to-Site VPN with IOS CA and ASA

In this section, we explore how to configure a site-to-site VPN using certificate-based authentication where an IOS router acts as the Certificate Authority (CA). This setup provides a secure and scalable alternative to pre-shared keys (PSK), especially beneficial in environments requiring automation, rollover, or central trust models.

Configuring the IOS CA Server

Begin by setting up the IOS router as the Certificate Authority. First, generate the RSA key pair, ensuring it’s marked as exportable and assigned a unique label:

crypto key generate rsa general-keys exportable label label modulus num

Next, export the key in PEM format with a 3DES-encrypted password:

crypto key export rsa label pem url nvram: 3des password

Enable the HTTP server to support certificate operations:

ip http server

Then configure the PKI server with essential parameters, including issuer name, database location, and auto-enrollment:

crypto pki server word
issuer-name cn=name l=location c=country
database level minimum
database url nvram:
grant auto
no shut

Ensure NTP is configured or the clock is manually set; otherwise, the CA server won’t function properly. Once initialized, the CA certificate and key will be auto-generated unless an external key is provided. If manually generated, the key must be exportable to support archival in PKCS#12 or PEM format. The CA will also auto-rollover certificates close to expiration, maintaining seamless operations during transitions.

Useful commands for validating CA status include:

```
show crypto pki server
```
```
show crypto pki trustpoints status
```
```
show crypto pki server CA-NAME crl
```
```
show crypto pki certificates
```

Configuring the ASA for Certificate Enrollment

Once the IOS CA is up and running, move to the ASA. Start by configuring a trustpoint that points to the IOS CA:

crypto ca trustpoint word
enrollment url http://router-address

Authenticate and enroll to retrieve a certificate:

crypto ca authenticate word
crypto ca enroll word

The ASA will prompt for a password and allow you to select certificate attributes. After successful enrollment, the ASA will trust the root certificate issued by the IOS router.

Configuring the IKEv1 and IPSec Policies on the ASA

Now define the IKEv1 policy, specifying certificate-based authentication:

crypto ikev1 policy num
authentication rsa-sig
encryption des
hash sha
group num
lifetime num

Set the remote peer as an IPsec-L2L tunnel group and associate it with the trustpoint:

tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x ipsec-attributes
ikev1 trustpoint word

Create a transform set for Phase 2:

crypto ipsec ikev1 transform-set t-set esp-des esp-sha-hmac

Optionally, configure the IPSec security association lifetime:

crypto ipsec security-association lifetime seconds 1800

Define the access list for interesting traffic:

access-list 101 extended permit ip 192.168.101.0 255.255.255.0 192.168.102.0 255.255.255.0

Tie it all together with a crypto map:

crypto map word num set ikev1 transform-set word
crypto map word num set peer x.x.x.x
crypto map word num match address 101
crypto map word num set trustpoint word
crypto map word interface nameif

Enable IKEv1 on the ASA interface:

crypto ikev1 enable nameif

This setup ensures secure certificate-based authentication for site-to-site VPNs, eliminating the need for static pre-shared keys and supporting more advanced certificate lifecycle management. The IOS CA architecture, when combined with proper timekeeping and exportable keys, enables full control over key distribution and renewal.

Site-to-Site VPN with PSK and Overlapping IP Using IKEv1

In cases where both sites in a VPN setup use the same internal IP ranges—often due to legacy addressing or branch standardization—it’s essential to implement NAT to avoid routing conflicts. This builds on the IKEv1 VPN with PSK setup and introduces identity NAT with object configuration for address translation.

Configuring Object NAT for Overlapping Subnets

Start by creating object network definitions on the first ASA. These objects define the actual local network and the translated identity that will be exposed through the VPN:

object network object1
subnet x.x.x.x mask

object network object2
subnet x.x.x.x mask

Configure NAT to statically translate object1 to object2 when traffic flows from the inside to the outside interface:

nat (inside,outside) source static object1 object2

Repeat a similar process on the remote ASA. Define a network object for the local network and the translated remote subnet (to match the NAT applied by the other side):

object network object1
subnet x.x.x.x mask

object network object3
subnet x.x.x.x mask

Then configure NAT accordingly:

nat (inside,outside) source static object1 object

This NAT configuration ensures that when traffic is passed through the tunnel, both ASAs see non-overlapping networks, allowing routing and encryption to proceed without conflict.

Crypto Configuration for IKEv1 VPN

Now configure the crypto policy for IKEv1 on both ASAs. This defines how peers authenticate and what parameters are used for Phase 1:

crypto ikev1 policy x
authentication pre-share
encryption des
hash sha
group 5
lifetime 1800

Define the peer as a tunnel-group of type IPsec L2L and assign the PSK:

tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x ipsec-attributes
ikev1 pre-shared-key key

Set the Phase 2 transform set:

crypto ipsec ikev1 transform-set name esp-des esp-sha-hmac

Optionally, configure the IPSec security association lifetime:

crypto ipsec security-association lifetime seconds 1800

Access List and Crypto Map

To match the NAT-translated networks, configure an access list that references object2 and object:

access-list num permit ip object2 mask object3 mask

Create the crypto map and link it to the peer, transform set, and ACL:

crypto map name num set ikev1 transform-set set-name
crypto map name num set peer x.x.x.x
crypto map name interface nameif
crypto ikev1 enable nameif

By translating internal addresses into non-overlapping ranges and correctly applying object-based NAT, this solution enables secure, conflict-free site-to-site communication over IKEv1 IPsec VPN. It’s particularly useful for M&A integrations, multi-tenant data centers, or branch office standardization where identical addressing schemes are unavoidable.

ASA Site-to-Site VPN with PSK and IP SLA for Failover

This setup demonstrates how to implement an IKEv1-based site-to-site VPN using pre-shared keys (PSKs), with IP SLA tracking to provide intelligent failover between two remote peers. This design is especially useful when you want redundancy across two WAN paths or remote gateways.

IP SLA Configuration on ASA1

To begin, configure IP SLA on ASA1 to continuously monitor reachability to a remote peer. This allows the ASA to track remote availability and dynamically prefer one tunnel over another based on real-time reachability.

sla monitor 1
type echo protocol ipIcmpEcho x.x.x.x interface nameif
timeout milliseconds
frequency seconds
exit
sla monitor schedule 1 start-time now life forever
track 11 rtr 1 reachability

This IP SLA configuration sets up an ICMP echo (ping) probe to a remote IP address via a specific ASA interface, and continuously tracks its reachability using track 11.

IKEv1 Site-to-Site VPN with Dual Peers

Next, configure the IKEv1 VPN tunnel settings, beginning with the IKE policy:

crypto ikev1 policy 1
authentication pre-share
encryption aes
hash sha
group 5
lifetime 1800

Create two tunnel groups—one for each remote peer—each using the same pre-shared key:

tunnel-group 103.1.1.100 type ipsec-l2l
tunnel-group 103.1.1.100 ipsec-attributes
ikev1 pre-shared-key cisco123

tunnel-group 104.1.1.100 type ipsec-l2l
tunnel-group 104.1.1.100 ipsec-attributes
ikev1 pre-shared-key cisco123

Define the IPSec transform set for Phase 2:

crypto ipsec ikev1 transform-set t-set esp-aes esp-sha-hmac

Set the IPSec security association lifetime:

crypto ipsec security-association lifetime seconds 1800

Create the ACL that identifies interesting traffic between the LANs:

access-list 101 permit ip 192.168.101.0 255.255.255.0 192.168.102.0 255.255.255.0

Configure the Crypto Map

Create the crypto map and apply both peer IPs with their respective interfaces:

crypto map VPN 10 set ikev1 transform-set t-set
crypto map VPN 10 set peer 103.1.1.100 104.1.1.100
crypto map VPN 10 match address 101
crypto map VPN interface primary
crypto map VPN interface secondary
crypto ikev1 enable primary
crypto ikev1 enable secondary

This configuration sets both peers under the same crypto map sequence, leveraging IP SLA to favor the primary peer and fail over to the secondary if it becomes unreachable.

With IP SLA integration, this site-to-site VPN setup becomes highly resilient. ASA1 uses real-time monitoring to determine peer reachability and dynamically switch VPN tunnels, ensuring continuous secure connectivity across dual WAN paths or redundant remote endpoints.

Site-to-Site VPN with IKEv2 and a Single Pre-Shared Key

This details the configuration of a site-to-site VPN using IKEv2 with a single shared key. IKEv2 simplifies the negotiation process and enhances security, making it preferable in modern deployments.

Step 1: Configure the IKEv2 Policy

Begin by creating an IKEv2 policy. This sets the encryption, integrity, group, and lifetime parameters for Phase 1 negotiation:

crypto ikev2 policy 1
encryption des
integrity sha
group 5
lifetime second 1800

Next, define the remote peer as a tunnel-group of type ipsec-l2l:

tunnel-group 102.1.1.100 type ipsec-l2l

Step 2: Set IPSec Attributes

Configure IPSec attributes under the tunnel-group. This includes both local and remote pre-shared keys, followed by the IPsec proposal definition:

tunnel-group 102.1.1.100 ipsec-attributes
ikev2 local-authentication pre-shared-key cisco123
ikev2 remote-authentication pre-shared-key cisco123

Define the IPSec proposal to specify the encryption and integrity methods:

crypto ipsec ikev2 ipsec-proposal PP
protocol esp encryption des
protocol esp integrity sha-1

Set the IPSec SA lifetime:

crypto ipsec security-association lifetime second 1800

Step 3: Configure the Access List

Define the interesting traffic to be encrypted through the tunnel using an extended access list:

access-list 101 permit ip 192.168.101.0 255.255.255.0 192.168.102.0 255.255.255.0

Step 4: Build the Crypto Map

Now tie everything together with a crypto map, referencing the IKEv2 proposal, peer IP, and ACL:

crypto map VPN 10 set ikev2 ipsec-proposal PP
crypto map VPN 10 set peer 102.1.1.100
crypto map VPN 10 match address 101
crypto map VPN interface outside

Finally, enable IKEv2 on the outside interface:

crypto ikev2 enable outside

This completes the setup of an IKEv2 site-to-site VPN using a shared pre-shared key. With fewer moving parts and a streamlined negotiation model, IKEv2 provides performance and security benefits over its predecessor, making it an ideal choice for secure inter-site communication.

Site-to-Site VPN Using IKEv2 with Dual Keys

In this configuration, we explore a more advanced deployment of IKEv2 site-to-site VPN where separate local and remote pre-shared keys are used for mutual authentication. This can provide better credential compartmentalization between peers and is especially useful in hub-and-spoke VPN environments.

Step 1: Define the IKEv2 Policy

Start by creating the IKEv2 policy on the ASA. This defines the parameters for the IKE SA negotiation (Phase 1), including encryption, integrity, DH group, and lifetime:

crypto ikev2 policy 1
encryption des
integrity sha
group 5
lifetime second 1800

Define the remote peer as a tunnel-group of type ipsec-l2l:

tunnel-group 102.1.1.100 type ipsec-l2l

Step 2: Configure Dual PSK Authentication

Under the tunnel-group, set the IPSec attributes. Here, you configure different keys for local and remote authentication:

tunnel-group 102.1.1.100 ipsec-attributes
ikev2 local-authentication pre-shared-key cisco123
ikev2 remote-authentication pre-shared-key disco123

This dual-key setup allows more granular control of credentials between endpoints.

Step 3: Define the IPSec Proposal and SA Settings

Next, create an IPSec proposal for Phase 2 parameters, including encryption and integrity settings:

crypto ipsec ikev2 ipsec-proposal PPP
protocol esp encryption des
protocol esp integrity sha-1

Set the lifetime for the IPSec Security Association:

crypto ipsec security-association lifetime sec 1800

Step 4: Define the Access List

Configure an ACL to define the interesting traffic that should be encrypted through the VPN tunnel:

access-list 101 permit ip 192.168.101.0 255.255.255.0 192.168.102.0 255.255.255.0

Step 5: Create the Crypto Map

Now bind all the components together using a crypto map:

crypto map VPN 10 set ikev2 ipsec-proposal PPP
crypto map VPN 10 set peer 102.1.1.100
crypto map VPN 10 match address 101
crypto map VPN interface outside

Finally, enable IKEv2 on the external interface:

crypto ikev2 enable outside

This dual-PSK IKEv2 configuration provides more flexibility and isolation in how each endpoint handles authentication, without relying on certificate-based setups. While rarely required for simpler deployments, dual keys are a powerful tool for tighter security policies and key management practices.

Site-to-Site VPN with IOS CA and IKEv2 Certificate Authentication on an ASA

For more robust and scalable VPN authentication, certificates issued by an IOS-based Certificate Authority (CA) can be used in an IKEv2 site-to-site VPN deployment. This configuration walks through setting up the IOS router as a CA, enrolling the Cisco ASA, and completing the IKEv2 VPN setup using digital certificates.

Step 1: Configure the IOS CA

On the IOS router that will serve as the Certificate Authority, begin by generating the RSA keys. The keys must be marked exportable to allow archival and reuse:

crypto key generate rsa general-keys exportable label label modulus num

Export the generated RSA key to NVRAM in PEM format, securing it with a 3DES password:

crypto key export rsa label pem url nvram: 3des password

Enable the HTTP server, which is required for certificate enrollment:

ip http server

Now configure the PKI server itself:

crypto pki server name
issuer-name cn=cn-name l=location c=country database level minimum
database url nvram:
grant auto
no shut

Ensure NTP is set or the clock is manually configured on the router—this is necessary for certificate validity.

You can validate CA status using:

show crypto pki server

Step 2: Enroll the ASA with the IOS CA

Switch to the Cisco ASA and configure a trustpoint to reference the IOS CA:

crypto ca trustpoint IOS-CA enrollment url http://router-address

Authenticate the trustpoint:

crypto ca authenticate IOS-CA

After accepting the root certificate, enroll the ASA:

crypto ca enroll IOS-CA

This will generate and submit a certificate request to the IOS CA. Once enrollment is complete, the ASA will trust the IOS CA as a valid certificate authority.

Step 3: Configure the ASA’s IKEv2 Certificate-Based VPN

Now define the IKEv2 policy on the ASA:

crypto ikev2 policy 1
encryption des
integrity sha
group 5
lifetime seconds 1800

Create the tunnel group and IPSec attributes, referencing the enrolled certificate:

tunnel-group 102.1.1.100 type ipsec-l2l
tunnel-group 102.1.1.100 ipsec-attributes
ikev2 local-authentication certificate IOS-CA
ikev2 remote-authentication certificate

Define the IPSec proposal:

crypto ipsec ikev2 ipsec-proposal PPP
protocol esp encryption des
protocol esp integrity sha-1
crypto ipsec security-association lifetime second 1800

Create the access list to identify interesting traffic:

access-list 101 permit ip 192.168.101.0 255.255.255.0 192.168.102.0 255.255.255.0

Tie everything together with a crypto map:

crypto map VPN 10 set ikev2 ipsec-proposal PPP
crypto map VPN 10 set peer 102.1.1.100
crypto map VPN 10 set trustpoint IOS-CA
crypto map VPN 10 match address 101
crypto map VPN interface outside

Finally, enable IKEv2 on the outside interface:

crypto ikev2 enable outside

This configuration completes a secure site-to-site VPN using IKEv2 and certificate-based authentication via an IOS router acting as the CA. Compared to PSK-based methods, this provides stronger identity assurance and easier credential management, especially when scaling VPN connectivity to multiple remote peers.

Site-to-Site VPN with IKEv2, PSK, and Overlapping Subnets

When configuring a site-to-site VPN in environments where both locations use overlapping or identical IP subnets, additional steps are required to avoid routing and encryption conflicts. Using Cisco ASA and IKEv2 with NAT and object-based policies, this deployment enables secure and seamless connectivity even when subnet duplication exists.

Step 1: Configure Object NAT for Address Translation

Begin by creating object networks on ASA #1. These define the original and translated networks used for NAT:

object network object1
subnet x.x.x.x mask

object network object2
subnet x.x.x.x mask

Apply static NAT to translate object1 to object2:

nat (inside,outside) source static object1 object2

On the second ASA, create similar network objects:

object network object1
subnet x.x.x.x mask

object network object3
subnet x.x.x.x mask

Apply the corresponding static NAT:

nat (inside,outside) source static object1 object3

This translation ensures that when traffic enters the VPN tunnel, both ASAs see unique, non-overlapping subnets.

Step 2: Configure the IKEv2 Policy

Define the IKEv2 Phase 1 policy on the ASA:

crypto ikev2 policy 1
encryption des
integrity sha
group 5
lifetime second 1800

Then create a tunnel-group for the peer:

tunnel-group 102.1.1.100 type ipsec-l2l

Step 3: Set IPSec Attributes and Proposal

Configure authentication using a shared key, followed by the IPSec Phase 2 proposal:

tunnel-group 102.1.1.100 ipsec-attributes
ikev2 local-authentication pre-shared-key cisco123
ikev2 remote-authentication pre-shared-key cisco123

crypto ipsec ikev2 ipsec-proposal PP
protocol esp encryption des
protocol esp integrity sha-1
crypto ipsec security-association lifetime second 1800

Step 4: Define the Access List

To permit only the translated networks, define the ACL using the NAT-translated objects:

access-list 101 permit ip object1-subnet mask object2-subnet mask

Step 5: Configure and Apply the Crypto Map

Tie everything together with a crypto map:

crypto map VPN 10 set ikev2 ipsec-proposal PP
crypto map VPN 10 set peer 102.1.1.100
crypto map VPN 10 match address 101
crypto map VPN interface outside

Finally, enable IKEv2 on the external interface:

crypto ikev2 enable outside

This configuration solves the IP overlap challenge by using object NAT to remap local subnets, then encrypts traffic using IKEv2 with PSK. It’s ideal for environments where subnet realignment isn’t immediately feasible, offering a secure workaround without compromising on network segregation or encryption standards.

IPv6 Site-to-Site VPN using IKEv1 and PSK

With the growing adoption of IPv6, configuring site-to-site VPNs that support native IPv6 addressing is becoming increasingly necessary. Cisco ASA supports IKEv1 VPNs over IPv6, and we will walk through a complete configuration using a pre-shared key (PSK) for authentication.

Step 1: Define the IKEv1 Policy

Start by creating an IKEv1 policy on the ASA to define how the VPN peers will negotiate Phase 1 of the tunnel:

crypto ikev1 policy 1
authentication pre-share
encryption aes
hash sha
group 5
lifetime 1800

Step 2: Configure the Tunnel Group and PSK

Next, define the remote peer using its IPv6 address in a tunnel-group and set the authentication method using a shared secret:

tunnel-group x:x:x::x type ipsec-l2l
tunnel-group x:x:x::x ipsec-attributes
ikev1 pre-shared-key key

Step 3: Define the Transform Set and IPSec Parameters

Configure the transform set to dictate the IPSec Phase 2 encryption and authentication methods. Then define the SA lifetime:

crypto ipsec ikev1 transform-set name esp-aes esp-sha-hmac
crypto ipsec security-association lifetime seconds 1800

Step 4: Define the IPv6 VPN ACL

Set up an IPv6 access list to specify which traffic should be encrypted through the VPN. Unlike IPv4 ACLs, these use IPv6 subnet formatting:

access-list num permit ip x:x:x::/x x:x:x::/x

Step 5: Configure and Apply the Crypto Map

Now bring everything together using a crypto map. This includes linking the transform set, peer, and access list, and applying it to the correct interface:

crypto map name num set ikev1 transform-set tset-name
crypto map name num set peer x:x:x::x
crypto map name num match address acl-num 
crypto map name interface nameif
crypto ikev1 enable nameif

This completes the configuration of an IKEv1 site-to-site VPN tunnel using IPv6 on Cisco ASA. By integrating IPv6-aware object definitions, NAT-less routing, and PSK authentication, you can securely connect modern IPv6-enabled networks while maintaining control over traffic flows.

Site-to-Site IKEv2 VPN with IPv6 and PSK

With native IPv6 networks becoming more prevalent, implementing secure site-to-site tunnels over IPv6 is a necessary evolution for many enterprise environments. We will cover configuring a Cisco ASA firewall to support an IKEv2 VPN over IPv6 using pre-shared key (PSK) authentication.

Step 1: Create the IKEv2 Policy

Start by defining an IKEv2 policy that outlines the cryptographic parameters for Phase 1 negotiation:

crypto ikev2 policy 1
encryption aes
integrity sha
group 5
lifetime seconds 1800

Step 2: Configure the Tunnel Group

Define the peer’s IPv6 address as an ipsec-l2l tunnel group and configure its attributes:

tunnel-group x:x:x::x type ipsec-l2l
tunnel-group x:x:x::x ipsec-attributes
ikev2 local-authentication pre-shared-key key 
ikev2 remote-authentication pre-shared-key key

Both local and remote authentication will use the same PSK in this scenario.

Step 3: Define the IPSec Proposal

Set up the IPSec proposal for Phase 2. This controls how data traffic is protected after the tunnel is established:

crypto ipsec ikev2 ipsec-proposal name protocol esp encryption aes
protocol esp integrity sha-1

Define the IPSec SA lifetime:

crypto ipsec security-association lifetime seconds 1800

Step 4: Create the Access List for IPv6 Traffic

Define an extended access list to identify IPv6 traffic that should be encrypted:

access-list 101 permit ip 192:168:101::/48 192:168:102::/48

Note: IPv6 access lists use CIDR notation (/48) instead of IPv4-style subnet masks.

Step 5: Build and Apply the Crypto Map

Tie everything together using a crypto map:

crypto map name num set ikev2 ipsec-proposal proposal-name
crypto map name num set peer x:x:x::x
crypto map name num match address acl-num
crypto map name interface nameif

Finally, enable IKEv2 on the chosen ASA interface:

crypto ikev2 enable nameif

With this configuration, your ASA is ready to establish a secure IPv6-based IKEv2 VPN tunnel using a PSK. IKEv2 offers streamlined negotiation, better NAT traversal, and stronger resilience than IKEv1, making it the preferred option for modern IPsec deployments.

Troubleshooting and Show Commands for IKEv1 and IKEv2

When configuring IKEv1 or IKEv2 VPN tunnels on Cisco ASA, it’s critical to know how to troubleshoot tunnel establishment failures effectively. Below is a breakdown of show commands and debug outputs that can help identify and resolve common issues.

Show Commands for IKEv1

Use these commands to inspect the state of IKEv1 tunnels:

show crypto ipsec sa | inc ip-source-or-dest – Quickly check for multiple SAs, which may indicate split tunnel issues or mismatches.
show vpn-sessiondb detail l2l
show crypto ikev1 sa
show crypto ikev1 stats
show crypto ipsec sa
show crypto ipsec sa detail

To dive deeper, use debug mode:

debug crypto ikev1 debug-level
no logging console

Or disable debugging afterward with:

no debug crypto ikev1

IKEv1 Debug Analysis Examples

If you’re seeing debug logs showing errors such as:

IKEv1 DEBUG: AAL SA proposal found unacceptable

…it often means that the encryption or hashing algorithms do not match between peers. Double-check that both sides are configured with matching Phase 1 and Phase 2 proposals.

Another common issue is mismatched Diffie-Hellman groups, indicated in debug like so:

IKEv1 Phase 1 failure: Mismatched attribute types for class Group Description: Rcv’d: group 5; Cfg’d: group 2

Make sure the group value in your IKEv1 policy is identical on both peers.

Tunnel Group Matching and Phase 2 Proposal Failures

If debug output contains lines like:

No matching tunnel group found

…it likely means the peer IP address isn’t associated with a defined tunnel group. Run:

show run tunnel-group

…to confirm the peer is correctly defined. Similarly, if Phase 1 succeeds but Phase 2 fails due to SA mismatches, the debug may show:

IPSec SA proposal found unacceptable

Ensure transform sets and IPSec proposals match exactly between the peers.

Missing Crypto Map Bindings

If the ASA receives VPN traffic but no crypto map is applied to the interface, you’ll see logs like:

No crypto map bound to interface... dropping pkt

This issue is commonly overlooked and easy to fix. Confirm your interface binding with:

show run crypto map

…and ensure your crypto map is tied to the proper interface:

crypto map name interface outside

IKEv2-Specific Troubleshooting

For IKEv2, use these show/debug commands:

```
show crypto ikev2 sa
```
```
show crypto ikev2 stats
```
```
show crypto ipsec sa
```
```
show crypto ipsec sa detail
```
```
debug crypto ikev2 protocol 127
```

When debugging IKEv2, one of the most common failures occurs due to mismatched policy parameters. You may see output like:

IKEv2-PROTO-5: Failed to verify the proposed policies
IKEv2-PROTO-1: Failed to find a matching policy

This indicates that the peer’s IKEv2 proposal doesn’t match any of the ASA’s configured IKEv2 policies. Confirm your configured crypto ikev2 policy matches encryption, integrity, and group parameters.

Final Tips

Use sysopt connection permit-vpn to ensure traffic from lower-security interfaces can enter via the VPN.
Always match lifetime, group, hash, and encryption settings between both peers.
Monitor for duplicate SAs and rekey behavior when using IP SLA or failover configurations.