Stackvora.tech

Site-to-Site IPsec VPN on ASA

Implement a robust site-to-site IPsec VPN on Cisco ASA using IKEv2. Covers Phase 1/2 negotiation, ACLs, NAT exemption, and common configuration pitfalls.

Establishing secure site-to-site connectivity is a fundamental requirement for distributed network architectures. Cisco Adaptive Security Appliances (ASAs) are widely deployed for this purpose, providing robust IPsec VPN capabilities. This guide focuses on configuring an IPsec VPN tunnel using Internet Key Exchange version 2 (IKEv2) on an ASA, ensuring secure and reliable communication between two network segments.

This article details the step-by-step configuration for both Phase 1 (IKEv2 negotiation) and Phase 2 (IPsec SA establishment), along with essential supporting configurations like access control lists (ACLs) and Network Address Translation (NAT) exemption, using ASA software version 9.x.

Understanding IPsec VPN Phases (IKEv2)

IPsec VPN operates in two distinct phases to establish a secure tunnel:

Phase 1: IKEv2 Negotiation (ISAKMP SA)

Phase 1 establishes a secure, authenticated channel (the IKE SA or ISAKMP SA) to protect the negotiation of Phase 2 parameters. Key elements configured in Phase 1 include:

  • Encryption Algorithm: How the IKE messages themselves are encrypted (e.g., AES-256).
  • Integrity Algorithm: How IKE message authenticity is ensured (e.g., SHA256).
  • Diffie-Hellman (DH) Group: Used to securely exchange keys (e.g., Group 14 for 2048-bit MODP).
  • Authentication Method: Pre-shared keys (PSKs) or digital certificates. PSKs are simpler for site-to-site.
  • Lifetime: How long the IKE SA remains valid before rekeying.

IKEv2 simplifies negotiation compared to IKEv1, often requiring fewer messages and supporting features like Dead Peer Detection (DPD) more efficiently.

Phase 2: IPsec SA Negotiation (Child SA)

Once Phase 1 is complete, Phase 2 negotiates the parameters for the actual IPsec Security Association (SA), which protects the user data. This includes:

  • Encryption Algorithm: For data payload (e.g., ESP-AES-256).
  • Integrity Algorithm: For data payload (e.g., ESP-SHA256-HMAC).
  • IPsec Mode: Tunnel mode (encapsulates original IP header) is standard for site-to-site.
  • PFS (Perfect Forward Secrecy): Optional, ensures compromise of one key doesn't compromise past keys. Achieved by using a new DH exchange for Phase 2.
  • Lifetime: How long the IPsec SA remains valid before rekeying. Often shorter than Phase 1.
  • Proxy IDs (Traffic Selectors): Define which local and remote networks will use the tunnel.

ASA Configuration: Phase 1 (IKEv2)

The first step is to define the IKEv2 policy. This policy dictates the cryptographic parameters for the Phase 1 negotiation. It's crucial that these parameters match on both VPN peers.

crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 14
 prf sha256
 lifetime seconds 86400
!
crypto ikev2 enable OUTSIDE
  • crypto ikev2 policy 10: Defines IKEv2 policy with a priority of 10. Lower numbers are preferred.
  • encryption aes-256: Uses AES with a 256-bit key for IKE message encryption. Other options include aes (128-bit) or 3des.
  • integrity sha256: Uses SHA256 for integrity checking of IKE messages. Other options include sha512, sha384, sha1, md5.
  • group 14: Specifies Diffie-Hellman group 14 (2048-bit MODP). Stronger groups like 19 (256-bit EC) or 20 (384-bit EC) offer higher security with similar or better performance.
  • prf sha256: Pseudo-Random Function for key derivation. Must match integrity.
  • lifetime seconds 86400: IKE SA lifetime of 24 hours.
  • crypto ikev2 enable OUTSIDE: Enables IKEv2 on the specified interface (e.g., OUTSIDE). This interface should be the one facing the internet and accessible by the remote peer.

ASA Configuration: Phase 2 (IPsec)

Phase 2 involves defining the IPsec transform set and the crypto map that ties everything together, including the traffic selectors (proxy IDs).

crypto ipsec ikev2 transform-set TRANSSET_AES256_SHA256 esp-aes-256 esp-sha256-hmac
 mode tunnel
!
access-list VPN_TRAFFIC extended permit ip 10.10.10.0 255.255.255.0 10.20.20.0 255.255.255.0
!
crypto map OUTSIDE_MAP 10 match address VPN_TRAFFIC
crypto map OUTSIDE_MAP 10 set peer 198.51.100.1
crypto map OUTSIDE_MAP 10 set ikev2 transform-set TRANSSET_AES256_SHA256
crypto map OUTSIDE_MAP 10 set security-association lifetime seconds 3600
crypto map OUTSIDE_MAP 10 set pfs group 14
!
crypto map OUTSIDE_MAP interface OUTSIDE
  • crypto ipsec ikev2 transform-set TRANSSET_AES256_SHA256 esp-aes-256 esp-sha256-hmac: Defines the transform set named TRANSSET_AES256_SHA256. It specifies AES-256 for data encryption and SHA256 for data integrity. The esp prefix indicates Encapsulating Security Payload (ESP).
  • mode tunnel: Specifies tunnel mode, which is standard for site-to-site VPNs.
  • access-list VPN_TRAFFIC extended permit ip 10.10.10.0 255.255.255.0 10.20.20.0 255.255.255.0: This access list acts as the traffic selector (or proxy ID). It defines which traffic is encrypted and sent over the VPN. In this example, traffic from 10.10.10.0/24 (local network) destined for 10.20.20.0/24 (remote network) will use the tunnel. Crucially, this ACL should mirror on both sides; the local network on one side is the remote network on the other.
  • crypto map OUTSIDE_MAP 10 match address VPN_TRAFFIC: Links the traffic selector ACL to the crypto map entry.
  • crypto map OUTSIDE_MAP 10 set peer 198.51.100.1: Specifies the public IP address of the remote VPN peer.
  • crypto map OUTSIDE_MAP 10 set ikev2 transform-set TRANSSET_AES256_SHA256: Associates the Phase 2 transform set with the crypto map.
  • crypto map OUTSIDE_MAP 10 set security-association lifetime seconds 3600: Sets the IPsec SA lifetime to 1 hour (3600 seconds). This is generally shorter than Phase 1 lifetime for security best practices.
  • crypto map OUTSIDE_MAP 10 set pfs group 14: Enables Perfect Forward Secrecy (PFS) using DH group 14 for Phase 2 rekeys. Recommended for enhanced security.
  • crypto map OUTSIDE_MAP interface OUTSIDE: Applies the crypto map to the specified interface.

