How to Set Up Site-to-Site VPNs on Cisco ASA Firewalls: IKEv1 and IKEv2 Configuration

Site-to-site VPN is the quiet workhorse connecting branch offices, data centers, and partner networks over the public internet as if they shared a private wire. Cisco ASA has supported this for decades through IPsec, evolving from IKEv1 to the more modern and more capable IKEv2. This guide covers both, how they differ, and how to build a resilient, correctly-troubleshot site-to-site tunnel between two ASAs.

IPsec and IKE Fundamentals

Site-to-site VPN on ASA relies on the IPsec protocol suite, with IKE (Internet Key Exchange) handling the key negotiation and security association setup before any actual encrypted traffic flows. Understanding the phases matters enormously for troubleshooting:

• IKE Phase 1 — the two peers authenticate each other and negotiate a secure channel (the ISAKMP/IKE SA) used to protect subsequent negotiation. This can run in Main Mode (6 messages, more secure/verbose, standard for site-to-site) or Aggressive Mode (3 messages, faster but exposes more information, generally discouraged for security-conscious deployments).
• IKE Phase 2 — using the secure Phase 1 channel, the peers negotiate the actual IPsec SAs that will encrypt real traffic, defining transform sets (encryption/hashing algorithms) and the traffic selectors (which subnets get encrypted).

IKEv1 vs. IKEv2 — IKEv2 is not just “IKEv1 version 2,” it’s a redesigned protocol: fewer message exchanges, built-in NAT-T and dead peer detection (DPI) support, better resistance to DoS during negotiation, native support for asymmetric authentication (different auth methods per side), and generally simpler, more robust behavior. New deployments should default to IKEv2 unless a specific legacy requirement forces IKEv1.

Planning Before Configuration

Before touching the CLI, both sides need agreement on:

• Peer public IP addresses (or dynamic DNS-based identity, for dynamic-IP peers)
• Pre-shared key or certificate-based authentication
• Phase 1 parameters — encryption, hash, DH group, lifetime
• Phase 2 parameters — transform set (encryption/hash for actual data), PFS group if used
• Interesting traffic — the exact source/destination subnet pairs that should be encrypted (crypto ACL)
• NAT exemption — internal-to-internal VPN traffic must not be NAT’d if it would break subnet matching, so NAT exemption rules are required for VPN traffic even if you NAT other outbound traffic

Configuring Site-to-Site VPN with IKEv2 (Recommended)

Step 1: Enable IKEv2 on the Outside Interface

enable
configure terminal
crypto ikev2 enable outside

Step 2: Define the IKEv2 Policy (Phase 1 parameters)

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

Step 3: Define the IPsec Proposal (Phase 2 parameters)

crypto ipsec ikev2 ipsec-proposal AES256-SHA256
 protocol esp encryption aes-256
 protocol esp integrity sha-256

Step 4: Define Interesting Traffic (Crypto ACL)

object network LOCAL-NET
 subnet 10.1.1.0 255.255.255.0
object network REMOTE-NET
 subnet 10.2.1.0 255.255.255.0

access-list VPN-TO-BRANCH2 extended permit ip object LOCAL-NET object REMOTE-NET

Step 5: NAT Exemption

nat (inside,outside) source static LOCAL-NET LOCAL-NET destination static REMOTE-NET REMOTE-NET no-proxy-arp route-lookup

Step 6: Configure the Tunnel Group (Peer Identity and PSK)

tunnel-group 198.51.100.10 type ipsec-l2l
tunnel-group 198.51.100.10 ipsec-attributes
 ikev2 remote-authentication pre-shared-key MyStrongSharedKey123!
 ikev2 local-authentication pre-shared-key MyStrongSharedKey123!

Step 7: Create the Crypto Map and Bind It

crypto map OUTSIDE-MAP 10 match address VPN-TO-BRANCH2
crypto map OUTSIDE-MAP 10 set peer 198.51.100.10
crypto map OUTSIDE-MAP 10 set ikev2 ipsec-proposal AES256-SHA256
crypto map OUTSIDE-MAP 10 set pfs group14
crypto map OUTSIDE-MAP interface outside

PFS (Perfect Forward Secrecy) forces a fresh Diffie-Hellman exchange for Phase 2 independent of the Phase 1 key material — a security best practice worth enabling, at a small computational cost.

Step 8: Mirror the Configuration on the Peer ASA

The remote-side ASA needs the mirror image — swapped local/remote subnets, swapped peer IP, matching PSK, and matching Phase 1/Phase 2 parameters. IKE negotiation will fail if the two sides don’t agree on proposed encryption/hash/DH parameters, so keep these identical on both ends.

