IKEv1 vs IKEv2 on the ASA: Migrating a Site-to-Site Tunnel

Most site-to-site VPNs running in production today were built on IKEv1, and a lot of them are still there because "if it isn't broken, don't touch it." But IKEv1 is a 1998-era protocol, and IKEv2 replaces it with faster negotiation, built-in dead-peer detection, cleaner rekeying, and a few capabilities IKEv1 simply cannot express. On a Cisco ASA the migration is mostly a rename exercise: the same tunnel, the same interesting traffic, expressed with IKEv2 syntax. This article maps IKEv1 to IKEv2 piece by piece using real configuration from a CML lab, then shows how to cut a live tunnel over without an outage. It sits in the PingLabz Cisco ASA series alongside the broader IPsec VPN collection.

The topology is the same one from our LAN-to-LAN IKEv2 walkthrough: FW1 is an ASAv 9.24(1) at 203.0.113.10 protecting 10.20.10.0/24, and the peer is a cat8000v at 198.51.100.2 fronting 10.30.10.0/24. That IKEv2 tunnel is the end state of this migration, so if you want to see the finished, verified result first, read that one and come back.

The Same Tunnel, Two Protocols

Start with what IKEv1 looks like on the ASA. Here is a valid IKEv1 Phase 1 policy for the same tunnel, shown for contrast.

crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 14
 lifetime 86400

It is compact and readable, and it carries the seeds of why people migrate. Look at authentication pre-share: in IKEv1 the authentication method is a property of the policy itself, and both peers must use the same method in the same direction. There is no prf line, because IKEv1 derives keying material with the negotiated hash rather than a separate pseudo-random function. And hash sha here means SHA-1, the default that ships with legacy configs and that modern security baselines want gone.

The IKEv2 form of that exact Phase 1, from the working lab, looks like this.

crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 14
 prf sha256

Same encryption, same DH group, but now integrity is SHA-256, and there is a dedicated prf sha256. Authentication is gone from the policy entirely, because IKEv2 moves it out to the tunnel group, where it can be set per direction. That relocation is the single most important structural difference and the reason the migration is worth doing carefully rather than blindly search-and-replacing.

The Migration Map

Every IKEv1 construct on the ASA has an IKEv2 counterpart. Migrating the tunnel is a matter of translating each piece, keeping the interesting-traffic ACL and the peer address identical. Here is the mapping used in the lab.

The crypto ACL and the peer statement do not change. That is the reassuring part: the definition of what to encrypt and where to send it is protocol-agnostic. What changes is how the two peers authenticate and negotiate, which is contained in the policy, the proposal, and the tunnel-group attributes.

What IKEv2 Actually Buys You

If IKEv2 were only a rename, nobody would bother. The migration is worth the change window because IKEv2 fixes real limitations. Three of them show up directly in the configuration.

Split local and remote authentication. This is the headline. In IKEv1 the authentication pre-share line applies to both peers, in one direction, and both must match. IKEv2 breaks authentication into two independent statements: ikev2 remote-authentication (what you require from the peer) and ikev2 local-authentication (what you present). Because they are separate, the two ends can use different methods. You can present a certificate while the far end presents a pre-shared key, which is impossible in IKEv1. In the lab both are set to the same PSK for simplicity, but the machinery for asymmetric authentication is right there in the syntax. The IKEv2 explained guide walks through why the exchange was redesigned this way.

A dedicated PRF. IKEv2 adds prf, the pseudo-random function used to derive keying material, as its own negotiated parameter. IKEv1 reused the integrity hash for key derivation. Separating them lets you, for example, run a strong PRF while tuning integrity independently, and it removes the implicit coupling that made IKEv1 harder to reason about.

ipsec-proposal instead of transform-set. The Phase 2 construct is renamed and restructured. IKEv1 uses a transform-set; IKEv2 uses an ipsec-proposal with explicit protocol esp encryption and protocol esp integrity sub-commands. Beyond the syntax, IKEv2 negotiates child SAs more efficiently and supports multiple proposals more cleanly. On top of these, IKEv2 brings built-in liveness checks (a standardized dead-peer detection rather than an IKEv1 add-on), fewer messages to establish a tunnel, and resistance to certain denial-of-service patterns that plagued IKEv1's aggressive mode.

Cutting Over a Live Tunnel

The risk in any migration is the outage between "old tunnel down" and "new tunnel up." On the ASA you avoid that by building the IKEv2 side alongside the IKEv1 side and moving the peer, rather than ripping out IKEv1 first. The sequence looks like this.