ASA Configuration: Tunnel Group and Authentication

The tunnel group defines peer-specific parameters, most importantly the authentication method.

tunnel-group 198.51.100.1 type ipsec-l2l
tunnel-group 198.51.100.1 ipsec-attributes
 ikev2 remote-authentication pre-shared-key MyStrongSecretPSK123!
 ikev2 local-authentication pre-shared-key MyStrongSecretPSK123!
!
  • tunnel-group 198.51.100.1 type ipsec-l2l: Creates a tunnel group for the remote peer's public IP address, specifying it's an IPsec LAN-to-LAN (L2L) connection.
  • ikev2 remote-authentication pre-shared-key MyStrongSecretPSK123!: The pre-shared key the ASA expects from the remote peer.
  • ikev2 local-authentication pre-shared-key MyStrongSecretPSK123!: The pre-shared key the ASA will present to the remote peer. These keys must be identical on both sides.

ASA Configuration: NAT Exemption (No NAT)

Traffic intended for the VPN tunnel should bypass NAT, as it's already secured and shouldn't be translated to the ASA's outside IP address.

nat (INSIDE,OUTSIDE) source static INSIDE_NET INSIDE_NET destination static REMOTE_NET REMOTE_NET no-proxy-arp route-lookup
  • nat (INSIDE,OUTSIDE) source static INSIDE_NET INSIDE_NET destination static REMOTE_NET REMOTE_NET no-proxy-arp route-lookup: This is a typical bi-directional NAT exemption rule.
  • INSIDE_NET should be an object or object-group representing your local subnet (e.g., object network INSIDE_NET subnet 10.10.10.0 255.255.255.0).
  • REMOTE_NET should be an object or object-group representing the remote subnet (e.g., object network REMOTE_NET subnet 10.20.20.0 255.255.255.0).
  • no-proxy-arp is often included to prevent the ASA from responding to ARP requests for the remote network, which is generally not desired in site-to-site scenarios.
  • route-lookup (ASA 9.x+) instructs the ASA to perform a route lookup before applying NAT rules, which can be useful for complex routing scenarios. Ensure this NAT rule is placed before any general outbound NAT rules that might catch VPN traffic.

ASA Configuration: Routing

The ASA needs a route to the remote VPN subnet pointing towards the VPN peer. However, for route-lookup in NAT exemption, or if you plan to use dynamic routing over the tunnel (beyond the scope of this article), a static route pointing to the remote network via the OUTSIDE interface is often required.

route OUTSIDE 10.20.20.0 255.255.255.0 198.51.100.1 1

This static route tells the ASA that to reach 10.20.20.0/24, traffic should be sent out the OUTSIDE interface, towards the VPN peer's IP address (198.51.100.1). The last number (1) is the metric.

Verification Commands

After configuration, verify the tunnel status:

  • show crypto ikev2 sa: Displays IKEv2 Security Associations (Phase 1). Look for a READY or UP status.
  • show crypto ipsec sa: Displays IPsec Security Associations (Phase 2). Check for active SAs and incrementing packet counters.
  • show vpn-sessiondb detail l2l: Provides comprehensive details about L2L VPN sessions.
  • show nat detail: Verify your NAT exemption rule hit count.
  • ping <remote_VPN_host> (from local network behind ASA): Initiate traffic to bring up the tunnel.
  • clear crypto ikev2 sa and clear crypto ipsec sa: Used to reset the VPN connection for troubleshooting.

Common Pitfalls

  • Mismatching Parameters: The most frequent cause of VPN failure. Ensure all Phase 1 and Phase 2 parameters (encryption, integrity, DH group, PSK, lifetimes) match exactly on both peers.
  • Incorrect Proxy IDs (VPN Traffic ACL): The local network on ASA A must be the remote network on ASA B in the access list, and vice versa. If these are incorrect, traffic will not be encrypted.
  • NAT Exemption Issues: VPN traffic being NAT'd to the outside interface instead of being encrypted. Ensure the NAT exemption rule is correctly defined and positioned (before general outbound NAT).
  • Missing or Incorrect Routes: The ASA needs a route to the remote subnet. If the route points to the wrong interface or next-hop, traffic will not reach the tunnel.
  • Firewall Rules: Ensure access rules on the ASA (access-group) permit the VPN traffic in both directions (e.g., from INSIDE to OUTSIDE for the remote subnet and vice-versa). By default, IPSec bypasses inspection, but the interfaces still need appropriate access rules.
  • IKEv2 vs IKEv1 Mismatch: Ensure both peers are configured for IKEv2. Some older devices might only support IKEv1.
  • Interface Activation: Forgetting to enable crypto ikev2 enable <interface_name> and crypto map <map_name> interface <interface_name>.

Back to the knowledge base · Ask the AI assistant