Note: This is the first of two tutorials on IKEv2.
Cisco is recommending that customers switch their VPN solutions to use Internet Key Exchange version 2 (IKEv2) wherever possible. IKEv2 is a next-generation key management protocol based on RFC 4306. This tutorial discusses the IKEv2 pre-shared changes that some companies need to be aware of, depending on the implementation of their VPN site-to-site architecture.
What You’ll Learn
- What is an IKEv2 keyring?
- Advantages of keyring configuration
- How to configure a keyring for pre-shared keys
- Troubleshooting IKEv2 keyring configuration
What You’ll Need
- Two routers that support IKEv2 VPN
What is an IKEv2 Keyring?
An IKEv2 keyring is the repository of either symmetric or asymmetric pre-shared keys. The keyring configuration is required if the local or remote authentication method is pre-shared key. Notice that I said either. It is possible to configure remote authentication using another technique—for example, Rivest, Shamir, and Adleman (RSA) certificates and then the use of a local key through a pre-shared key.
The IKEv2 keyring is configured and must be attached to the IKEv2 profile, which sets the authentication type, such as RSA signature or pre-shared. Notice that in the following figure, you can see that the keyring configuration is added to the IKEv2 profile, which is added to the IPsec profile that is attached to the interface. Also, in IKEv2, the side that initiates the tunnel is called the Initiator, and the other side is called the Responder.
Advantages of a Keyring Configuration
The keyring capabilities of IKEv2 have some advantages, For example, we can configure different keyrings for different sites and use different subblocks, which allows the mixing of symmetrical keys between one site and asymmetric between another site. Additionally, the pre-shared key is used during phase 1 of the IKEv2 exchange.
How to Configure a Keyring for Pre-Shared Keys
First, configure the keyring block on both routers. In our example, it would be HQ and the branch router. The branch router configuration is shown in the following figure. Notice that the keyring is labeled KR1, and that local keyring is referenced under the default IKEv2 profile. Also notice that we are using asymmetric pre-shared keys. They are different on both sides. We use the local and remote commands on the pre-shared configuration to specify the keys.
We will configure a keyring called KR1 on the branch router. On the HQ router, we will call it Keys1. Notice that both routers are using pre-shared keys, but the keys are different. We set up these routers to share the fully qualified domain name (FQDN) with the other router because the keyring configuration will use the FQDN as the local identity. This setup is important because the local identity is used in the IKEv2 authentication process.
The local identity is the identity of the router that is initiating the tunnel. The remote identity is the identity of the router that is responding to the tunnel. The local identity is used to generate the authentication data and the remote identity is used to verify the authentication data. The authentication data is generated by the router that is using the local identity and the pre-shared key. The authentication data is verified by the router that is using the remote identity and the pre-shared key. If the authentication data does not match, the tunnel is not established.
Let’s look at the configuration on the HQ router. Notice that the key blocks are inverse images of each other. The peer’s name is the local device, the IPv4 address is the remote routers interface, and then the pre-shared commands are the local key and the remote key, which are flipped on the other router.
Troubleshooting IKEv2 Keyring Configuration
To troubleshoot the keyring process, we can do a few show commands and then debug the IKEv2 communication. The show command we will do on each side is show crypto IKEv2 profile. This command will show how the router interprets the configuration input into the router. Notice that the local identity is the FQDN HQ router. This command was executed from the branch router; therefore, it says local identity.
The other command used in troubleshooting is the debug command. In our case, we will use debug crypto ikev2. We enabled debug on the HQ router.
There are two important parts. The first is the initialization of IKEv2. Notice that it tells you which peer block and keyring information it used for the tunnel. In our case, it used keyring Keys1 and peer block Branch-Rtr.
In the second part of the same command, we see more information on the actual key exchange process. The exchange determined that the peer’s authentication method is PSK (pre-shared key) and that the router generated IKEv2 authentication data based on the pre-shared key for Branch-Rtr.abc.public. This area is where you would see a failure if the keys were incorrect on the other side.