1. Add the IKEv2 building blocks without touching IKEv1. Configure crypto ikev2 policy 10, the crypto ipsec ikev2 ipsec-proposal PLZ-PROP, and crypto ikev2 enable outside. None of this disturbs the running IKEv1 tunnel, because nothing references it yet.
2. Add IKEv2 authentication to the existing tunnel group. Under tunnel-group 198.51.100.2 ipsec-attributes, add the ikev2 remote-authentication and ikev2 local-authentication pre-shared keys. The IKEv1 PSK can stay in place during the transition.
3. Point the crypto map entry at the IKEv2 proposal. Change set ikev2 ipsec-proposal PLZ-PROP on crypto map sequence 10. The moment both peers prefer IKEv2 and can negotiate it, the next SA formation uses IKEv2.
4. Coordinate the far end. IKEv1 and IKEv2 do not interoperate with each other, so both peers must be ready for IKEv2 at cutover. Prepare EDGE2's IKEv2 keyring and profile in parallel, then clear the SA or let it rekey to force the switch.
5. Verify, then remove IKEv1. Once the tunnel is confirmed on IKEv2, delete the IKEv1 policy, transform-set, and PSK to close the door on a fallback you no longer want.

If you are also weighing whether to keep classic crypto maps at all during a refresh, that is a separate and worthwhile decision. Our comparison of crypto maps versus VTI covers when a route-based tunnel is the better long-term target than the policy-based crypto map shown here.

Proving the Cutover Took

The whole point of a careful migration is being able to prove, not assume, that the tunnel is now IKEv2. The ASA makes this trivial. After cutover, the session summary labels the live tunnel by IKE version.

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%

IKEv2 IPsec is the line that closes the ticket. If this still read as an IKEv1 session, the cutover had not taken and the crypto map or the peer was still preferring the old protocol. Because the ASA aggregates the IKE version, the crypto parameters, and the traffic counters in the VPN session database, one command tells you both which protocol is live and whether data is flowing over it. The full show vpn-sessiondb detail l2l output, with the IKEv2 and IPsec halves side by side, is broken down in the LAN-to-LAN IKEv2 article.

Migration Pitfalls to Plan For

A few things trip people up on the ASA specifically, and knowing them ahead of the change window saves an emergency rollback.

IKEv1 and IKEv2 do not fall back to each other. This is the one that catches teams mid-cutover. If FW1 is offering IKEv2 and the far end is still only IKEv1, the tunnel does not "downgrade," it simply fails to form. There is no graceful degradation between the two protocols. That is why coordinating both peers is a hard requirement, not a nicety. Schedule the change with whoever owns the remote device and confirm they are ready before you clear the SA.

Do not forget both authentication directions. Because IKEv2 split the PSK into remote-authentication and local-authentication, engineers migrating from the single IKEv1 pre-shared-key line sometimes configure only one of the two. The tunnel then fails during authentication with no obvious reason, because the policy negotiated fine. When you translate the IKEv1 key, always write both IKEv2 lines even when the value is identical.

Leave the crypto ACL and NAT exemption alone. The interesting-traffic ACL and any no-NAT (NAT exemption) statements protecting the VPN traffic are protocol-agnostic. Touching them during an IKE migration adds an unrelated failure domain. Change only the IKE and IPsec constructs; leave the traffic definition and NAT policy exactly as they were.

Watch your lifetimes and SHA-1. Legacy IKEv1 configs frequently carry hash sha (SHA-1) and default lifetimes. A migration is the natural moment to move integrity to SHA-256, as the lab does, and to review the Phase 1 and Phase 2 lifetimes rather than blindly copying the old 86400-second values. The two rekey timers are independent under IKEv2, so set them deliberately.

Plan the cutover during a maintenance window, keep the IKEv1 configuration in place until the IKEv2 tunnel is verified, and only then remove it. That way your rollback is a single crypto map change away for as long as you need it.

Key Takeaways

• The migration is a translation, not a redesign: policy, transform-set to ipsec-proposal, enable, tunnel-group PSK, and crypto map binding each have a direct IKEv2 equivalent. The crypto ACL and peer statement do not change.
• IKEv2's big win is split authentication: remote-authentication and local-authentication are separate, so the two ends can use different methods (PSK one way, certificates the other), which IKEv1 cannot do.
• IKEv2 adds a PRF and restructures Phase 2: a dedicated pseudo-random function and the ipsec-proposal replace IKEv1's reused hash and transform-set.
• Cut over without an outage: build the IKEv2 pieces alongside IKEv1, add IKEv2 auth to the tunnel group, point the crypto map at the IKEv2 proposal, coordinate the far end, verify, then remove IKEv1. The two protocols do not interoperate, so both peers must be ready at the same time.
• Prove it with show vpn-sessiondb summary: the IKEv2 IPsec label is documentary proof the tunnel migrated off IKEv1.

Keep going: the Cisco ASA pillar links every ASA lab, the IPsec VPN hub covers the protocol end to end, and the IKEv2 explained guide unpacks the exchange you just migrated to.