← Back To List

Cisco: site-to-site IPsec VPN with IKEv2


Internet Key Exchange Version 2 (IKEv2) provides built-in support for Dead Peer Detection (DPD) and Network Address Translation-Traversal (NAT-T), plus other advantages over IKEv1.

With time, more and more business will use IKEv2 instead of v1.

Follow below steps to create a Site-to-Site VPN tunnel with IKEv2 on Cisco Router.


Step1. Create proposal

crypto ikev2 proposal ikev2-proposal-3des-sha256
 encryption 3des
 integrity sha256
 group 21 14 5 2
crypto ikev2 proposal ikev2-proposal-aes256-sha256
 encryption aes-cbc-256
 integrity sha256
 group 21 14 5

Proposal is a collection of transforms used in the negotiation of Internet Key Exchange (IKE) security associations (SAs) as part of the IKE_SA_INIT exchange, which is in the control plane, not data plane.

We can specify a list of parameters in each encryption/integrity/group.

Step2. Create policy

crypto ikev2 policy ikev2-policy1
 proposal ikev2-proposal-3des-sha256
 proposal ikev2-proposal-aes256-sha256

A proposal need to be attached in a policy to take effect.

Note that you can add as many proposals as you want. The SA negotiation will automatically compare and match with one of the proposals.

Also note that an IKEv2 policy is not explicitly used in any IKEv2 profile or any other places in the configuration (see discussion after).

Step3. Create Key Ring

crypto ikev2 keyring keyring-ikev2
 peer test-mumbai
  address [IP of the GW in Mumbai region]
  pre-shared-key SomeSecretCode
 peer test-chicago
  address xxx.xxx.xxx.xxx
  pre-shared-key SomeOtherSecretCode

IKEv2 key ring is a repository of symmetric and asymmetric preshared keys and is independent of the IKEv1 key ring. The IKEv2 key ring is associated with an IKEv2 profile.

Step4. Create Profile

crypto ikev2 profile ikev2-profile-default
 match identity remote any
 identity local fqdn example.com
 authentication remote pre-share
 authentication local pre-share
 keyring local keyring-ikev2
 dpd 30 2 on-demand

An IKEv2 profile is a repository of nonnegotiable parameters of the IKE SA, such as local or remote identities and authentication methods and services that are available to authenticated peers that match the profile.

An IKEv2 profile must be attached to either a crypto map or an IPsec profile on the initiator. An IKEv2 profile is not mandatory on the responder.

In the above example, I created a default IKEv2 profile, and set remote identity as “any”, so that I can reuse the same profile for multiple IKEv2 peers in the crypto map.

To create a specific profile for a remote peer, configure the unique remote identity in “match identity remote [xxxx]”, it can be IP address, email, fqdn, and key-id.

Step5. Add profile to crypto map

crypto map mymap 38 ipsec-isakmp
 set peer [IP of the GW in Mumbai region]
 set transform-set vpn-sha256-aes256
 set pfs group14
 set ikev2-profile ikev2-profile-default
 match address MUMBAI

The prerequisites is that there is already definition of “transform-set” and extended access-list.

crypto ipsec transform-set vpn-sha256-aes256 esp-aes 256 esp-sha256-hmac
 mode tunnel

ip access-list extended MUMBAI
 10 permit ip host [local host IP] host [remote host IP]


Use below commands to verify the VPN status and traffic.

# Displays the state of the phase 1 Security Association (SA).
show crypto ikev2 sa

# Displays the state of the phase 2 SA.
show crypto ipsec sa

# verify if the Security Parameter Index (SPI) has been negotiated correctly
show crypto ipsec sa peer [peer's IP] | i spi

# confirm whether traffic flows across the tunnel
show crypto ipsec sa peer [peer's IP] | i pkts 

Side-by-Side comparison of IKEv1 and IKEv2 configuration


You may wonder this question:

Why IKEv2 policy is not referred in other parts of the configuration?

You are not alone. I found a discussion on cisco forum that shed some lights on it.

When creating an IKEv2 policy, I instinctively want to go for a name including peer’s identity, e.g “ikev2-policy-MUMBAI” refer to the peer in AWS Mumbai region. However, it does not work as expected because there is no reference of this policy name in other part of the configuration that binds this policy to a specific peer.

Meanwhile, there is an bizarre optional “match address local [local IP]” which allows for the selection of a specific policy based on the local address of the negotiating Security Association (SA) during the initial exchange. But why do I want to define a local address? Maybe when the router has multiple outside-facing interfaces and it’s useful to bind a specific policy to one of the interface? I still think it makes more sense to define a remote address in this case.

In conclusion, when you create a IKEv2 policy, you are just adding a new set of proposals into a policy pool, and you don’t know which policy will be used for a specific peer, it’s just automatically matched.

So naming-wise, I will just give a generic name like “ikev2-policy1”. And when I need to configure a new VPN, I will check the existing policies to decide if I need to create a new policy or to just add a new proposal to an existing policy.

In fact, IKEv1 policy also has no way to be bound with a specific peer, instead they are matched automatically by the order of policy ID. But since IKEv2 is implemented later, I think Cisco could have made improvements to the configuration options.

It’s logical to have an option like “match remote address [peer’s GW IP]” command, which makes it clear that this policy is to define the proposals agreed with this specific peer. But as of now, it’s not a reality.

IKEv2 Defaults

Cisco comes with “IKEv2 Smart Defaults feature”.

Using “show crypto ikev2 proposal default” will show the default proposal, and using “show crypto ikev2 proposal” will show default plus user defined proposals.

#show crypto ikev2 proposal default
 IKEv2 proposal: default
     Encryption : AES-CBC-256
     Integrity  : SHA512 SHA384
     PRF        : SHA512 SHA384
     DH Group   : DH_GROUP_256_ECP/Group 19 DH_GROUP_2048_MODP/Group 14 DH_GROUP_521_ECP/Group 21 DH_GROUP_1536_MODP/Group 5

As you can imagine, there is default configuration for IKEv2 policy as well.

#show crypto ikev2 policy default
 IKEv2 policy : default
      Match fvrf : any
      Match address local : any
      Proposal    : default

Guess what, there is no default IKEv2 profile 🙂


Creating a site-to-site IPsec VPN with IKEv2 on Cisco router is quite simple. But I wish Cisco can improve the policy matching mechanism to give user more precise control over the policy selection.





← Back To List