Cisco: site-to-site IPsec VPN with IKEv2
Introduction
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.
Configuration
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 5Proposal 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-sha256A 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 SomeOtherSecretCodeIKEv2 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-demandAn 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 MUMBAIThe 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]Verify
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
Discussion
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 5As 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 : defaultGuess what, there is no default IKEv2 profile 🙂
Conclusion
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.
References
https://www.cisco.com/c/en/us/support/docs/ip/internet-key-exchange-ike/117258-config-l2l.html
https://community.cisco.com/t5/vpn/how-to-select-crypto-ikev2-policy/td-p/4037826