Site-to-Site IPSec VPN Using PKI on ASA: Evolution from the Old to the New Post ASA 9.7

Site-to-Site IPSec VPNs (Virtual Private Networks) are a critical part of network security, enabling secure communication between different sites over the internet. They are often used by enterprises to securely connect branch offices, data centers, or remote locations to a central network. One of the most common methods to authenticate and establish secure connections in an IPSec VPN is using Public Key Infrastructure (PKI). Over the years, Cisco ASA (Adaptive Security Appliance) has been a popular choice for implementing these VPNs.

Since the release of ASA version 9.7, there have been significant changes in how Site-to-Site IPSec VPNs are configured, especially when PKI is involved. This blog will delve into the evolution of configuring a Site-to-Site IPSec VPN with PKI on Cisco ASA, comparing the old way and the new way post-ASA 9.7.

### **The Old Way: Pre-ASA 9.7**

Before ASA version 9.7, setting up a Site-to-Site IPSec VPN with PKI required configuring various components manually, often involving multiple steps that could lead to complex troubleshooting. Here’s a breakdown of the traditional approach:

#### 1. **PKI Setup:**

   - **Certificate Authorities (CAs):** You had to manually configure certificate authorities for both local and remote ASA devices. This involved importing CA certificates from external Certificate Authorities (CAs) or setting up your own internal CA infrastructure.

   - **Trustpoint Configuration:** The ASA had to be configured with a "trustpoint," which is the certificate authority the ASA trusts. This would include steps like configuring the trustpoint, importing the CA certificate, and linking it to the ASA.

   

#### 2. **IKEv1/2 Configuration:**

   - You needed to configure IKE (Internet Key Exchange) settings manually, including defining the IKE version, the encryption and hashing algorithms, and other VPN parameters. Authentication was done through certificates rather than pre-shared keys (PSK), which required using the trustpoint set up earlier for the VPN peers.

   

#### 3. **IKEv1/IKEv2 Policies:**

   - The ASA required manual configuration of specific IKE policies, which included defining the phase 1 encryption, hashing, and authentication methods. Each peer’s certificate was manually linked to the policy to establish mutual authentication.

   

#### 4. **Cryptomap and IPSec Policies:**

   - A crypto map was configured to associate the IPSec VPN settings with the ASA interface. This involved manually linking the cryptographic settings, including encryption and integrity algorithms, and specifying the remote IP address and local peer configurations.

   

#### 5. **Debugging and Maintenance:**

   - Troubleshooting Site-to-Site VPNs in the old setup often involved diving deep into the ASA's logs and CLI (command-line interface) outputs, which could be tedious and time-consuming. Manual certificate management, CRL (certificate revocation list) checks, and periodic updates to trustpoints often led to errors.

### **The New Way: Post-ASA 9.7**

Starting with ASA version 9.7, Cisco introduced several new features that simplify the configuration and maintenance of Site-to-Site IPSec VPNs, especially when PKI is used for authentication. These changes are aimed at enhancing automation, improving security, and reducing administrative overhead.

#### 1. **Simplified PKI Configuration:**

   - **PKI Integration:** With ASA 9.7 and later, Cisco improved PKI integration. The new ASA software allows for seamless integration with external PKI systems, and certificates can be automatically retrieved and updated from a CA, making manual management less cumbersome.

   - **Automatic Certificate Enrollment:** Rather than manually importing certificates, ASA 9.7+ can automatically request and renew certificates from a CA. This streamlines the certificate lifecycle and reduces the administrative burden.

   

#### 2. **IKEv2 Enhancements:**

   - **Automatic IKEv2 Configuration:** ASA 9.7+ has improved the handling of IKEv2, making it easier to configure. Now, IKEv2 settings can be automated and associated with trustpoints more seamlessly, reducing the manual input needed to set up encryption and hashing parameters.

   - **Single Phase 1 Policy:** One of the significant improvements is the ability to configure a single IKEv2 policy for both IKEv1 and IKEv2 connections. This feature simplifies the configuration and reduces the chances of errors related to mismatched policies.

   

#### 3. **Crypto Maps are Phased Out:**

   - **Policy-Based Routing Replaced by Tunnel Groups:** In ASA versions prior to 9.7, crypto maps were used to define how IPSec traffic should be handled. Post-ASA 9.7, Cisco introduced the use of tunnel groups to define VPN settings and eliminate the need for crypto maps in many scenarios.

   - **Tunnel Group Simplification:** ASA now allows administrators to define the entire VPN policy within a tunnel group. This streamlines the configuration, reduces complexity, and improves the scalability of VPN setups.

   

