IKEv2 Site-to-Site VPN with Crypto Maps on IOS XE

You have a site-to-site VPN in production. It works. It has worked for years. It uses a crypto map, an ISAKMP policy, a pre-shared key, and a transform set, and the last time anybody touched it was during a maintenance window nobody wants to repeat. Now someone has read an audit report and wants IKEv2, or wants AES-GCM, or wants the tunnel to stop dropping every time the far side reboots. And the internet keeps telling you the answer is to rip the whole thing out and rebuild it as a virtual tunnel interface.

You do not have to. On Cisco IOS XE you can keep the crypto map, keep the crypto ACL, keep the transform set, keep the interface binding, and swap only the key exchange. One line inside the crypto map entry is the entire migration. This article walks the real config and the real output from our lab: a HUB at 203.0.113.1 and SPOKE1 at 198.51.100.2, both cat8000v running 17.18.02, protecting 10.20.10.0/24 to 10.30.10.0/24. If you want the wider context first, the IPsec VPN pillar covers how the pieces fit together, and the IKEv1 version of this exact build is the thing we are migrating from.

The IKEv2 Config Anatomy

IKEv2 is not IKEv1 with a bigger version number. It is a different protocol with a different configuration model, and the object names do not line up cleanly with what you already know. Four constructs do the work. Two of them have obvious IKEv1 ancestors. Two of them are new, and one of those new ones is the piece that everything hangs off.

The mental shift is that in IKEv1 the pieces were global and loosely coupled (a policy floated in space, a key floated in space, and IOS did its best to pair them at negotiation time). In IKEv2 the profile is a container that explicitly binds a peer identity to an authentication method to a keyring. Nothing is implicit. That is more typing, and it is also why IKEv2 fails loudly instead of silently doing the wrong thing.

The Full HUB Config

Here is the working configuration from the lab, verbatim. SPOKE1 is the mirror image of this: swap the peer address to 203.0.113.1, swap the local identity to 198.51.100.2, and reverse the source and destination in the crypto ACL.

crypto ikev2 proposal PLZ-IKEV2-PROP
 encryption aes-gcm-256
 prf sha256
 group 19
crypto ikev2 policy PLZ-IKEV2-POL
 proposal PLZ-IKEV2-PROP
crypto ikev2 keyring PLZ-KEYRING
 peer SPOKE1
  address 198.51.100.2
  pre-shared-key PingLabz-IKEv2-PSK-01
crypto ikev2 profile PLZ-IKEV2-PROF
 match identity remote address 198.51.100.2 255.255.255.255
 identity local address 203.0.113.1
 authentication local pre-share
 authentication remote pre-share
 keyring local PLZ-KEYRING
crypto ipsec transform-set PLZ-TS-GCM esp-gcm 256
 mode tunnel
crypto map PLZ-CMAP 10 ipsec-isakmp
 set peer 198.51.100.2
 set transform-set PLZ-TS-GCM
 set ikev2-profile PLZ-IKEV2-PROF
 match address PLZ-CRYPTO-ACL
interface GigabitEthernet2
 crypto map PLZ-CMAP

Look at the bottom half of that config. The transform set, the crypto map, the match address pointing at a crypto ACL, the crypto map statement on the outside interface: all of it is exactly what you already run for IKEv1. The top half is new. The joint between them is a single line.

The One Line That Is the Whole Migration

crypto map PLZ-CMAP 10 ipsec-isakmp
 set ikev2-profile PLZ-IKEV2-PROF

That is it. set ikev2-profile inside the crypto map entry tells IOS XE to negotiate this SA pair with IKEv2 instead of IKEv1. The keyword ipsec-isakmp on the crypto map line is a historical artifact and stays exactly as it was (do not go looking for an ipsec-ikev2 variant, there is not one). Everything else in the map is untouched.

Which means the migration on a live tunnel looks like this. Build the four IKEv2 objects (they are inert until something references them, so you can stage them safely during business hours). Then in your maintenance window, add one line to the crypto map entry, coordinate with the far end, and clear the SA. The crypto ACL does not change. The transform set does not have to change (though if you are doing this at all, you may as well move to GCM while you are here). The interface binding does not change. Routing does not change, because with a crypto map there was never any routing to change.

AES-GCM Needs a PRF and No Integrity

The first time you type the proposal, IOS will print this at you:

IKEv2 proposal MUST either have a set of an encryption algorithm other than aes-gcm, an
integrity algorithm and a DH group configured or
 encryption algorithm aes-gcm, a prf algorithm and a DH group configured