Configuring Site-to-Site VPN with IKEv1 (Legacy)

Still common in older deployments or when interoperating with third-party gear that hasn’t been upgraded:

crypto isakmp enable outside
crypto isakmp policy 10
 authentication pre-share
 encryption aes-256
 hash sha256
 group 14
 lifetime 86400

crypto ipsec transform-set TS-AES256-SHA esp-aes-256 esp-sha-hmac

tunnel-group 198.51.100.10 type ipsec-l2l
tunnel-group 198.51.100.10 ipsec-attributes
 pre-shared-key MyStrongSharedKey123!

access-list VPN-TO-BRANCH2 extended permit ip object LOCAL-NET object REMOTE-NET

crypto map OUTSIDE-MAP 10 match address VPN-TO-BRANCH2
crypto map OUTSIDE-MAP 10 set peer 198.51.100.10
crypto map OUTSIDE-MAP 10 set transform-set TS-AES256-SHA
crypto map OUTSIDE-MAP 10 set pfs group14
crypto map OUTSIDE-MAP interface outside

Note IKEv1’s crypto isakmp policy versus IKEv2’s crypto ikev2 policy — the commands are structurally similar but not interchangeable, and mixing them on the same tunnel is not how a peer relationship is defined (each peer/tunnel picks one IKE version).

Verification

Check Phase 1 (IKE SA) Status

show crypto ikev2 sa

Expected healthy output:

IKEv2 SA Database
Session-id: 1, Status: ESTABLISHED, IKE count: 1, CHILD count: 1
Local: 203.0.113.1/500  Remote: 198.51.100.10/500  ...

For IKEv1:

show crypto isakmp sa

Check Phase 2 (IPsec SA) Status

show crypto ipsec sa

Look for non-zero pkts encaps/pkts decaps counters — Phase 2 SA existing but zero packet counts usually indicates the tunnel is up but no traffic is actually being routed into it (a routing or interesting-traffic ACL mismatch, not a crypto negotiation problem).

Confirm Interesting Traffic Actually Triggers the Tunnel

packet-tracer input inside icmp 10.1.1.5 8 0 10.2.1.5

This simulates a packet and shows exactly which policy/route/crypto map decision it would hit — extremely useful for validating without needing live production traffic.

Real-World Deployment Scenario

Scenario: A company with a headquarters and three branch offices needs full-mesh-equivalent connectivity for file sharing and VoIP, but wants to avoid the O(n²) complexity of a literal full mesh as they add branches.

Design:

• Hub-and-spoke topology — HQ ASA acts as the hub with a site-to-site tunnel to each branch; branches don’t tunnel directly to each other, but route branch-to-branch traffic through HQ (simpler key/policy management, centralized traffic visibility, at the cost of extra hop latency for branch-to-branch traffic).
• IKEv2 used throughout for better NAT-T handling (two branches sit behind ISP-provided NAT devices) and DPD-based fast failure detection.
• Each tunnel uses AES-256/SHA-256/DH Group 14 with PFS enabled, consistent across all peers to simplify policy auditing.
• Redundancy consideration: HQ ASA pair is in Active/Standby failover (see our dedicated ASA HA guide) so a hardware failure at HQ doesn’t take down the entire hub-and-spoke VPN mesh.
• Route-based supplementary consideration: where supported, using VTI (Virtual Tunnel Interface) instead of pure crypto-map/policy-based VPN simplifies routing (OSPF/BGP can run over the tunnel interface directly) versus manually maintaining crypto ACLs per subnet pair as the network grows.

Common Configuration Mistakes

• Mismatched Phase 1 or Phase 2 parameters between peers (different DH groups, different encryption/hash algorithms) — negotiation fails silently from an end-user perspective, showing up only in debug crypto output.
• Overlapping IP subnets between sites — a classic branch-office VPN killer; two sites both using 192.168.1.0/24 internally cannot establish meaningful routing without NAT gymnastics.
• Forgetting NAT exemption, causing VPN traffic to get NAT’d before it reaches the crypto engine, breaking the subnet match against the crypto ACL.
• Asymmetric crypto ACLs — one side’s “permit” statement doesn’t exactly mirror the other’s expected source/destination, causing Phase 2 to fail to establish even though Phase 1 succeeds.
• Using Aggressive Mode with PSK on IKEv1 for convenience — this is considerably weaker against offline attacks than Main Mode and should be avoided for anything beyond legacy compatibility necessity.
• No Dead Peer Detection tuning, leaving a tunnel showing “up” in the SA table long after the actual remote peer has become unreachable, delaying failover to a backup path if one exists.

Troubleshooting Site-to-Site VPN