#### 4. **Simplified Certificate Management:**

   - **Automated Certificate Management (ACM):** ASA 9.7+ introduced the Automated Certificate Management (ACM) feature, which simplifies the management of both server and client certificates. It allows ASA devices to automatically retrieve and manage certificates, renew them, and handle certificate revocation checking (CRL) automatically.

   - **Built-in Support for Multiple Trustpoints:** Instead of manually managing multiple trustpoints and their certificates, ASA now supports multiple trustpoints that are easier to configure and maintain.

   

#### 5. **Improved Monitoring and Troubleshooting:**

   - **Enhanced Logging and Debugging:** Post-ASA 9.7, Cisco introduced improved logging and diagnostics for Site-to-Site VPNs, allowing for easier monitoring of the VPN tunnel’s health. This includes better integration with centralized logging and management systems.

   - **SSL Certificate Validation:** The ASA now has improved support for SSL certificate validation for Site-to-Site VPNs, making it easier to detect and resolve certificate-related issues.

### **Key Advantages of the New Approach**

1. **Automation and Reduced Complexity:**

   The biggest advantage of the new approach post-ASA 9.7 is automation. The automatic certificate enrollment and updates drastically reduce the need for manual intervention and the chances of configuration errors. The integration of the IKEv2 protocols with certificates has made the configuration process more intuitive.

2. **Scalability and Ease of Maintenance:**

   The transition from using crypto maps to tunnel groups simplifies VPN management, especially when scaling the number of connections. Additionally, automated certificate management makes it easier to maintain and troubleshoot large numbers of Site-to-Site VPN connections.

3. **Security Enhancements:**

   ASA 9.7+ offers enhanced security capabilities by ensuring that certificates are regularly updated, preventing expired or compromised certificates from impacting the VPN tunnel. The built-in features like certificate validation and enhanced IKEv2 support also ensure better encryption and authentication methods.

4. **Improved User Experience:**

   With an easier-to-navigate CLI and less manual configuration required, administrators can focus more on network security and less on maintaining the VPN infrastructure.

### **Conclusion**

The evolution of Site-to-Site IPSec VPN configuration on Cisco ASA devices from the old way to the new approach post-ASA 9.7 represents a significant leap forward in terms of automation, security, and simplicity. The transition from manual certificate handling and complex configurations to more automated, scalable, and user-friendly processes allows network administrators to set up and maintain secure VPN connections with far less effort. As Cisco continues to improve the ASA platform, these innovations set the stage for more seamless and efficient VPN management in enterprise environments.

If you haven’t yet upgraded to ASA 9.7 or later, it’s time to consider the enhanced features and improved management options that come with the latest software versions. Whether you're implementing new Site-to-Site VPNs or maintaining existing connections, the new way is the way to go.

Modernizing IKE Phase 1: Insights on Main Mode Message 1 in ASA Post-9.7

When configuring VPNs, security engineers frequently encounter the Internet Key Exchange (IKE) protocol, which establishes a secure communication channel between two peers. IKE operates in two phases: **IKE Phase 1** (which authenticates peers and sets up a secure channel) and **IKE Phase 2** (which negotiates security associations for data transfer). Prior to Cisco Adaptive Security Appliance (ASA) 9.7, Main Mode in IKE Phase 1 required a series of six packets exchanged to complete peer negotiation. However, with advances in security protocols, many aspects of IKE, including Main Mode, have been optimized in Cisco ASA releases post-9.7. 

Let’s take a closer look at how IKE Phase 1 Main Mode Message 1 works post-ASA 9.7.

---

#### IKE Phase 1: Main Mode Message 1 Overview

In IKE Phase 1, Main Mode is typically used when establishing a secure VPN tunnel. It uses six messages for the negotiation, which include:

- **Messages 1-2:** Negotiation of Security Policies

- **Messages 3-4:** Diffie-Hellman Exchange (exchange of public keys)

- **Messages 5-6:** Authentication of Peers

Here, we focus specifically on **Message 1**, the starting point of Main Mode in IKE Phase 1.

---

### Pre-9.7 ASA Implementation of IKE Phase 1 Main Mode Message 1

