Site-to-site IPsec VPN on the Cisco ASA is the most common way to interconnect two offices, a branch and headquarters, or a corporate network and a cloud VPC. The ASA has supported it since the PIX days, and the configuration model has evolved through three generations: classic IKEv1 with crypto maps (legacy), IKEv2 with crypto maps (current default), and route-based VTI (newer, route-aware). This article focuses on the current default - IKEv2 with crypto maps - because it is what 90% of production ASA tunnels use today, with one section on VTI for engineers who want the route-based model.
It is part of the Cisco ASA Complete Guide. Adjacent reads: Troubleshoot Cisco ASA IPsec VPN Phase 1 and Phase 2, Cisco ASA VPN NAT Exemption: The Mistake That Breaks Tunnels, and the modern remote-access VPN counterparts: AnyConnect SSL VPN and AnyConnect IKEv2 VPN.
What the Tunnel Does
A site-to-site IPsec VPN encrypts traffic between two sites so it can traverse an untrusted network (typically the internet) safely. The ASA at each end is configured with a peer (the remote ASA's public IP), an authentication method (pre-shared key or digital certificate), and a list of "interesting traffic" - the source/destination subnets that should be encrypted and sent through the tunnel.
When a packet matches interesting traffic, the ASA encrypts it and tunnels it to the peer. The peer decrypts and forwards. Two things make this work:
- The IKE control plane. Negotiates the encryption keys (Phase 1) and the security associations for the tunnel (Phase 2). IKEv2 is the modern protocol; IKEv1 is legacy.
- NAT exemption. Interesting traffic must NOT be PATted to the outside interface IP, or it will exit the firewall translated and the peer will reject it. Identity NAT in Section 1 keeps the traffic untranslated. We cover this in detail in the NAT exemption article.
IKEv2 Site-to-Site Walkthrough (Modern Default)
The minimal IKEv2 site-to-site config has six pieces: an IKEv2 policy, an IPsec proposal, a tunnel-group, a crypto map, NAT exemption, and the interesting-traffic ACL. Here it is end-to-end on the local ASA (peer 198.51.100.2):
! 1. IKEv2 policy (Phase 1 parameters)
crypto ikev2 policy 10
encryption aes-256
integrity sha256
group 14
prf sha256
lifetime seconds 86400
!
! Enable IKEv2 on the outside interface
crypto ikev2 enable outside
!
! 2. IPsec proposal (Phase 2 parameters)
crypto ipsec ikev2 ipsec-proposal AES256-SHA256
protocol esp encryption aes-256
protocol esp integrity sha-256
!
! 3. Tunnel-group (peer-specific config + auth)
tunnel-group 198.51.100.2 type ipsec-l2l
tunnel-group 198.51.100.2 ipsec-attributes
ikev2 remote-authentication pre-shared-key STRONG_SECRET
ikev2 local-authentication pre-shared-key STRONG_SECRET
!
! 4. Interesting-traffic ACL
object network LOCAL-LAN
subnet 10.10.10.0 255.255.255.0
object network REMOTE-LAN
subnet 10.20.0.0 255.255.255.0
!
access-list VPN-ACL extended permit ip object LOCAL-LAN object REMOTE-LAN
!
! 5. NAT exemption (must be Section 1 manual NAT)
nat (inside,outside) source static LOCAL-LAN LOCAL-LAN destination static REMOTE-LAN REMOTE-LAN no-proxy-arp route-lookup
!
! 6. Crypto map binding ACL + proposal + peer
crypto map OUTSIDE-MAP 10 match address VPN-ACL
crypto map OUTSIDE-MAP 10 set peer 198.51.100.2
crypto map OUTSIDE-MAP 10 set ikev2 ipsec-proposal AES256-SHA256
crypto map OUTSIDE-MAP 10 set security-association lifetime seconds 3600
!
crypto map OUTSIDE-MAP interface outsideRead it as a wiring diagram: outbound packets that match VPN-ACL (LOCAL-LAN to REMOTE-LAN) are matched by crypto map sequence 10, encrypted with the AES256-SHA256 proposal, and sent to peer 198.51.100.2. The peer authenticates with pre-shared key. NAT exemption keeps the source and destination untranslated.
The remote ASA is the mirror image: same IKEv2 policy and IPsec proposal, tunnel-group keyed on the local ASA's outside IP, ACL with source and destination flipped, NAT exemption mirrored, crypto map pointing at the local ASA. Both sides must agree on encryption parameters, otherwise Phase 1 or Phase 2 negotiation fails.
Verifying the Tunnel
The four most useful show commands once the config is in:
! Phase 1 - IKEv2 SA
ASA-PERIM# show crypto ikev2 sa
IKEv2 SAs:
Session-id:1, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
123456789 203.0.113.2/500 198.51.100.2/500 READY INITIATOR
Encr: AES-CBC, keysize: 256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/1234 sec
Child sa: local selector 10.10.10.0/0 - 10.10.10.255/65535
remote selector 10.20.0.0/0 - 10.20.0.255/65535
ESP spi in/out: 0xa1b2c3d4/0xe5f6a7b8
! Phase 2 - IPsec SA
ASA-PERIM# show crypto ipsec sa
interface: outside
Crypto map tag: OUTSIDE-MAP, seq num: 10, local addr: 203.0.113.2
access-list VPN-ACL extended permit ip 10.10.10.0/24 10.20.0.0/24
local ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.20.0.0/255.255.255.0/0/0)
current_peer: 198.51.100.2
#pkts encaps: 4521, #pkts encrypt: 4521, #pkts digest: 4521
#pkts decaps: 4118, #pkts decrypt: 4118, #pkts verify: 4118
...
! Verify tunnel is actively passing data (decaps/encaps incrementing)
ASA-PERIM# show vpn-sessiondb l2l
! What does my interesting-traffic ACL look like?
ASA-PERIM# show access-list VPN-ACLIf show crypto ikev2 sa shows Status: UP-ACTIVE and show crypto ipsec sa shows incrementing encaps and decaps counters, the tunnel is up and passing data. If encaps is incrementing but decaps is not, the local side is sending but the remote side is not (or the return is not coming back to you - check ACLs at the remote end). If decaps is incrementing but encaps is not, the local side is receiving but not sending - check the interesting-traffic ACL and NAT exemption.
Pre-Shared Key vs Certificate Authentication
| Method | Pros | Cons | Common use |
|---|---|---|---|
| Pre-shared key (PSK) | Trivial to configure, no PKI, works in 30 seconds | One leak compromises every tunnel using the same key, no automated rotation | Branch-to-HQ, partner extranet, lab |
| Certificate (RSA) | Per-peer trust, automated rotation possible, scales to many peers | Requires PKI infrastructure, cert lifecycle management | Enterprise hub-and-spoke with many spokes, security-sensitive deployments |
For two-site deployments, PSK is fine. For 50+ spokes, certificates pay back the PKI investment in operational hygiene. The configuration shape is similar: replace the pre-shared-key lines with ikev2 remote-authentication rsa-sig and ikev2 local-authentication certificate <trustpoint>, plus a trustpoint configuration that points at your CA.
Route-Based VPN: VTI
Modern ASA software (9.7+) supports Virtual Tunnel Interfaces (VTI), which give you a route-based VPN: the tunnel is a logical interface, you put routes through it, and any traffic that route-lookups to the VTI is encrypted. No interesting-traffic ACL, no NAT exemption.
! IPsec profile (replaces crypto map for VTI)
crypto ipsec profile VPN-PROFILE
set ikev2 ipsec-proposal AES256-SHA256
!
! Tunnel interface
interface Tunnel1
nameif vti-to-remote
ip address 169.254.1.1 255.255.255.252
tunnel source interface outside
tunnel destination 198.51.100.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPN-PROFILE
!
! Tunnel-group (same as crypto map case)
tunnel-group 198.51.100.2 type ipsec-l2l
tunnel-group 198.51.100.2 ipsec-attributes
ikev2 remote-authentication pre-shared-key STRONG_SECRET
ikev2 local-authentication pre-shared-key STRONG_SECRET
!
! Route remote LAN through the VTI
route vti-to-remote 10.20.0.0 255.255.255.0 169.254.1.2 1VTI is the modern clean model and pairs naturally with dynamic routing (you can run BGP or OSPF over the tunnel for failover and route exchange). For a fixed two-site deployment with no routing requirements, crypto map is still fine and is what most production ASAs use.
Common Mistakes
- Forgetting NAT exemption. The biggest single source of "tunnel is up but no traffic" tickets. Outbound packets get PATted to the outside interface IP before reaching the crypto map. The fix is identity NAT in Section 1. We dedicate a whole article to it: Cisco ASA VPN NAT Exemption.
- Mismatched encryption proposals. Both sides must agree on encryption, integrity, DH group, and lifetime. Tiny mismatches (SHA1 on one side, SHA256 on the other) cause Phase 1 or Phase 2 to fail to negotiate. Check both sides agree before debugging the tunnel state machine.
- ACL mismatch on local vs remote. The interesting-traffic ACLs must be exact mirrors. Local ACL says "permit 10.10.10.0/24 to 10.20.0.0/24", remote ACL must say "permit 10.20.0.0/24 to 10.10.10.0/24". A subnet mismatch (e.g., remote is /23 but local says /24) causes the tunnel to come up but only partial traffic to encrypt.
- No outside ACL allowing IKE/ESP. If your outside interface has a restrictive inbound ACL, you need to permit UDP/500 (IKE), UDP/4500 (NAT-T), and ESP (protocol 50) from the peer. Most engineers add this and forget when they later harden the perimeter.
- PSK on both sides differ. Phase 1 will fail authentication. Verify with
show crypto ikev2 sashowing AUTH_FAILED, and the remote side's logs. - Routing-table thinks the destination is somewhere else. If the inside router has a route to the remote subnet via a path that does not go through the ASA (a leftover EIGRP route, an old static), the inside hosts will route that way and never hit the firewall. Verify with traceroute from an inside host.
Related Articles
- Troubleshoot Cisco ASA IPsec VPN Phase 1 and Phase 2 - debug commands and the negotiation flow.
- Cisco ASA VPN NAT Exemption: The Mistake That Breaks Tunnels - the most common single failure mode.
- Cisco ASA AnyConnect SSL VPN Configuration - the remote-access counterpart.
- Cisco ASA AnyConnect IKEv2 VPN Configuration - the remote-access IKEv2 counterpart.
- Cisco ASA VPN Group Policies and Tunnel Groups - the abstraction underneath both site-to-site and remote-access.
- Cisco ASA packet-tracer Guide - the simulator that walks the encrypt/decrypt phases.
Key Takeaways
An ASA site-to-site IPsec VPN has six pieces of config: IKEv2 policy, IPsec proposal, tunnel-group, interesting-traffic ACL, NAT exemption, and crypto map (or VTI for the route-based model). IKEv2 with PSK and AES-256/SHA-256/DH-14 is the modern default for two-site deployments. Verify with show crypto ikev2 sa for Phase 1 and show crypto ipsec sa for Phase 2 (encaps and decaps counters incrementing means traffic is flowing). The single most common failure is forgetting NAT exemption: outbound traffic gets PATted to the outside interface IP before reaching the crypto map and the tunnel never carries it. VTI is the modern cleaner model when you want routing over the tunnel.
