91 Days to CCIE SEC v6.1 Lab

January 12, 2026 / Balaji Bandi / 0 Comments

Cisco Site to Site VPN (using FTD or ASA)

Establishing a Site-to-Site (S2S) IPSec VPN is a core skill for any network security engineer. While the fundamental IKE (Internet Key Exchange) concepts remain the same, the deployment steps vary significantly between the GUI-driven Cisco Firepower Threat Defence (FTD) and the CLI-centric Cisco ASA using ASDM. Cisco ASA and Firepower Threat Defense (FTD) devices are still heavily used in enterprise environments.

Core Technical Concepts

Before configuring, it is essential to understand the two negotiation phases:

  • Phase 1 (IKEv1/IKEv2): Establishes a secure management tunnel between the two firewall public IPs. This involves negotiating encryption (AES), hashing (SHA), and Diffie-Hellman (DH) groups.
  • Phase 2 (IPSec): Establishes the data tunnel for actual user traffic. It defines “interesting traffic” (what subnets to encrypt) using a Crypto Map (Policy-Based) or a Virtual Tunnel Interface (Route-Based).

1. The Classic Approach: IKEv1

IKEv1 splits its work into two distinct phases. Think of Phase 1 as building the “secure room” and Phase 2 as the “business” conducted inside that room.

Phase 1: Establishing the Management Tunnel

The goal here is to create an ISAKMP SA (Security Association). This can happen in two ways:

  • Main Mode (MM): The Secure Choice (6 Messages)
    • MM1 & MM2: The peers agree on the “Five Horsemen”: Hash (SHA/MD5), Encryption (AES/3DES), Authentication (PSK/Cert), DH Group, and Lifetime.
    • MM3 & MM4: The Diffie-Hellman key exchange happens. Encryption keys are now generated.
    • MM5 & MM6: The peers identity themselves (IP addresses) and authenticate. Because these are sent after the keys are exchanged, identities remain encrypted and hidden from eavesdroppers.
  • Aggressive Mode (AM): The Fast Choice (3 Messages)
    • AM packs everything into three messages. It’s faster but transmits identities in cleartext, making it less secure and less flexible than Main Mode.

Phase 2: The Data Tunnel (Quick Mode)

Once the management tunnel is ready, Quick Mode (QM) kicks in. It uses a 3-message exchange to establish two unidirectional IPsec SAs (one for sending, one for receiving).

  • PFS (Perfect Forward Secrecy): An optional but highly recommended feature. It forces the firewall to generate new keys for Phase 2 that aren’t derived from Phase 1, ensuring that if one key is compromised, the others remain safe.

2. The Modern Standard: IKEv2

IKEv2 was built to fix the complexities and inefficiencies of its predecessor. It does away with the “Modes” and uses a simple Request/Response architecture.

The Streamlined Exchange

While IKEv1 requires 9 messages (6 for MM + 3 for QM) to get traffic flowing, IKEv2 does it in just 4 messages:

  1. IKE_SA_INIT: Negotiates crypto and performs the DH exchange in one round trip.
  2. IKE_AUTH: Authenticates the session and creates the first “Child SA” (the IPsec data tunnel).

3. Why Upgrade? IKEv2 Improvements

If your hardware supports it, IKEv2 is the clear winner for several reasons:

  • Efficiency: Fewer messages mean faster tunnel establishment and less bandwidth overhead.
  • Asymmetric Authentication: One side can use a Certificate while the other uses a Pre-Shared Key—perfect for B2B setups with different security policies.
  • Next-Gen Encryption (NGE): Native support for ECDSA-SIG (Elliptic Curve) for stronger security with shorter keys.
  • Mobile Friendly: Native support for EAP (Extensible Authentication Protocol) makes it the industry standard for remote-access VPNs.
  • Resilience: Includes Anti-DoS features to protect the firewall’s CPU during a flood of connection requests.

FTD to FTD (via Management Center/FMC) you can also use FDM onbox Manamgenet tools

Cisco FTD is typically managed via the Secure Firewall Management Center (FMC).

1. Define the Topology

  1. Navigate to Devices > VPN > Site to Site.
  2. Click Add VPN > Firepower Threat Defense Device.
  3. Choose Point to Point and select IKEv2 (industry standard).

2. Configure Endpoints (Nodes)

  • Node A (FTD1): Select the device and the outside interface. Add a Network Object for its local protected subnet (e.g., 10.1.1.0/24).
  • Node B (FTD2): Repeat the process for the second FTD and its subnet (e.g., 10.2.2.0/24).

3. Phase 1 & 2 Parameters

  • IKE Tab: Create an IKE Policy. Use AES-256, SHA-256, and DH Group 14.
  • IPSec Tab: Create an IPSec Proposal (Transform Set). Ensure it matches the IKE settings (e.g., ESP-AES-256 and ESP-SHA-256).
  • Authentication: Select Pre-shared Manual Key and enter a complex password.

