Site-to-Site IPSec VPN Using EasyVPN with ISAKMP Profiles: Old vs New Cisco IOS Configuration

Site-to-Site IPSec VPN using EasyVPN with ISAKMP Profiles (Old vs New Cisco IOS)

Key Takeaway: EasyVPN simplifies IPSec deployment, but newer IOS versions shift towards IKEv2 + VTIs (FlexVPN), changing how configurations are structured.

Table of Contents

• Introduction
• What is EasyVPN?
• Core Components
• Crypto Math Explained
• Old IOS Config
• New IOS Config
• Old vs New Comparison
• Packet Flow
• Verification
• Troubleshooting
• Interview Q&A
• Related Articles

Introduction

EasyVPN is designed to simplify IPSec VPN deployment by reducing configuration complexity on remote routers.

However, modern IOS versions introduce significant architectural changes such as:

• IKEv2 adoption
• Keyrings instead of global keys
• VTI-based VPNs (FlexVPN)

What is EasyVPN?

EasyVPN allows a central router (server) to push VPN configuration to remote routers (clients).

Key Idea: Instead of configuring everything manually, the server distributes policies.

Core Components

• ISAKMP Policy (Phase 1)
• ISAKMP Profile (Identity matching)
• Transform Set (Encryption)
• Crypto Map / IPsec Profile

IPSec Crypto Math Explained (From Zero to CCNP Level)

IPSec security is not magic — it is built on a few simple mathematical ideas:

• Multiplication (encryption)
• One-way functions (hashing)
• Modular arithmetic (Diffie-Hellman)

Let’s break each one in the simplest possible way.

1. Encryption (Confidentiality)

Encryption converts readable data into unreadable data using a key.

Ciphertext = Encrypt(Plaintext, Key)

Simple Understanding

Think of it like a lock:

• Data = message
• Key = password
• Encryption = locking the message

Step-by-Step Example

Plaintext = 10 Key = 3 Encrypted = 10 × 3 = 30

👉 Without the key, you can't easily go back.

2. Hashing (Integrity)

Hashing ensures data is not changed during transmission.

Hash = H(Data)

Key Properties

• One-way (cannot reverse)
• Same input → same output
• Small change → completely different output

Example

Data: HELLO → Hash: X123 Data: HELLo → Hash: Z987

👉 Even a tiny change completely alters the hash.

3. Why Hashing is Used in IPSec

When data is sent:

• Sender computes hash
• Receiver recomputes hash

👉 If hashes match → data is safe
👉 If not → data was altered

4. Diffie-Hellman (Key Exchange - Most Important)

This is the heart of IPSec.

👉 It allows two routers to create a shared secret WITHOUT sending it.

Math Formula

Shared Key = (g^a mod p)^b mod p

Step-by-Step Simple Example

Let’s simplify:

• g = 5 (public)
• p = 23 (public)

Router A:

Private = 6 Public = (5^6) mod 23 = 8

Router B:

Private = 15 Public = (5^15) mod 23 = 19

Now Exchange Public Keys

Router A computes:

Shared = (19^6) mod 23 = 2

Router B computes:

Shared = (8^15) mod 23 = 2

👉 Both get SAME key = 2 👉 But they NEVER sent it!

Why This is Secure

• Public values are visible
• Private values are secret
• Attacker cannot compute shared key easily

5. Putting It All Together (IPSec Flow)

Here’s what happens in real IPSec:

1. Diffie-Hellman → generate shared key
2. Hash → verify identity
3. Encryption → secure data

Real IPSec Mapping

Concept	Purpose
Diffie-Hellman	Key exchange
Hash (SHA)	Integrity
AES	Encryption

6. Why Math Matters in EasyVPN

EasyVPN simplifies configuration — but internally:

• DH creates keys
• Hash verifies identity
• Encryption protects traffic

Most Important Insight:
IPSec is just three math ideas repeated:

Multiply (encrypt) + Verify (hash) + Share secret (DH)

Final Intuition

Think of IPSec like this:

• Diffie-Hellman → agree on secret password
• Hash → verify no tampering
• Encryption → lock the data

👉 That’s the entire VPN system simplified.

Old IOS Configuration

Full Config

