LAN-to-LAN IPsec VPN on the ASA with IKEv2

If you have configured a site-to-site VPN on a Cisco router, the ASA version looks familiar until it doesn't. The crypto map is still there, the access list still defines interesting traffic, but the IKEv2 pieces carry ASA-specific names and the verification command you reach for on IOS returns almost nothing useful. This article walks a real LAN-to-LAN (L2L) IKEv2 tunnel from a Cisco ASA to a Cisco IOS XE peer, captured live in a CML lab, and shows you the one command that makes ASA VPN troubleshooting click: show vpn-sessiondb. It is part of the PingLabz Cisco ASA series and the broader IPsec VPN collection, so if you want the router-to-router foundation first, start with the ASA site-to-site VPN walkthrough.

The lab is simple on purpose. FW1 is an ASAv running 9.24(1), sitting on the outside at 203.0.113.10 with an inside network of 10.20.10.0/24 (host 10.20.10.100). EDGE2 is a cat8000v running IOS XE 17.18.02 at 198.51.100.2, with a loopback of 10.30.10.1/24 standing in for a branch LAN. The goal: encrypt traffic between 10.20.10.0/24 and 10.30.10.0/24 using IKEv2 with AES-256, SHA-256, and Diffie-Hellman group 14.

The ASA IKEv2 L2L Configuration

An IKEv2 site-to-site tunnel on the ASA has five moving parts: the IKEv2 policy (Phase 1 proposal), the IPsec proposal (Phase 2 transform), the tunnel group holding the pre-shared key, the crypto ACL defining interesting traffic, and the crypto map that binds it all to the outside interface. Here is the exact configuration from the lab.

crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 14
 prf sha256
crypto ikev2 enable outside
crypto ipsec ikev2 ipsec-proposal PLZ-PROP
 protocol esp encryption aes-256
 protocol esp integrity sha-256
access-list VPN-ACL extended permit ip 10.20.10.0 255.255.255.0 10.30.10.0 255.255.255.0
tunnel-group 198.51.100.2 type ipsec-l2l
tunnel-group 198.51.100.2 ipsec-attributes
 ikev2 remote-authentication pre-shared-key PingLabz-IKEv2-PSK-01
 ikev2 local-authentication pre-shared-key PingLabz-IKEv2-PSK-01
crypto map PLZ-CMAP 10 match address VPN-ACL
crypto map PLZ-CMAP 10 set peer 198.51.100.2
crypto map PLZ-CMAP 10 set ikev2 ipsec-proposal PLZ-PROP
crypto map PLZ-CMAP interface outside

Read it top to bottom. The crypto ikev2 policy 10 block is the Phase 1 (IKE_SA) proposal: how the two peers negotiate the secure channel. Notice the prf sha256 line, the pseudo-random function, which is unique to IKEv2 and has no equivalent in IKEv1. The crypto ipsec ikev2 ipsec-proposal PLZ-PROP block is Phase 2: how the actual data is protected inside the tunnel (ESP with AES-256 and SHA-256). The tunnel group is keyed by the peer IP (198.51.100.2) and holds the pre-shared key. And here is the first ASA quirk worth flagging: IKEv2 splits authentication into remote-authentication and local-authentication, so the key you present and the key you expect are configured separately (they happen to be the same here). That split is a real IKEv2 capability, not ASA boilerplate, and it is the foundation of asymmetric auth designs. If you want the protocol-level detail, the IKEv2 explained guide covers why the exchange is built this way.

The EDGE2 side is a standard IOS XE IKEv2 keyring plus an IKEv2 profile and a crypto map, matching the same proposal, PSK, and interesting-traffic definition. The two ends have to agree on encryption, integrity, DH group, and the traffic selectors, or the SA never forms.

ASA IKEv2 Pieces and Their IOS Equivalents

If you already know IOS site-to-site VPN, the fastest way to learn the ASA is to map each ASA command to the IOS construct it replaces. They do the same job under different names.

The one-to-one mapping is the point: an ASA site-to-site tunnel is not a different animal, it is the same IPsec state machine with ASA naming. Where the ASA genuinely diverges is verification.

Bringing the Tunnel Up