4. Crucial Final Steps: NAT & Access Control

  • NAT Exempt: You must create a Manual NAT rule that tells the FTD not to perform PAT on traffic destined for the remote VPN subnet.
  • Access Control (ACP): Create a rule allowing traffic from Local_Subnet to Remote_Subnet and vice-versa.

ASA to ASA (via CLI or we can also use ASDM)

The ASA uses a structured CLI approach. Configuration must be mirrored on both sides.

Step 1: Define Interesting Traffic (ACL)

access-list VPN-ACL extended permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0

Step 2: Phase 1 (IKEv2 Policy)

crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 14
 prf sha256
 lifetime seconds 86400
crypto ikev2 enable outside

Step 3: Phase 2 (IPSec Transform Set & Crypto Map)

crypto ipsec ikev2 ipsec-proposal MY-PROPOSAL
 protocol esp encryption aes-256
 protocol esp integrity sha-256

crypto map OUTSIDE-MAP 10 match address VPN-ACL
crypto map OUTSIDE-MAP 10 set peer 192.168.100.10  # Remote Public IP
crypto map OUTSIDE-MAP 10 set ikev2 ipsec-proposal MY-PROPOSAL
crypto map OUTSIDE-MAP interface outside

Step 4: Tunnel Group (Authentication)

tunnel-group 192.168.100.10 type ipsec-l2l
tunnel-group 192.168.100.10 ipsec-attributes
 ikev2 local-authentication pre-shared-key MySecretKey
 ikev2 remote-authentication pre-shared-key MySecretKey

Step 5: NAT Exemption

nat (inside,outside) source static LOCAL-NET LOCAL-NET destination static REMOTE-NET REMOTE-NET

Verification Commands

To confirm the tunnel is active, use these CLI commands on either platform:

  • show crypto ikev2 sa: Verifies if Phase 1 is “Ready” or “Up”.
  • show crypto ipsec sa: Verifies if Phase 2 is encrypting/decrypting packets.
  • packet-tracer: Use the Cisco Packet Tracer tool to simulate a packet and see where it hits a drop or an encryption phase.

IKEv1 Troubleshooting Logs

IKEv1 uses specific states to indicate where the negotiation is failing.

  • MM_WAIT_MSG2 (Initiator stuck): The firewall sent the first packet (Phase 1 policy) but got no response.
    • Cause: Routing issues, peer is down, or a firewall is blocking UDP 500/4500.
  • MM_WAIT_MSG6 (Authentication): The tunnel fails at the final step of Phase 1.
    • Cause: Almost always a Pre-Shared Key (PSK) mismatch.
  • NO_PROPOSAL_CHOSEN: The local and remote firewalls don’t have matching encryption or hash settings.
    • Solution: Compare Phase 1 policies (AES, SHA, DH Group) and ensure at least one matches perfectly. 

IKEv2 Troubleshooting Logs

IKEv2 is more streamlined but uses “Notify” codes to signal errors.

  • AUTHENTICATION_FAILED: The peers couldn’t verify each other.
    • Cause: Mismatched PSKs or a mismatch in the IKE ID (e.g., one side expects an IP, the other sends a hostname).
  • TS_UNACCEPTABLE (Traffic Selector): Phase 1 is up, but the data tunnel (Phase 2) failed.
    • Cause: The local protected network does not match the remote’s “interesting traffic” ACL. If you use 10.1.1.0/24, the peer must have a mirror rule for 10.1.1.0/24.
  • INVALID_ID_INFORMATION: A failure during the Phase 2 negotiation.
    • Cause: Often caused by Proxy ID (subnet) mismatches between different vendors (e.g., ASA to Palo Alto). 

General “Standard” Errors (Both Versions)

  • Peer is not responsive - Declaring peer dead: The tunnel was up but dropped.
    • Cause: DPD (Dead Peer Detection) timed out due to ISP instability or the remote device rebooting.
  • NAT-T Errors: If the firewall is behind a NAT device, ensure UDP 4500 is open.
  • QM_IDLE (IKEv1 only): This is the success state. If you see this, Phase 1 is perfect and the issue is likely in Phase 2 or routing. 

Top Verification Commands

Run these in the CLI to see real-time status:

  1. show crypto ikev2 sa (or isakmp sa for v1): Check if the state is READY or stuck.
  2. show crypto ipsec sa: Look for “pkts encaps/decaps.” If one is 0, traffic is one-way.
  3. debug crypto ike-common 10: High-level debugging to see the handshake fail in real-time

Happy Labinggggggggggggggg …!