crypto isakmp policy 10 encryption aes 256 hash sha authentication pre-share group 14 crypto isakmp key MY-SECRET-KEY address 192.0.2.2 crypto ipsec transform-set MY-TRANSFORM esp-aes 256 esp-sha-hmac crypto isakmp profile MY-ISAKMP-PROFILE keyring default match identity address 192.0.2.2 local-address Gig0/0 crypto map MY-CRYPTOMAP 10 ipsec-isakmp set peer 192.0.2.2 set transform-set MY-TRANSFORM set isakmp-profile MY-ISAKMP-PROFILE match address 100 interface Gig0/0 crypto map MY-CRYPTOMAP

New IOS Configuration (IKEv2 + VTI)

Modern Config

crypto ikev2 proposal PROP encryption aes-cbc-256 integrity sha256 group 14 crypto ikev2 policy POLICY proposal PROP crypto ikev2 keyring KR peer PEER1 address 192.0.2.2 pre-shared-key local KEY pre-shared-key remote KEY crypto ikev2 profile PROFILE match identity remote address 192.0.2.2 255.255.255.255 authentication local pre-share authentication remote pre-share keyring local KR crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac crypto ipsec profile IPSEC-PROFILE set transform-set TS set ikev2-profile PROFILE interface Tunnel0 tunnel source Gig0/0 tunnel destination 192.0.2.2 tunnel mode ipsec ipv4 tunnel protection ipsec profile IPSEC-PROFILE

Old vs New (Critical Differences)

Feature	Old IOS	New IOS
IKE Version	IKEv1	IKEv2
Keys	Global	Keyring
VPN Type	Crypto Map	VTI (Tunnel)
Scalability	Limited	High

Packet Flow (Simplified)

• IKE Phase 1 → Secure channel
• IKE Phase 2 → Data encryption
• IPSec tunnel established

Verification

show crypto ikev2 sa show crypto ipsec sa

Troubleshooting

• Check key mismatch
• Verify policies
• Check ACL

debug crypto ikev2

Interview Questions

Expand

Q: Why IKEv2?
Better security and efficiency

Q: Why VTI?
Simplifies routing and scalability

Related Articles

• EasyVPN NEM
• Aggressive Mode
• IPSec PKI
• PKI Dynamic
• VPN with NAT

Conclusion

Modern IOS shifts towards IKEv2 and FlexVPN. Understanding both old and new models is critical for real-world deployments and interviews.

Final Insight: Learn old configs for troubleshooting legacy networks, and new configs for modern scalable design.

Transitioning from IKEv1 to IKEv2: Enhancements in ASA Post-9.7 VPN Configurations

In traditional VPN setups, the IKE (Internet Key Exchange) protocol plays a crucial role in establishing secure connections between two peers over an untrusted network. This includes exchanging keys and authenticating the peers before communication begins. For decades, IKEv1 and specifically IKE Phase 1 Main Mode Message 4 has been instrumental in establishing this initial secure channel.

However, as network security and protocols evolved, the release of Cisco’s ASA (Adaptive Security Appliance) version 9.7 brought new ways to handle IKE negotiations, particularly with advancements in IKEv2. This article will explore the traditional IKE Phase 1 Main Mode message process, then dive into how the modern approach, particularly on ASA Post-9.7, has improved it. 

---

### Traditional Approach: IKE Phase 1 (Main Mode) Message 4

Before diving into the newer methods, let’s briefly review the purpose of Message 4 in the IKE Phase 1 (Main Mode) sequence, especially with IKEv1, which is commonly configured in older VPN setups.

In IKEv1, the Main Mode exchange consists of six messages:

1. **Messages 1 and 2**: These messages exchange the initial policy proposals between peers.

2. **Messages 3 and 4**: This is where the Diffie-Hellman (DH) key exchange takes place, enabling each peer to establish a common secret key.

3. **Messages 5 and 6**: Used for authentication.

**Message 4 Specifics**:

When Message 4 arrives, it contains the **KE (Key Exchange) payload** which enables both peers to derive a shared session key. The calculation also uses a pre-shared key (PSK) locally configured on each peer, and this key is critical for establishing secure parameters in the session. This message additionally allows each peer to identify if a NAT (Network Address Translation) device is present in the path, an important detail for maintaining a stable VPN tunnel.

### What Changed in ASA Post-9.7?