This is not an error and the config is not rejected. It is a validation hint that IOS prints while the proposal is incomplete, and it disappears once the proposal has everything it needs. But it is telling you something real, so read it properly.

An IKEv2 proposal has to be one of two shapes. Either you use a classic cipher (AES-CBC, say) and you must configure an integrity algorithm plus a DH group. Or you use AES-GCM and you must configure a PRF plus a DH group, and you must NOT configure an integrity algorithm. The reason is that GCM is an AEAD cipher (Authenticated Encryption with Associated Data). It performs encryption and integrity in a single pass, using the GHASH function internally. Bolting an HMAC on top would be dead weight: extra bytes on every packet, extra CPU, zero extra security.

The PRF is still needed, because the pseudo-random function is what derives the keying material from the Diffie-Hellman shared secret. In IKEv1 (and in non-GCM IKEv2) the integrity algorithm doubled as the PRF, which is why you never had to think about it. With GCM there is no integrity algorithm to borrow, so you name the PRF explicitly. In our proposal that is prf sha256.

The Tunnel Is Up. Proving It.

This is where most IKEv1 muscle memory betrays you, so start with the right command.

HUB#show crypto ikev2 sa detailed
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         203.0.113.1/500       198.51.100.2/500      none/none            READY
      Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:19, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/6 sec
      CE id: 1001, Session-id: 1
      Local spi: 006A65307FBECC85       Remote spi: E0055D1CB14CC870
      Status Description: Negotiation done
      Local id: 203.0.113.1
      Remote id: 198.51.100.2
      Local req msg id:  2              Remote req msg id:  0
      Local next msg id: 2              Remote next msg id: 0
      Local window:      5              Remote window:      5
      DPD configured for 0 seconds, retry 0
      Fragmentation not  configured.
      Dynamic Route Update: enabled
      Extended Authentication not configured.
      NAT-T is not detected
      Initiator of SA : Yes
      PEER TYPE: IOS-XE

Read that output line by line, because almost every field is a thing you configured and can now verify.

The IKE SA only proves the two routers agreed on how to talk. The traffic itself rides in a child SA, and that is where the crypto ACL turns into something concrete:

Child sa:
          local selector       ->      remote_selector
          10.20.10.0/0 - 10.20.10.255/65535    ->    10.30.10.0/0 - 10.30.10.255/65535
          ESP spi in/out: 0xDC114E8E/0x854355BF
          Encr: AES-GCM, keysize: 256, esp_hmac: None
          ah_hmac: None, comp: IPCOMP_NONE, mode tunnel

Those local and remote selectors are IKEv2's name for what IKEv1 called proxy IDs, and they came directly from your crypto ACL: 10.20.10.0/24 to 10.30.10.0/24, ports and protocols wide open. If the two ends of a crypto-map VPN have mismatched ACLs, this is where you see it, as a selector that does not look like what you expected. Note esp_hmac: None again, for the same AEAD reason.

READY, Not QM_IDLE (The False Alarm That Gets Everyone)

Here is the failure mode that generates more panicked tickets than any actual IKEv2 bug. Someone migrates a tunnel, then reaches for the command they have typed ten thousand times:

HUB#show crypto isakmp sa

And it shows nothing useful. No peer. No QM_IDLE. The engineer concludes the tunnel is down, opens a P1, and starts rolling back a change that was working perfectly.

The tunnel was never down. show crypto isakmp sa displays IKEv1 security associations. An IKEv2 tunnel does not create one, so there is nothing for that command to display. The IKE SA you built lives in a different table, and you get to it with show crypto ikev2 sa.

One command that works for both, and the one you should reach for first when you do not know which flavour a tunnel is running, is show crypto session. It reports UP-ACTIVE regardless of IKE version and tells you the peer, the flow, and the packet counters. Learn that habit and the QM_IDLE reflex stops costing you outages.

Identity Matching Is Where IKEv2 Configs Die

Two lines in the profile deserve more attention than the rest of the config put together:

crypto ikev2 profile PLZ-IKEV2-PROF
 match identity remote address 198.51.100.2 255.255.255.255
 identity local address 203.0.113.1

match identity remote is a selector. When an IKE_AUTH exchange arrives, IOS looks at the identity the peer asserted and walks its IKEv2 profiles looking for one that matches. If a profile matches, that profile's authentication methods and keyring are used. If no profile matches, the negotiation is dropped. There is no fallback, no default profile, no "close enough". The peer's IP address being right in your keyring is not sufficient, because the keyring is only consulted after a profile has already been selected.

