In the previous articles in this IKEv2 series, we have looked at how to configure LAN-to-LAN and FlexVPN Server and Client using IKEv2. In this article, we will be configuring another type of VPN called FlexVPN Spoke to Spoke, which is essentially DMVPN but with IKEv2.
The lab setup we will use in this article is shown below:
In the diagram above, we have two FlexVPN clients connecting to one FlexVPN server. Before we go to the FlexVPN spoke-to-spoke configuration, let us see what happens if we just use the standard FlexVPN server/client configuration. The configuration on the FlexVPN server is as follows:
hostname FLEX-SERVER ! aaa new-model aaa authorization network IKE_LIST local ! ip access-list standard FLEX_ACL permit any ! 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 ! crypto ikev2 authorization policy default route set interface route set access-list FLEX_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 match identity remote fqdn domain example.com 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 Virtual-Template1 type tunnel ip unnumbered Loopback0 tunnel source Ethernet0/0 tunnel protection ipsec profile default !
The configuration on one of the FlexVPN clients is as follows:
hostname FLEX-CLIENT ! aaa new-model aaa authorization network IKE_LIST local ! ip access-list standard FLEX_ACL permit 172.16.1.0 0.0.0.255 ! interface Loopback0 ip address 172.16.1.1 255.255.255.0 ! interface Tunnel1 ip unnumbered Loopback0 tunnel source Ethernet0/0 tunnel destination dynamic tunnel protection ipsec profile default ! interface Ethernet0/0 ip address 10.0.0.10 255.255.255.0 no shut ! crypto ikev2 authorization policy default route set interface route set access-list FLEX_ACL ! crypto ikev2 keyring FLEX_KEYS 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_KEYS aaa authorization group psk list IKE_LIST default ! crypto ikev2 client flexvpn IKEv2_CLIENT_PROFILE peer 1 10.0.0.1 client connect Tunnel1 ! crypto ipsec profile default set ikev2-profile FLEX_CLIENT_PROF !
Note: You can replicate the configuration for the other FlexVPN client; just remember to change the IP addresses (172.16.1.1 to 172.16.2.1 and 10.0.0.10 to 10.0.0.20) and the subnet matched under the FLEX_ACL.
If you look at the FlexVPN server configuration, you will notice that the FLEX_ACL permits any network. This basically means the FlexVPN server is advertising a default route to the clients. The FlexVPN server also sends the virtual-access interface address because of the “route set interface” command under the IKEv2 authorization policy.
When our tunnels are set up, we can see the routes advertised by the FlexVPN server on one of the FlexVPN clients:
If we check the routing table of the FlexVPN server, we will also see the networks advertised by the FlexVPN clients:
For testing purposes, let us check that the FlexVPN client can ping the FlexVPN server’s network, i.e., 192.168.10.1.
On the FlexVPN server, we can see that this traffic was encrypted/decrypted over the Virtual-Access1 interface:
Now, from a routing perspective, since the FlexVPN clients also have a default route through the tunnel (through the FlexVPN server), it means they will forward traffic to each other through that tunnel. For example, if FlexVPN client1 pings FlexVPN client2, the traffic will flow through the FlexVPN server.
I can verify that this traffic goes through the FlexVPN server by looking at the encrypted/decrypted section of the IPsec SAs again:
FlexVPN Spoke to Spoke
As with normal DMVPN, it is more desirable for spoke-to-spoke traffic to flow through a tunnel between the spokes themselves rather than going through the hub. This is what FlexVPN Spoke to Spoke helps us achieve and it also uses NHRP to achieve this functionality. However, unlike normal DMVPN, the NHRP configuration required for FlexVPN Spoke to Spoke is much simpler.
Looking at it from a high level, we can bring out the following requirements for FlexVPN Spoke-to-Spoke configuration:
- The configuration on the FlexVPN server (hub) will remain fairly the same, i.e., we still configure a dynamic VTI. However, some NHRP commands will be added under the VTI.
- The Spokes (FlexVPN clients) will still have a static VTI configured for Hub-to-Spoke communication. However, some NHRP commands will also be included under the tunnel interface.
- A dynamic VTI needs to be configured on the spokes so that they can dynamically build spoke-to-spoke tunnels. This third point is where FlexVPN Spoke to Spoke really defers from the normal FlexVPN server/client model.
There are three basic NHRP commands that we require for the FlexVPN Spoke-to-Spoke configuration:
- On both the hub and spoke, we need to configure an NHRP network ID under the VTI, which identifies the DMVPN cloud and also enables NHRP on that interface.
- On the hub, we need to enable NHRP redirect so that the hub can inform the spokes that they can communicate directly, i.e., trigger spoke-to-spoke tunnel negotiation.
- On the spokes, we need to enable NHRP shortcut so that spokes will forward traffic to other spokes’ remote subnets via the spoke-to-spoke tunnel.
Keeping these points in mind, let’s get down to the configuration. The configuration addition on the FlexVPN server (Hub) is as follows:
interface Virtual-Template1 type tunnel ip nhrp network-id 1 ip nhrp redirect
Note: You cannot make changes to a Virtual-Template configuration if it has associated Virtual-access interfaces; you will get the following error: “% Virtual-template config is locked, active vaccess present.” To make changes, clear your IKEv2 and IPsec SAs (and make sure they are not rebuilt by shutting down the physical interfaces, maybe on the clients).
The configuration addition on the FlexVPN Client1 is as follows:
interface Virtual-Template1 type tunnel ip unnumbered Loopback0 ip nhrp network-id 1 ip nhrp shortcut virtual-template 1 tunnel source Ethernet0/0 tunnel protection ipsec profile default ! interface Tunnel1 ip nhrp network-id 1 ip nhrp shortcut virtual-template 1 ! crypto ikev2 keyring FLEX_KEYS peer FLEX_CLIENT2 address 10.0.0.20 pre-shared-key cisco ! crypto ikev2 profile FLEX_CLIENT_PROF match identity remote address 10.0.0.20 virtual-template 1
Note: You can replicate the spoke configuration on the 2nd FlexVPN client with the necessary IP address change.
When the tunnels are up, Hub-to-Spoke traffic will still flow as normal:
Now what happens when we ping 172.16.2.1 (Spoke2) from 172.16.1.1 (Spoke1)?
We see that the traffic is successful, but something actually happened behind the scenes: a dynamic tunnel was built. The ping traffic started off going through the hub but, after the dynamic tunnel was built, the remaining ping packets went over this dynamic spoke-to-spoke tunnel:
If we use the show ip nhrp command, we see the cache entries for the remote spoke and NHRP routes there:
You can refer to this Cisco document for details on how the NHRP redirect works to build FlexVPN Spoke to Spoke tunnels.
In this article, we have configured FlexVPN Spoke to Spoke, which allows spokes to communicate with each other over dynamically created tunnels.
I hope you have found this article insightful.
References and Further Reading
- Configuring FlexVPN Spoke to Spoke: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/xe-3s/sec-flex-vpn-xe-3s-book/sec-flex-spoke.html