With ASA 9.7, Cisco introduced enhanced IKEv2 support, encouraging users to adopt IKEv2 for better security, efficiency, and flexibility. IKEv2 addresses several limitations of IKEv1, offering simpler and more robust setup processes and improved handling of NAT traversal.

Key updates in the handling of IKE negotiations post-9.7 include:

1. **Transition to IKEv2**:

   - **IKEv2 Simplifies Exchange**: Unlike IKEv1, which required six messages in Main Mode to negotiate the phase, IKEv2 reduces this exchange down to just four messages in total. This simplified process reduces latency and complexity.

   - **Enhanced NAT Traversal**: IKEv2 supports NAT traversal more natively and doesn’t require as many specific messages to detect NAT devices along the path.

2. **Modern Key Derivation Mechanism**:

   - In IKEv2, the keys are derived with a more advanced cryptographic method, often using ECDH (Elliptic Curve Diffie-Hellman) instead of the traditional DH groups. This results in stronger security with smaller key sizes and faster computation, thus enhancing performance and security simultaneously.

3. **Fragmentation Support**:

   - In IKEv2, ASA 9.7 introduced **IKE message fragmentation**, a helpful feature to avoid issues when the message size exceeds the MTU (Maximum Transmission Unit) along the path, especially relevant with large certificates. Fragmentation support ensures that large IKE messages do not get dropped or cause issues in establishing the tunnel.

4. **Unified NAT Detection**:

   - IKEv2 on ASA 9.7 introduces a unified way of handling NAT traversal and detection, without relying on separate messages. This streamlines the process and improves reliability, especially in complex NAT environments where packets may have altered IP addresses and ports.

### Modern Message Flow in ASA 9.7+ with IKEv2

Let’s break down how the modern process works in IKEv2, which is the preferred approach on ASA devices post-9.7:

1. **Initiator Sends SA Proposal**:

   - The initiator (one of the peers) sends an IKE_SA_INIT message, which proposes the cryptographic algorithms and DH group to be used.

2. **Responder Acknowledges and Provides KE Payload**:

   - The responder replies with an IKE_SA_INIT message that contains a KE payload, allowing both sides to establish the common session key in a single exchange, as opposed to multiple exchanges required in IKEv1 Main Mode.

3. **Initiator Authentication and Traffic Selector Exchange**:

   - After the initial session key is established, the initiator sends an IKE_AUTH message to authenticate itself. This message includes traffic selectors to define what subnets or IP ranges are accessible through the VPN.

4. **Responder Authentication and Traffic Selector Confirmation**:

   - The responder verifies the initiator’s authentication, then responds with its own IKE_AUTH message, completing the authentication and finalizing the VPN session parameters.

This new process with IKEv2 eliminates the need for separate Message 4 NAT detection in IKEv1, as IKEv2 handles this more seamlessly. Additionally, the reduced number of messages (only four in total) provides a faster and more efficient setup.

### Advantages of Using ASA Post-9.7 with IKEv2

Using IKEv2 on ASA Post-9.7 provides several clear benefits:

1. **Reduced Latency and Complexity**: Fewer messages and a more streamlined exchange process cut down on the time required to establish the VPN.

2. **Stronger Security with ECDH**: ASA devices support stronger cryptographic algorithms with smaller, more efficient key sizes.

3. **Better NAT Traversal**: Unified NAT handling in IKEv2 eliminates issues and improves compatibility across NAT devices.

4. **Built-In Fragmentation Support**: Ensures compatibility across varied network configurations without issues due to MTU limits.

5. **Simplified Configuration and Management**: IKEv2’s streamlined message process also reduces configuration complexity, which is a boon for administrators managing large VPN environments.

### Conclusion

While IKEv1 Main Mode Message 4 has historically been essential for deriving the session key and detecting NAT, modern ASA versions (post-9.7) have moved beyond this older protocol. With IKEv2’s enhanced features and simpler message flow, ASA post-9.7 environments can establish secure, efficient, and robust VPNs with far less hassle. Moving to IKEv2 not only simplifies VPN configuration and management but also strengthens security by using advanced cryptographic protocols and handling NAT more reliably. 

If you are managing a Cisco ASA environment and have yet to adopt IKEv2, consider upgrading to ASA 9.7+ and configuring your VPNs with IKEv2. This shift will position your network to handle modern security demands more effectively and with far greater efficiency.