identity local is the other half: it is the identity this router asserts about itself. The far end will run its own match identity remote against exactly this value. In our lab the HUB asserts 203.0.113.1 and SPOKE1's profile carries match identity remote address 203.0.113.1 255.255.255.255. The two must agree.

This is the number one IKEv2 configuration failure, and it is easy to trip over in ways that look nothing like an identity problem:

• Multiple exit interfaces. If you do not set identity local, the router asserts the IP of whichever interface the packet leaves through. Change the routing, change the identity, break the tunnel.
• NAT in the path. The peer asserts its pre-NAT identity, but you configured match identity remote address using the post-NAT address you see in the packet's source field. Those are different values, and the match fails.
• FQDN on one side, address on the other. A peer configured with identity local fqdn will never match your match identity remote address, however correct the addressing is. The identity type has to line up, not just the value.
• Overlapping profiles. Two profiles, one with a specific address match and one with a wildcard, and the wrong one wins. Order and specificity matter.

The symptom in every one of these cases is the same: authentication fails, or the tunnel simply never comes up, and the SA table is empty. The diagnostic is debug crypto ikev2, where you will see the identity the peer actually sent and can compare it against what you told the profile to expect. Nine times out of ten the two strings are visibly different and the fix takes ten seconds. For a fuller treatment of how the exchange works, see IKEv2 explained.

Be Honest: This Is Still a Legacy Design

Swapping the key exchange gives you IKEv2's real benefits. Better crypto negotiation. AEAD ciphers. A 24-hour SA lifetime. Built-in DPD (liveness checks are part of the protocol rather than a bolt-on). Anti-DoS cookies. Cleaner rekey behaviour that does not black-hole traffic mid-negotiation. Those are worth having, and you got them for one line of config.

What you did not get is a better VPN architecture. A crypto map with IKEv2 is still a crypto map, and it still carries every structural limitation it always had:

• One IPsec SA pair per crypto ACL line. Ten subnets on each side means a lot of ACEs and a lot of SAs, and the two ends must agree on every one of them.
• No routing protocols across the tunnel. There is no interface to run OSPF or BGP on. Every remote subnet is a manual ACL edit on both routers, forever.
• No interface counters. You cannot show interface the tunnel, cannot graph it in your NMS, cannot apply QoS to it in the obvious way, and cannot use interface state as a routing signal.
• No tunnel to fail over. Redundancy means peer lists and reverse route injection rather than a routing protocol reconverging in a second.

So treat this migration as what it is: a low-risk, high-value stepping stone. It buys you modern crypto today without a redesign, and it teaches you the IKEv2 object model (proposal, policy, keyring, profile) on config you already understand. When you have that, the profile you just built is the exact same profile a virtual tunnel interface consumes, so the next move is short. Our IKEv2 SVTI configuration walk-through takes this same lab and reattaches PLZ-IKEV2-PROF to a tunnel interface instead, and crypto maps versus VTI lays out why that is where you want to end up.

Key Takeaways

• The migration is one line. set ikev2-profile PLZ-IKEV2-PROF inside the crypto map entry is what makes a crypto map negotiate with IKEv2. The crypto ACL, transform set, and interface binding are unchanged from the IKEv1 build, and the map line still ends in ipsec-isakmp.
• Four objects, one that matters. Proposal (was ISAKMP policy), policy (new), keyring (was ISAKMP key), and profile (new, and the one everything attaches to).
• AES-GCM takes a PRF and no integrity algorithm. GCM is AEAD, so it authenticates internally. IOS prints a validation hint saying so, and Hash: None in the SA is the confirmation, not a problem.
• READY, not QM_IDLE. show crypto isakmp sa shows nothing for an IKEv2 tunnel. Use show crypto ikev2 sa, or use show crypto session, which works for both.
• Identity is explicit and is what the profile keys off. match identity remote and identity local have to line up on both sides, in type as well as value. Mismatched identity is the single most common IKEv2 failure.
• Crypto maps are still legacy. Better key exchange, same structural limits: SA pairs per ACL line, no routing protocols, no interface counters. Use this to modernise safely, then move to a VTI.

Where this fits in the wider picture, including transform sets, NAT traversal, and the phase model this all sits on top of, is covered in the IPsec VPN pillar. All configuration and output above is from a live CML lab: HUB and SPOKE1 on cat8000v 17.18.02.