In this series, we have been looking at how to configure IKEv2 on Cisco IOS routers. In the last two articles, we configured an L2L VPN using IKEv2 and crypto maps and also enabled debugging so as to go behind the scenes of IKEv2.
In this article, we will configure L2L VPN using a method other than crypto maps—VTIs—and also use PKI for authentication rather than PSK. Our topology remains as shown below:
Using virtual tunnel interfaces (VTIs) to build VPN tunnels provides many benefits, one of which is the fact that they can carry multicast traffic. Apart from that, these interfaces can be treated like any normal interface and a number of policies can be applied to them. You can refer to this article on how to use VTIs to build VPN tunnels (IKEv1).
Before we get to the PKI configuration, let us first rebuild our VPN configuration to use VTIs rather than crypto maps.
The configuration on R1 is as follows:
interface Ethernet0/0 no crypto map R1-R2-CRYPTO-MAP ! crypto ipsec transform-set R1-R2-TRANSFORM-SET esp-aes esp-sha256-hmac ! crypto ipsec profile R1-R2-IPSEC-PROFILE set transform-set R1-R2-TRANSFORM-SET set ikev2-profile R1-R2-PROFILE ! interface tunnel 0 ip address 172.16.1.1 255.255.255.0 tunnel source Ethernet0/0 tunnel mode ipsec ipv4 tunnel destination 10.0.0.2 tunnel protection ipsec profile R1-R2-IPSEC-PROFILE ! no ip route 192.168.20.0 255.255.255.0 10.0.0.2 ip route 192.168.20.0 255.255.255.0 172.16.1.2
In the configuration above, I have removed the crypto map attached to the Ethernet0/0 interface. I then configured my own transform set and attached this transform set along with our previously configured IKEv2 profile to an IPsec profile. This IPsec profile is then applied to the tunnel interface.
Note: I could have used the default transform set and also the default IPsec profile, but I decided to create mine. If you want to use the default IPsec profile called “default,” just edit it to attach the IKEv2 profile you created. For example:
crypto ipsec profile default set ikev2-profile R1-R2-PROFILE
I have also changed the static route for the remote protected subnet to go through the tunnel so that traffic to that destination will be encrypted. We will consider other ways to get traffic to flow through the tunnel later in this article.
The configuration on R2 is similar, as follows:
interface Ethernet0/0 no crypto map R1-R2-CRYPTO-MAP ! crypto ipsec transform-set R1-R2-TRANSFORM-SET esp-aes esp-sha256-hmac ! crypto ipsec profile R1-R2-IPSEC-PROFILE set transform-set R1-R2-TRANSFORM-SET set ikev2-profile R1-R2-PROFILE ! interface tunnel 0 ip address 172.16.1.2 255.255.255.0 tunnel source Ethernet0/0 tunnel mode ipsec ipv4 tunnel destination 10.0.0.1 tunnel protection ipsec profile R1-R2-IPSEC-PROFILE ! no ip route 192.168.10.0 255.255.255.0 10.0.0.1 ip route 192.168.10.0 255.255.255.0 172.16.1.1
If our configuration is good, the tunnel should automatically come up. We can confirm using various show commands like show crypto ikev2 sa and show crypto ipsec sa.
To confirm that traffic through the tunnel is protected, we can ping between the Loopback 0 interfaces of the routers:
What we want to achieve in this section is asymmetric authentication: R1 should authenticate using a digital certificate but R2 should keep using the pre-shared key. This is not possible with IKEv1, but it can be done in IKEv2.
The first thing we need is a certificate authority. Since this is a lab setup, I will configure R1 as the certificate authority, which will also issue out certificates to itself. You can refer to this article on how to enable Certificate Server on Cisco IOS and how to enroll with a Cisco IOS Certificate Server.
First we will enable the certificate server on R1.
crypto pki server IOS_CA issuer-name cn=IOS_CA, o=Example.com grant auto no shut
Note: Depending on your IOS version, you may first need to generate an RSA key with a label that is the same as the IOS certificate server name. On my IOS version (15.2), the RSA key was automatically generated.
Now, I need to enroll with this CA for a normal digital certificate. Even though R1 is acting as the IOS certificate server, we still need to authenticate and enroll with the CA like any normal CA, so we will configure the trustpoint and specify the enrollment URL:
crypto pki trustpoint IOS_TRUSTPOINT enrollment url http://10.0.0.1 ! ip domain name example.com
I configured a domain name so that when R1 is requesting for a certificate, it will use an FQDN of “hostname.domain-name” rather than just “hostname.” Another way to do it would have been to specify a subject-name under the trustpoint definition.
We will now authenticate the trustpoint:
After authenticating the CA, we can now request (enroll) a digital certificate from it:
For R2 to successfully verify R1’s digital certificate, it must trust the certificate authority that issued R1’s digital certificate. Therefore, on R2, we only need to authenticate the CA.
crypto pki trustpoint IOS_TRUSTPOINT enrollment url http://10.0.0.1 revocation-check none ! crypto pki authenticate IOS_TRUSTPOINT
Now we can go ahead and alter our IKEv2 profile configuration. What we currently have on R1 is:
We need to change the local authentication to “rsa-sig”. We also need to set the local identity, i.e., how R1 should identify itself to the remote peer. Finally, we need to set the PKI trustpoint that will be used to sign and/or verify digital certificates. If you don’t set a PKI trustpoint, authentication will fail because the router will not automatically search for locally defined trustpoints.
crypto ikev2 profile R1-R2-PROFILE authentication local rsa-sig identity local fqdn R1.example.com pki trustpoint IOS_TRUSTPOINT
Note: If you don’t specify ‘sign’ or ‘verify’ at the end of your PKI trustpoint definition, it will use that trustpoint to both sign and verify digital certificates. In our scenario, R1 only needs to use that trustpoint to sign so the command pki trustpoint IOS_TRUSTPOINT sign will also work.
On R2, we also need to make some changes to the IKEv2 profile: we need to set the remote authentication to “rsa-sig” and we need to change the way the remote peer’s identity is matched. You can also add the PKI trustpoint for completeness’ sake.
crypto ikev2 profile R1-R2-PROFILE no authentication remote pre-share authentication remote rsa-sig no match identity remote address 10.0.0.1 match identity remote fqdn R1.example.com pki trustpoint IOS_TRUSTPOINT
Hint: Another way to match the remote peer’s identity is to use a certificate map.
You can check that your tunnel interface is up after the configuration changes and that traffic between the protected subnets is going through.
You can also check the IKEv2 SAs, which will reveal what authentication method is being used to sign and verify:
To wrap up this article, let’s talk about how routes can be propagated over the VPN tunnel. One way, as we have seen, is to use static routes. Another way will be to configure a dynamic routing protocol and advertise the routes that should be protected using the tunnel. A third way, which we will configure, is to advertise the routes inside the IKEv2 SAs.
The configuration to achieve this on R1 is as follows:
aaa new-model aaa authorization network IKEv2_LIST local ! ip access-list standard R1-SUBNETS permit 192.168.10.0 0.0.0.255 ! crypto ikev2 authorization policy R1-AUTHR-POLICY route set interface route set access-list R1-SUBNETS ! crypto ikev2 profile R1-R2-PROFILE aaa authorization group psk list IKEv2_LIST R1-AUTHR-POLICY
The configuration on R2 is as follows:
aaa new-model aaa authorization network IKEv2_LIST local ! ip access-list standard R2-SUBNETS permit 192.168.20.0 0.0.0.255 ! crypto ikev2 authorization policy R2-AUTHR-POLICY route set interface route set access-list R2-SUBNETS ! crypto ikev2 profile R1-R2-PROFILE aaa authorization group cert list IKEv2_LIST R2-AUTHR-POLICY
Once the IKE SAs have been rebuilt (you can force this by using the clear crypto ikev2 sa command), we now see the remote subnets listed at the bottom of the show crypto ikev2 sa detailed command:
With this configuration, you can now safely remove the static routes you have configured and your ping traffic will still be successful.
In this article, we have configured an L2L VPN using IKEv2 and VTIs with PKI for authentication. We have also seen how routes can be advertised in IKE SAs.
I hope you have found this article helpful.
References and Further Reading
- FlexVPN Site-to-Site Configuration Example: http://www.cisco.com/c/en/us/support/docs/security/flexvpn/115782-flexvpn-site-to-site-00.html
- Configuring Internet Key Exchange Version 2 (IKEv2): http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ikevpn/configuration/15-1mt/Configuring_Internet_Key_Exchange_Version_2.html