Previously, in ASA implementations prior to 9.7:

1. **IKE Phase 1 Main Mode** was initiated, with the expectation of six messages for completing Phase 1 negotiation.

2. **Message 1** contained locally configured ISAKMP policies, which were sent from the initiator to the responder on UDP port 500. These policies included key attributes, such as encryption algorithms, hashing, Diffie-Hellman group, and the authentication method.

3. The ASA evaluated its local ISAKMP policies to determine which policy to use with the peer.

Since **Aggressive Mode** in IKE was not configured by default, the message would not initiate an Aggressive Mode connection, meaning that only Main Mode would be used in these cases.

---

### Changes in ASA Post-9.7: Key Enhancements

Cisco ASA 9.7 and later versions brought significant enhancements to the IKE Phase 1 process, particularly in handling Main Mode’s Message 1. Here’s what changed:

1. **Enhanced Flexibility with IKEv2:**

   - ASA 9.7 introduced improved support for **IKEv2**, a more secure, efficient successor to IKEv1.

   - While IKEv1 Main Mode is still supported, IKEv2 brings optimizations, reducing the need for the six-message exchange.

   - IKEv2 supports only a four-message sequence for establishing Phase 1, improving the speed and security of connections.

   

2. **Streamlined ISAKMP Policy Configuration:**

   - The ISAKMP configuration process became more streamlined, focusing on **simplifying security policy negotiation**.

   - Policies, once defined with IKEv1 parameters (encryption, hashing, DH group, and pre-shared key), are now easier to manage with clear parameters for IKEv2, leading to quicker negotiations.

   - For devices still using IKEv1 Main Mode, the configuration process remains, but with enhanced support and diagnostic logging to help troubleshoot configuration issues.

3. **Aggressive Mode De-emphasis:**

   - Cisco ASA Post-9.7 environments continue to use **Main Mode by default**, and Aggressive Mode is still available but generally discouraged in favor of the more secure Main Mode (or transitioning entirely to IKEv2).

   - This is due to Aggressive Mode’s weaker security profile; it’s not recommended in scenarios where higher security is critical.

4. **Enhanced Logging and Debugging:**

   - Cisco ASA Post-9.7 introduced enhanced logging capabilities, which provide more detailed insights into IKE negotiations, especially when peers attempt to establish connections using Main Mode or Aggressive Mode.

   - These logs can highlight whether a peer attempts Aggressive Mode, aiding troubleshooting.

---

### Practical Example: Configuring IKE Phase 1 Main Mode Message 1 on ASA Post-9.7

Below is a sample configuration showing how to define ISAKMP policies on ASA 9.7+ for IKE Phase 1, ensuring Main Mode is used:

# Enable IKEv1 on the ASA device

crypto isakmp enable outside

# Define IKEv1 Policy

crypto isakmp policy 10

 authentication pre-share

 encryption aes-256

 hash sha256

 group 5

 lifetime 86400

- **Explanation:**

  - `authentication pre-share`: Specifies pre-shared key as the authentication method.

  - `encryption aes-256`: Uses AES-256 encryption.

  - `hash sha256`: Uses SHA-256 for hashing, increasing security.

  - `group 5`: Specifies Diffie-Hellman Group 5.

  - `lifetime 86400`: Sets a lifetime of 24 hours.

Once configured, when the ASA initiates IKE Phase 1, the Main Mode Message 1 will contain these parameters, allowing the peer to select from the ISAKMP policies defined.

---

### Key Takeaways

- **Main Mode vs. Aggressive Mode:** Main Mode is the preferred method for Phase 1 in ASA Post-9.7, aligning with security best practices, as Aggressive Mode is less secure.

- **Enhanced Security with IKEv2:** ASA 9.7+ supports IKEv2, which offers a more efficient negotiation process and improves overall security.

- **Simplified Configuration and Troubleshooting:** With enhanced logging and streamlined policy management, Cisco ASA post-9.7 helps network engineers better manage and troubleshoot VPNs.

---

As Cisco ASA devices continue to evolve, using IKEv2 where possible is recommended due to its speed, efficiency, and improved security compared to IKEv1. However, for legacy setups that require IKEv1 Main Mode, ASA 9.7+ maintains robust support with improved logging and configuration options. 

---

This understanding should help network engineers configure secure VPNs on ASA 9.7+ while ensuring compatibility with both IKEv1 and IKEv2.