IPsec tunnels are on-demand. Nothing negotiates until interesting traffic arrives, so the cleanest test is to source real traffic from the branch LAN toward the HQ host. From EDGE2, ping the inside host at 10.20.10.100 sourced from the loopback that sits inside the protected 10.30.10.0/24 range.

EDGE2#ping 10.20.10.100 source Loopback10 repeat 5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/24 ms

Five exclamation marks, 100 percent success. Traffic sourced from 10.30.10.1 reached 10.20.10.100 across the encrypted tunnel and back. One detail from the capture worth internalizing: the very first attempt was only 2 of 5. That is not a fault, it is the SA negotiating while the first packets are already in flight. The IKE_SA exchange takes a moment to complete, a couple of early packets get dropped during setup, and then the tunnel is up and everything after it succeeds. If you script a health check, always send a second probe.

The Star of the Show: show vpn-sessiondb

Here is where IOS habits fail you. On a router, you would type show crypto session or show crypto ipsec sa and read the tunnel state. Those commands exist on the ASA too, but they are not where the ASA keeps the good information. The ASA aggregates the IKE half and the IPsec half of every VPN session, plus counters, rekey timers, and auth mode, into one database: the VPN session database. Query it with show vpn-sessiondb.

FW1# show vpn-sessiondb detail l2l
IKEv2:
  Tunnel ID    : 1.1
  UDP Src Port : 500                    UDP Dst Port : 500
  Rem Auth Mode: preSharedKeys
  Loc Auth Mode: preSharedKeys
  Encryption   : AES256                 Hashing      : SHA256
  Rekey Int (T): 86400 Seconds          Rekey Left(T): 86363 Seconds
  PRF          : SHA256                 D/H Group    : 14
IPsec:
  Tunnel ID    : 1.2
  Local Addr   : 10.20.10.0/255.255.255.0/0/0
  Remote Addr  : 10.30.10.0/255.255.255.0/0/0
  Encryption   : AES256                 Hashing      : SHA256
  Encapsulation: Tunnel
  Rekey Int (T): 28800 Seconds          Rekey Left(T): 28763 Seconds
  Bytes Tx     : 700                    Bytes Rx     : 952
  Pkts Tx      : 7                      Pkts Rx      : 7

Read this output like a two-story building. The IKEv2 block (Tunnel ID 1.1) is the control channel, Phase 1. It confirms the UDP 500 source and destination ports, that both ends used pre-shared keys (Rem Auth Mode and Loc Auth Mode, the remote/local split from the config made visible), AES256 with SHA256, DH group 14, and the pseudo-random function SHA256. The rekey line tells you the IKE_SA is good for 86400 seconds with 86363 left, meaning this session was established roughly 37 seconds ago.

The IPsec block (Tunnel ID 1.2) is the data channel, Phase 2. This is where the real proof lives. The local and remote address selectors match exactly what the crypto ACL defined: 10.20.10.0/24 to 10.30.10.0/24. Encapsulation is Tunnel mode, encryption AES256, hashing SHA256. And the counters are the money shot: Bytes Tx 700 / Bytes Rx 952 and Pkts Tx 7 / Pkts Rx 7. Seven packets each way is our ping (five echoes plus the couple that primed the SA), encrypted and decrypted. When someone claims a tunnel is up, these counters are how you prove data is actually moving through it, not just that Phase 1 negotiated.

Two things to note. First, the IKEv2 rekey (86400s, the IKE_SA lifetime) and the IPsec rekey (28800s, the child SA lifetime) are independent timers, which is exactly how IKEv2 is meant to work: the control channel and the data channel age out on their own schedules. Second, everything you would otherwise chase across three or four show crypto commands on IOS is here in one screen.

The Summary View

For a fast health read, or on a box terminating hundreds of tunnels, drop the detail keyword and ask for the summary.

FW1# show vpn-sessiondb summary
Site-to-Site VPN             :      1 :          1 :           1
  IKEv2 IPsec                :      1 :          1 :           1
Device Total VPN Capacity    :    250
Device Load                  :     0%

