So far in this series, we have been looking at how to configure IKEv2 on the Cisco IOS. We have configured site-to-site VPN tunnels using both crypto-maps and VTIs and also PSK and PKI authentication. For the rest of this series, we will look at other VPN types that can be configured with IKEv2.
‘FlexVPN’ is actually Cisco’s implementation of IKEv2 that provides a unified configuration framework for almost all VPN types (GETVPN is not yet supported). In IKEv1, the configuration for site-to-site VPNs was different from the configuration for EzVPN; FlexVPN tries to bring everything under a common configuration block.
What we want to achieve in this article is something similar to EzVPN – a FlexVPN server should be able to terminate VPN tunnels from remote clients (both hardware and software). Hardware remote clients will be other Cisco IOS routers while software remote clients can be the Cisco AnyConnect client or built-in Windows 8 client, for example.
For this article, we will stick with two Cisco IOS routers: one will act as the FlexVPN server and the other will act as the FlexVPN client.
Note: Loopback interfaces will serve as the networks that need to be protected on both routers.
There are a few things to understand when configuring FlexVPN server/client. The first relates to the FlexVPN configuration on the server: since we expect that there will be several remote clients, we need to use a dynamic VTI (unlike the static VTI that we used for the site-to-site VPN tunnel).
The second relates to the FlexVPN client: if you want the client to be able to connect to multiple peers or you want to configure multiple source interfaces, then you need to configure a FlexVPN client profile and set the tunnel destination to dynamic.
Let’s get down to the configuration. Most of the configuration from the previous IKEv2 articles still apply here, but like I said, we will be using a dynamic VTI (dVTI) on the server. We will also stick with all the IKEv2 Smart Defaults for our configuration.
hostname FLEX-SERVER ! aaa new-model aaa authorization network IKE_LIST local ! crypto ikev2 authorization policy default route set access-list PROTECTED_ACL ! crypto ikev2 keyring ANY peer ANY address 0.0.0.0 0.0.0.0 pre-shared-key cisco ! crypto ikev2 profile FLEX_SERVER_PROF match identity remote address 0.0.0.0 identity local address 10.0.0.1 authentication remote pre-share authentication local pre-share keyring local ANY aaa authorization group psk list IKE_LIST default virtual-template 1 ! crypto ipsec profile default set ikev2-profile FLEX_SERVER_PROF ! 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 ! interface Virtual-Template1 type tunnel ip unnumbered Ethernet0/0 tunnel source Ethernet0/0 tunnel mode ipsec ipv4 tunnel protection ipsec profile default ! ip access-list standard PROTECTED_ACL permit 192.168.10.0 0.0.0.255 !
Note: The keyring ‘ANY’ matches all IP addresses so it is like a wildcard key. Of course this is not secure. PKI should be preferred instead.
In the configuration above, we configured a virtual-template interface which is how we define a dynamic virtual tunnel interface. When a remote peer successfully negotiates the IPsec tunnel, virtual-access interfaces will be created from this virtual-template and these virtual-access interfaces will inherit the layer 3 features of this virtual template. You can also apply various policies (QoS, ACLs, etc.) to the created virtual-access interfaces. We then attached the virtual-template under the IKEv2 profile.
You should be familiar with other aspects of the configuration from the previous article. For example, the PROTECTED_ACL defines the networks that will be carried in the IKE SAs to define what routes should be advertised.
We will now go ahead with the FlexVPN client configuration. Since we will not be connecting to multiple peers, I will use a normal static VTI and statically define the tunnel destination rather than using a FlexVPN client profile.
hostname FLEX-CLIENT ! aaa new-model aaa authorization network IKE_LIST local ! crypto ikev2 authorization policy default route set interface route set access-list PROTECTED_ACL ! crypto ikev2 keyring FLEX_SERVER_KEY peer FLEX_SERVER address 10.0.0.1 pre-shared-key cisco ! crypto ikev2 profile FLEX_CLIENT_PROF match identity remote address 10.0.0.1 255.255.255.255 authentication remote pre-share authentication local pre-share keyring local FLEX_SERVER_KEY aaa authorization group psk list IKE_LIST default ! crypto ipsec profile default set ikev2-profile FLEX_CLIENT_PROF ! interface Loopback0 ip address 192.168.20.2 255.255.255.0 ! interface Tunnel1 ip unnumbered Ethernet0/0 tunnel source Ethernet0/0 tunnel destination 10.0.0.1 tunnel mode ipsec ipv4 tunnel protection ipsec profile default ! interface Ethernet0/0 ip address 10.0.0.2 255.255.255.0 ! ip access-list standard PROTECTED_ACL permit 192.168.20.0 0.0.0.255
As you can see, this configuration is very similar to our site-to-site VPN configuration except that we don’t explicitly specify an IP address for the Tunnel1 interface.
Once you have applied this configuration, you should see the tunnel interface come up on the FlexVPN client and the Virtual-access interface come up on the FlexVPN server. The only challenge is that the tunnel will be flapping and you may see a message like:
*May 7 07:53:25.898: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
This is due to the routes that we are pushing through the IKE SAs. Because we used the default IKEv2 authorization policy, the FlexVPN client is automatically pushing the IP address of its tunnel interface while the FlexVPN server is pushing the IP address of its virtual-access interface.
Looking at the virtual-template configuration on the FlexVPN server, we configured “ip unnumbered Ethernet0/0”. This means that the virtual-access interface will use an IP address of 10.0.0.1 which will be sent to the FlexVPN client via the IKE SA. When the client receives this route, it will install it in its routing table as a static route.
The problem then presents itself: how will the client build a tunnel to a destination of 10.0.0.1 if the way it knows how to reach that destination is through the tunnel?
There are two ways to solve this problem. The first is to change the interface we use for the “ip unnumbered” command on both the FlexVPN client and the server. The second method is to remove the “route set interface” commands under the default IKEv2 authorization policies. I will use the second method but you should decide which one works for you:
crypto ikev2 authorization policy default no route set interface
With this, the tunnel and virtual-access interface come up and stay up.
We can also check the IKEv2 session details on both the server and client – notice the remote subnets:
These remote subnets are installed as static routes in the routing table of the routers.
Finally, let’s test that we can ping between the protected subnets and also confirm that the traffic is protected:
In this article, we have seen how to use IKEv2 (implemented as FlexVPN by Cisco) to configure a different type of VPN using dynamic VTIs. We also saw an issue that the routes advertised by IKE SAs can cause.
In the next article in this series, we will look at another VPN tunnel that can be configured using IKEv2. I hope you have found this article insightful.
References and Further reading
- FlexVPN Migration: Legacy EzVPN-NEM+ and FlexVPN on the Same Server: http://www.cisco.com/c/en/us/support/docs/security/flexvpn/115013-flexvpn-migration-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