Configuring a secure site-to-site connection between two corporate networks requires modern cryptographic protocols that prioritize speed, resilience, and cryptographic strength. Upgrading from legacy IKEv1 to Internet Key Exchange version 2 (IKEv2) on Cisco ASA firewalls eliminates handshake inefficiencies and provides built-in mobility and multihoming support. If you manage perimeter security, implementing this protocol correctly ensures your branch offices communicate without vulnerability windows.
This guide walks through the exact CLI configuration steps, architectural requirements, NAT exemption rules, and verification commands needed to establish an operational tunnel. You'll learn how to configure policies, proposals, crypto maps, and tunnel groups while avoiding common misconfigurations that stall production traffic.
Architectural Prerequisites and Planning
Before entering configuration commands on your Cisco ASA, you must map out the network parameters. A mismatch in Phase 1 or Phase 2 parameters will cause the negotiation to fail silently or throw cryptic error codes in the logging buffer.
You need the following parameters ready:
- Public IP addresses of both local and remote ASA security appliances.
- Internal subnet ranges behind each firewall (for example, 192.168.1.0/24 locally and 10.50.0.0/16 remotely).
- A robust, pre-shared key (PSK) shared securely with the remote network administrator.
- Software version compatibility: Cisco ASA code must run version 8.4.1 or later to support the necessary crypto syntax for modern IKEv2 policies.
For official documentation on foundational security parameters, consult the Cisco ASA Configuration Guide.
Step 1: Configuring IKEv2 Policies and Enabling Services
Phase 1 negotiation parameters are established using global IKEv2 policies. These policies dictate how the firewalls authenticate each other and establish a secure management channel.
Enter global configuration mode and define your policy parameters:
crypto ikev2 policy 10
encryption aes-256
integrity sha256
group 20
prf sha256
lifetime seconds 86400
Next, you must explicitly enable IKEv2 on your outside (internet-facing) interface:
crypto ikev2 enable outside
The pseudo-random function (PRF) defined as sha256 ensures that key derivation is cryptographically sound, matching modern security compliance frameworks.
Step 2: Defining Interesting Traffic and NAT Exemption
The ASA relies on access control lists (ACLs) to determine which packets require IPsec protection. Traffic matching this ACL is considered "interesting traffic" and triggers the tunnel build.
First, define network object groups for your local and remote subnets:
object-group network local-network
network-object 192.168.1.0 255.255.255.0
object-group network remote-network
network-object 10.50.0.0 255.255.255.0
Create the extended access list referencing these object groups:
access-list vpn-traffic extended permit ip object-group local-network object-group remote-network
If your ASA performs dynamic PAT or NAT on outbound traffic, you must configure an identity NAT (NAT exemption) rule. Without this, your local traffic will be translated before encryption, causing the remote peer to drop the packets:
nat (inside,outside) source static local-network local-network destination static remote-network remote-network no-proxy-arp route-lookup
Step 3: Configuring Phase 2 IPsec Proposals and Crypto Maps
Phase 2 handles the actual data encryption transport. You must define an IPsec proposal that matches the remote peer's configuration.
Create the proposal and specify the ESP encryption and integrity algorithms:
crypto ipsec ikev2 ipsec-proposal vpn-proposal
protocol esp encryption aes-256
protocol esp integrity sha-256
Now, create the crypto map entry, tie it to the access list, define the remote peer IP address, and attach the proposal:
crypto map outside-map 1 match address vpn-traffic
crypto map outside-map 1 set peer 203.0.113.50
crypto map outside-map 1 set ikev2 ipsec-proposal vpn-proposal
crypto map outside-map 1 set pfs group20
Finally, bind the crypto map globally to your outside interface:
crypto map outside-map interface outside
Step 4: Setting Up Tunnel Groups and Pre-Shared Keys
The tunnel group configuration defines how the remote peer is identified and authenticated. For a site-to-site architecture, use the ipsec-l2l type.
tunnel-group 203.0.113.50 type ipsec-l2l
tunnel-group 203.0.113.50 ipsec-attributes
ikev2 local-authentication pre-shared-key SuperSecretKey123!
ikev2 remote-authentication pre-shared-key SuperSecretKey123!
Ensure that the pre-shared key matches character-for-character on the peer device. Mismatched keys will result in immediate authentication failures during the IKEv2 exchange.
Common Configuration Mistakes
Even experienced network engineers occasionally hit roadblocks when deploying IPsec tunnels. Watch out for these frequent errors:
- Asymmetric Crypto Maps: If the encryption proposals, Diffie-Hellman groups, or transform sets do not mirror each other across both firewalls, Phase 2 will fail.
- Missing NAT Exemption: Forgetting the
no-proxy-arpor identity NAT rule is the single most common reason a tunnel stays up, but passes zero user data. - MTU and Fragmentation Issues: If large packets drop across the tunnel, adjust your TCP maximum segment size or enable IKEv2 fragmentation commands.
Verification and Troubleshooting
Once configurations are applied on both ends, generate interesting traffic by pinging a host on the remote subnet from your local network.
Verify the status of your security associations using these CLI commands:
show crypto ikev2 sa
show crypto ipsec sa
Review the output to confirm that both the IKEv2 SA (Phase 1) and IPsec SA (Phase 2) show active states with matching packet encapsulation and decapsulation counters. For further protocol diagnostics, review the Cisco Security Advisories to stay updated on vulnerability patches.
Frequently Asked Questions
Can I run IKEv1 and IKEv2 concurrently on the same Cisco ASA?
Yes. You can configure separate tunnel groups and crypto policies to handle legacy IKEv1 peers alongside modern IKEv2 endpoints, though migrating entirely to IKEv2 is recommended for enhanced security.
Why is my tunnel showing active in Phase 1 but passing no traffic?
This typically points to a Phase 2 mismatch or a missing NAT exemption rule on one of the firewalls. Check your access lists and identity NAT statements.
Do I need a special license for IKEv2 site-to-site VPNs on an ASA?
Standard site-to-site IPsec functionality requires no specialized premium crypto licenses on modern ASA software, unlike remote-access AnyConnect client limitations.
How do I clear stuck security associations during testing?
Use the command clear crypto ikev2 sa followed by clear crypto ipsec sa to force the firewalls to tear down existing states and re-negotiate a fresh tunnel.