One site-to-site VPN, and the ASA labels its type explicitly: IKEv2 IPsec. That single line is doing quiet but important work. It is documentary proof of which IKE version the live tunnel actually negotiated. If you had migrated this tunnel from IKEv1, this is the line that confirms the cutover took (more on that in the companion migration article). The capacity and load fields also matter operationally: this ASAv supports 250 concurrent sessions and is currently at 0 percent, so you know your headroom at a glance.

When the Tunnel Will Not Form

Because the ASA hides the negotiation behind a clean session view, it helps to know where mismatches bite before they do. Every field in the show vpn-sessiondb detail l2l output above corresponds to something both peers had to agree on, and a disagreement on any one of them stalls the tunnel at a predictable point.

Phase 1 is symmetric: the ASA's crypto ikev2 policy (encryption AES-256, integrity SHA-256, DH group 14, PRF SHA-256) must have a matching proposal on EDGE2. If the two policies do not overlap, the IKE_SA never completes and show vpn-sessiondb shows nothing at all, because there is no session to display. That absence is itself a clue: no session object usually means Phase 1, not Phase 2. Point the pings at the far LAN, then check both ends of the IKEv2 policy line by line.

The pre-shared key is the next classic. Because IKEv2 splits authentication, a common mistake is fixing one direction and forgetting the other. The remote-authentication key is what you expect from the peer, and the local-authentication key is what you present. If EDGE2's keyring does not line up with both, the exchange fails during authentication and, again, no session appears. In the lab both keys are PingLabz-IKEv2-PSK-01, which is the simple symmetric case, but the split is there precisely so you can run different credentials each way.

Phase 2 is where the crypto ACL earns scrutiny. The ASA's access-list VPN-ACL defines interesting traffic as 10.20.10.0/24 to 10.30.10.0/24, and EDGE2's selectors must mirror it exactly (10.30.10.0/24 to 10.20.10.0/24 from its perspective). Mismatched or overly broad selectors are the most common reason a tunnel comes up but traffic does not flow, and the fingerprint is a session that exists with zero or lopsided packet counters. That is exactly why the Pkts Tx and Pkts Rx fields are worth reading every time: matching, non-zero counters in both directions mean the selectors agree and data is round-tripping. If Tx climbs but Rx stays at zero, your traffic is leaving encrypted and nothing is coming back, which points at the far end or the return-path routing rather than your own crypto.

Why This Command Matters

The teaching point is small but it separates people who fight the ASA from people who drive it. On IOS you build a mental model out of several show crypto commands. On the ASA, show vpn-sessiondb is the single pane of glass for every VPN type the box terminates: site-to-site L2L, remote-access AnyConnect (Secure Client), clientless (on older code), and L2TP. You filter it by type (l2l, anyconnect, remote) and add detail when you need the crypto parameters and counters. Learn this one command well and the ASA's VPN behavior stops being opaque.

That does not mean the show crypto family is useless on the ASA. show crypto ikev2 sa and show crypto ipsec sa still work and are handy for raw SPI and selector detail. But for a human-readable, aggregated, per-session view with auth mode, counters, and rekey timers in one place, show vpn-sessiondb wins.

Key Takeaways

• ASA IKEv2 L2L has five parts: the crypto ikev2 policy (Phase 1), the crypto ipsec ikev2 ipsec-proposal (Phase 2), the tunnel-group PSK, the crypto ACL, and the crypto map bound to the outside interface.
• The PSK is split: IKEv2 uses remote-authentication and local-authentication separately, so the two ends can even use different methods. That split shows up again in show vpn-sessiondb as Rem/Loc Auth Mode.
• Tunnels are on-demand: the first probe may be partial while the SA negotiates. A 100 percent second ping is normal, not a fix.
• Use show vpn-sessiondb, not show crypto session: the ASA aggregates the IKEv2 and IPsec halves, byte and packet counters, rekey timers, and auth mode into one view. The IPsec counters are how you prove data is really flowing.
• The summary labels the IKE version: IKEv2 IPsec in show vpn-sessiondb summary is your proof of what the tunnel actually negotiated.

Ready to go deeper? The Cisco ASA pillar indexes every ASA lab on PingLabz, the IPsec VPN hub covers the protocol from the ground up, and if you inherited a legacy tunnel, the next step is our guide on migrating an ASA site-to-site tunnel from IKEv1 to IKEv2.