In the first article, we discussed general concepts regarding IKEv2 and looked at some of the IKEv2 components on the Cisco IOS. In this article, we will configure a normal LAN-to-LAN (L2L) VPN between two Cisco IOS routers but, instead of using IKEv1, we will use IKEv2.

The topology we will be using is shown below:

We will be building a VPN tunnel between R1 and R2 to protect the LAN subnets – 192.168.10.0/24 and 192.168.20.0/24. I will be using Loopback interfaces to represent those LAN subnets. The basic configuration on the routers is as follows:

hostname R1
!
interface Loopback0
 ip address 192.168.10.1 255.255.255.0
interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.0
!
ip route 192.168.20.0 255.255.255.0 10.0.0.2
hostname R2
!
interface Loopback0
 ip address 192.168.20.2 255.255.255.0
interface Ethernet0/0
 ip address 10.0.0.2 255.255.255.0
!
ip route 192.168.10.0 255.255.255.0 10.0.0.1

Now let’s begin with the VPN configuration. In the last article, I told you that Cisco has what it calls IKEv2 smart defaults and we will make use of those defaults here. There are five default IKEv2 components, but only three are relevant to us in this article: default IKEv2 proposal, default IKEv2 policy, and default IPsec transform-set:

Note: These defaults are also in the running configuration but you need to use the show running-config all command to see them.

As you can see from above, the default IKEv2 proposal has three encryption algorithms, five integrity (and PRF) algorithms, and two DH groups. The algorithms are configured in an order of priority with the more secure ones listed first. The default proposal is attached to the default IKEv2 policy. Finally, we have a default IPsec transform-set, which uses AES and SHA algorithms.

With these smart defaults, our work has been reduced. We only have to configure the IKEv2 profile and IKEv2 key ring (since we will be using pre-shared keys).

crypto ikev2 keyring R1-R2-KEYS
 peer R2
  address 10.0.0.2
  pre-shared-key cisco
 !
crypto ikev2 profile R1-R2-PROFILE
 match identity remote address 10.0.0.2 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local R1-R2-KEYS

In the configuration above, I have configured a PSK of “cisco” and this is the key that will be configured on both peers. Later in this article, we will configure both peers to use different PSK keys.

We can now configure the other aspects of the VPN, such as the crypto map and ACL to match interesting traffic:

ip access-list extended R1-R2-ACL
 permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255
!
crypto map R1-R2-CRYPTO-MAP 10 ipsec-isakmp
 set peer 10.0.0.2
 set ikev2-profile R1-R2-PROFILE
 match address R1-R2-ACL
!
interface Ethernet0/0
 crypto map  R1-R2-CRYPTO-MAP

Notice that I have not set a transform-set under the crypto map configuration. If you specify the command “set transform-set default” under the crypto map, you will get an error “transform set with tag ‘default’ cannot be configured as it is a default transform-set name.” Therefore, to use the default transform-set, just don’t configure it; it will be used automatically.

For completeness’ sake, the configuration for the R2 is as follows:

crypto ikev2 keyring R1-R2-KEYS
 peer R1
  address 10.0.0.1
  pre-shared-key cisco
 !
crypto ikev2 profile R1-R2-PROFILE
 match identity remote address 10.0.0.1 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local R1-R2-KEYS
!
ip access-list extended R2-R1-ACL
 permit ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255
!
crypto map R1-R2-CRYPTO-MAP 10 ipsec-isakmp
 set peer 10.0.0.1
 set ikev2-profile R1-R2-PROFILE
 match address R2-R1-ACL
!
interface Ethernet0/0
 crypto map  R1-R2-CRYPTO-MAP

To test our configuration, I will ping from R1’s Lo0 interface to R2’s Lo0 interface.

Cool! Our ping test was successful. We can use some show commands to verify that the traffic is indeed being encrypted. We will start with the show crypto ikev2 sa command (similar to show crypto isakmp sa):

From the output above, we see the most secure transform (based on the default IKEv2 proposal) has been negotiated: AES-CBC-256, SHA512 and DH Group 5.

We can also use the show crypto ikev2 session command to view information about active IKEv2 sessions (including information about the child SA):

Finally, we have the show crypto ipsec sa command, where we can see the packets encrypted/decrypted and also see the transform-set being used (in our case, the default transform-set is used):

Before we end this article, I will like to show you how to configure asymmetric PSK to authenticate peers. We will configure R1 to use a PSK of “cisco1” while R2 uses a PSK of “cisco2.” As we will see, even though the PSKs are not the same, authentication will still be successful.

To implement this, we just need to make some changes to the IKEv2 keyring configuration. On R1, the configuration is as follows:

crypto ikev2 keyring R1-R2-KEYS
 peer R2
  no pre-shared-key cisco
  pre-shared-key local cisco1
  pre-shared-key remote cisco2
 !

The configuration change on R2 is as follows:

crypto ikev2 keyring R1-R2-KEYS
 peer R1
  no pre-shared-key cisco
  pre-shared-key local cisco2
  pre-shared-key remote cisco1
 !

Side talk: I was thinking that since I am configuring the keyring for a peer (e.g., peer R2 configured on R1), the “pre-shared-key local” should be that of the peer, but I guess Cisco wanted to keep things simple: ‘local’ means the device you are configuring on and ‘remote’ means the peer.

I will clear the SAs and then initiate the ping again. As you can see, the SAs were formed and the ping is successful.

Summary

In this article, we have configured an L2L VPN between two Cisco IOS routers using IKEv2 with PSK authentication. We made use of the default IKEv2 proposal, default IKEv2 policy and also the default IPsec transform-set. We also configured asymmetric PSK and saw that the VPN tunnel was still formed.

In the next article, we will use debug outputs to see the behind-the-scene process of how IKEv2 works, including the messages it makes use of.

I hope you have found this article insightful and I look forward to writing the next article in the series.

References and Further Reading