debug crypto ikev2 protocol 127
debug crypto ikev2 platform 127
show crypto ikev2 sa detail
show crypto ipsec sa
clear crypto ikev2 sa
clear crypto ipsec sa

clear crypto ikev2 sa and clear crypto ipsec sa are commonly used to force renegotiation after a config change — a stale SA won’t automatically pick up new parameters without a clear or a natural lifetime expiration.

Security Best Practices

• Use IKEv2 for new deployments — better negotiation efficiency, native NAT-T, stronger DoS resistance during negotiation.
• Avoid Aggressive Mode PSK on IKEv1 wherever Main Mode is viable.
• Use strong pre-shared keys (long, random, unique per peer) or move to certificate-based authentication for larger deployments where PSK management becomes an operational burden.
• Enable PFS on Phase 2 to limit the blast radius of any future key compromise.
• Enable and tune Dead Peer Detection so failures are detected within a reasonable window rather than relying purely on SA lifetime expiration.
• Avoid weak DH groups (Group 1/2) and weak hash algorithms (MD5, SHA-1) in new deployments — use Group 14+ and SHA-256 or better as a baseline.
• Document crypto ACLs and NAT exemptions together — they’re tightly coupled and a common source of configuration drift when one side gets updated without the other during a subnet change.

Performance Tuning

• Right-size the crypto ACL scope — overly broad “any-any” style crypto ACLs (where legitimate) can pull unintended traffic into the tunnel, adding unnecessary encryption overhead; scope to actual required subnet pairs.
• Consider VTI-based route-based VPN over traditional policy-based (crypto-map) VPN for topologies with many subnets or growing routing complexity — it lets dynamic routing protocols handle reachability instead of manually maintained ACL entries per subnet pair, and scales operationally much better as sites and subnets are added.
• Monitor IPsec SA rekey behavior — very short lifetimes cause frequent renegotiation overhead; very long lifetimes reduce cryptographic hygiene. A balance around industry-standard defaults (commonly measured in hours, not days) is typical unless compliance requirements dictate otherwise.

Frequently Asked Questions

Should I use IKEv1 or IKEv2 for a new site-to-site VPN? IKEv2, unless a specific peer device only supports IKEv1. IKEv2 is more efficient, more secure by design, and has native support for features IKEv1 needed vendor-specific workarounds for (like NAT-T and DPD).

What causes a tunnel to show “up” but pass zero traffic? Almost always a NAT exemption or routing issue, not a crypto/negotiation problem — the Phase 1/Phase 2 SAs can be perfectly healthy while traffic simply never gets routed into the tunnel in the first place. packet-tracer and checking encaps/decaps counters are the fastest way to isolate this.

Can I have overlapping subnets between two sites in a site-to-site VPN? Not without significant NAT complexity layered into the VPN design — the cleanest fix is always non-overlapping addressing during network design; retrofitting NAT-over-VPN for overlapping subnets is achievable but adds real operational complexity.

What’s the difference between policy-based (crypto map) and route-based (VTI) site-to-site VPN? Policy-based VPN uses a crypto ACL to define exactly which traffic gets encrypted, tied to a crypto map. Route-based VPN (VTI) creates a virtual tunnel interface that any routed traffic can traverse based on the routing table, allowing dynamic routing protocols to run over the tunnel — generally simpler to scale for complex, multi-subnet, multi-site topologies.

How do I tell if a Phase 1 failure is due to a PSK mismatch versus a parameter mismatch? debug crypto ikev2 protocol output typically distinguishes between authentication failures (PSK/certificate mismatch) and proposal negotiation failures (no matching encryption/hash/DH combination) — read the debug output carefully rather than guessing, since the fix differs completely between the two.

Summary

Site-to-site VPN on Cisco ASA comes down to getting both IKE phases to agree — matching Phase 1 authentication and crypto parameters, matching Phase 2 transform sets, and mirrored interesting-traffic definitions on both peers — combined with correct NAT exemption and routing so negotiated tunnels actually carry real traffic. IKEv2 should be the default choice for new deployments given its efficiency and security improvements over IKEv1, and disciplined verification (show crypto ikev2 sa, show crypto ipsec sa, packet-tracer) turns what can feel like an opaque negotiation process into a methodical, diagnosable one. Build it with PFS, strong algorithms, and DPD from the start, and a site-to-site tunnel becomes exactly what it should be: an invisible, reliable extension of your private network.

References

• Cisco ASA Series VPN Configuration Guide — Site-to-Site IPsec VPNs: https://www.cisco.com/c/en/us/td/docs/security/asa/index.html
• Cisco IKEv2 and IPsec Configuration Guide
• Cisco ASA Command Reference (crypto ikev2, crypto isakmp, crypto map commands)
• RFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2)