FlexVPN Spoke to Spoke

Lesson Contents

In the FlexVPN hub and spoke lesson, you learned that there is no direct communication between the spoke routers. All traffic goes through the hub router.

It is possible to configure FlexVPN so that spoke routers can communicate with each other directly. This has some advantages. The hub router requires less bandwidth and the latency for spoke to spoke traffic is lower. Just like with DMVPN, we use the Next Hop Resolution Protocol (NHRP) to accomplish this.

There is a difference between how DMVPN and FlexVPN use NHRP:

  • DMVPN uses NHRP for registration and resolution.
  • FlexVPN uses NHRP only for resolution.

FlexVPN doesn’t use NHRP to register spoke routers with the hub router. Instead, we can use IKEv2 routing to advertise a /32 route for the IP address of the tunnel interface to the remote router. This allows communication between the hub and spoke router.

To “convert” a regular FlexVPN hub and spoke network into a network where direct spoke to spoke traffic is possible, we need to make these changes:

  • On the hub router, we have to add an NHRP network ID and enable NHRP redirection.
  • The spoke routers require a dynamic VTI for spoke-to-spoke VPN tunnels.
  • The spoke routers require the NHRP network ID and we need to enable NHRP shortcut switching.
  • The spoke routers require some IKEv2 changes so they can authenticate each other.

In this lesson, I’ll explain how to configure all of this.

Configuration

Here is the topology we will use:

Flexvpn Hub Spoke Topology

This is the same topology that we used in the FlexVPN hub and spoke lesson. We will make changes to that topology so that our spoke routers communicate with each other directly. I used IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.9(3)M2 for this example.

Configurations

Want to take a look for yourself? Here you will find the startup configuration of each device.

Hub1

hostname Hub1
!
aaa new-model
!
aaa authorization network FLEXVPN_LOCAL local 
!
ip cef
!
crypto ikev2 authorization policy IKEV2_AUTHORIZATION 
 route set interface
 route set access-list FLEXVPN_ROUTES
!
crypto ikev2 keyring IKEV2_KEYRING
 peer SPOKE_ROUTERS
  address 0.0.0.0 0.0.0.0
  pre-shared-key local CISCO
  pre-shared-key remote CISCO
!
crypto ikev2 profile IKEV2_PROFILE
 match identity remote fqdn domain FLEXVPN.LAB
 identity local fqdn HUB.FLEXVPN.LAB
 authentication remote pre-share
 authentication local pre-share
 keyring local IKEV2_KEYRING
 aaa authorization group psk list FLEXVPN_LOCAL IKEV2_AUTHORIZATION
 virtual-template 1
!
crypto ipsec profile IPSEC_PROFILE
 set ikev2-profile IKEV2_PROFILE
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.255
!
interface Loopback1
 ip address 172.16.1.254 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 192.168.1.254 255.255.255.0
!
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback1
 tunnel protection ipsec profile IPSEC_PROFILE
!
ip access-list standard FLEXVPN_ROUTES
 permit any
!
end

Spoke1

hostname Spoke1
!
aaa new-model
!
aaa authorization network FLEXVPN_LOCAL local 
!
ip cef
!
crypto ikev2 authorization policy IKEV2_AUTHORIZATION 
 route set interface
 route set access-list FLEXVPN_ROUTES
!
crypto ikev2 keyring IKEV2_KEYRING
 peer HUB1
  address 192.168.1.254
  pre-shared-key local CISCO
  pre-shared-key remote CISCO
!
crypto ikev2 profile IKEV2_PROFILE
 match identity remote fqdn HUB.FLEXVPN.LAB
 identity local fqdn SPOKE1.FLEXVPN.LAB
 authentication remote pre-share
 authentication local pre-share
 keyring local IKEV2_KEYRING
 aaa authorization group psk list FLEXVPN_LOCAL IKEV2_AUTHORIZATION
!
crypto ipsec profile IPSEC_PROFILE
 set ikev2-profile IKEV2_PROFILE
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Tunnel0
 ip address 172.16.1.1 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel destination 192.168.1.254
 tunnel protection ipsec profile IPSEC_PROFILE
!
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
!
ip access-list standard FLEXVPN_ROUTES
 permit 1.1.1.1
!
end

Spoke2

hostname Spoke2
!
aaa new-model
!
aaa authorization network FLEXVPN_LOCAL local 
!
ip cef
!
crypto ikev2 authorization policy IKEV2_AUTHORIZATION 
 route set interface
 route set access-list FLEXVPN_ROUTES
!
crypto ikev2 keyring IKEV2_KEYRING
 peer HUB1
  address 192.168.1.254
  pre-shared-key local CISCO
  pre-shared-key remote CISCO
!
crypto ikev2 profile IKEV2_PROFILE
 match identity remote fqdn HUB.FLEXVPN.LAB
 identity local fqdn SPOKE2.FLEXVPN.LAB
 authentication remote pre-share
 authentication local pre-share
 keyring local IKEV2_KEYRING
 aaa authorization group psk list FLEXVPN_LOCAL IKEV2_AUTHORIZATION
!
crypto ipsec profile IPSEC_PROFILE
 set ikev2-profile IKEV2_PROFILE
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Tunnel0
 ip address 172.16.1.2 255.255.255.0
 tunnel source GigabitEthernet0/0
 tunnel destination 192.168.1.254
 tunnel protection ipsec profile IPSEC_PROFILE
!
interface GigabitEthernet0/0
 ip address 192.168.1.2 255.255.255.0
!
ip access-list standard FLEXVPN_ROUTES
 permit 2.2.2.2
!
end

Hub1

Let’s start with the hub router. We need to add an NHRP ID and enable NHRP redirection on the virtual-template interface:

Hub1(config)#interface Virtual-template 1
Hub1(config-if)#ip nhrp network-id 1
Hub1(config-if)#ip nhrp redirect

If you have an active VPN, you receive the following error:

% Please use virtual template to configure your virtual access

When this happens, shut your GigabitEthernet0/0 interface and wait until the router removes your IKEv2 SAs. This takes time. I tried the following commands to speed this up:

  • clear crypto sa
  • clear crypto isakmp
  • clear crypto ikev2 sa
  • clear crypto session

None of the above commands solves it immediately. If you find a way that deletes the virtual-access interface(s) right away (except for a reboot), let me know.

This is everything we have to configure on the hub router.

Spoke1

Most of the configuration is done on the spoke routers:

  • We need a dynamic VTI for spoke-to-spoke traffic.
  • We need to identify and authenticate spoke routers we want to communicate with.

Let’s start with the dynamic VTI:

Spoke1(config)#interface Virtual-template 1 type tunnel
Spoke1(config-if)#ip unnumbered tunnel 0
Spoke1(config-if)#ip nhrp network-id 1
Spoke1(config-if)#ip nhrp shortcut virtual-template 1
Spoke1(config-if)#tunnel source GigabitEthernet 0/0
Spoke1(config-if)#tunnel protection ipsec profile IPSEC_PROFILE

I use the ip unnumbered command and instead of creating a new loopback with an IP address, I refer to the IP address of the tunnel interface. We add the same NHRP network ID that we used on the hub router but also use the ip nhrp shortcut command to enable shortcut switching on the interface.

There are two changes we have to make to the static VTI interface. We have to add the same NHRP network ID and enable shortcut switching here as well:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 785 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

1804 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , ,


Forum Replies

  1. Hello,
    very nice lesson and well explained. I would just need a clarification here.

    In all FlexVPN examples, the tunnel mode you are using is the default one. This means GRE. I tried the labs with a small change under the tunnel interfaces and virtual-templates:

    tunnel mode ipsec ipv4

    This leads to a direct IPSec encapsulation avoiding the GRE overhead. However, the spoke to spoke direct connectivity is not working. The NHRP redirection fails completely. Hub and spoke communication and spoke to spoke via the hub is fine though.

    I am wondering if this is related

    ... Continue reading in our forum

  2. Hello Ilias

    Unfortunately, NHRP only works with GRE tunnels and doesn’t function with IPsec. Take a look at this Cisco Community thread which details this fact.

    https://community.cisco.com/t5/vpn/flexvpn-spoke-to-spoke-nhrp-redirect-not-working/td-p/2762514

    The reason is that NHRP can be thought of as a Layer 2 protocol. When encapsulated within a GRE tunnel, it is tunneled as is. With native IPSec tunneling, it attempts to send a Layer 2 protocol over an infrastructure designed for Layer 3, so it fails.

    I hope this has been helpful!

    Laz

  3. None of the above commands solves it immediately. If you find a way that deletes the virtual-access interface(s) right away (except for a reboot), let me know.

    Hello, admin shutting the remote (static) VTIs brings down the virtual-access interface straight away allowing you to make changes and “unshutting” the static VTIs when you are done applying changes to the DVTI

  4. Hello Jason

    Great, thanks for sharing your findings with us! I will let Rene know.

    Thanks again!

    Laz

4 more replies! Ask a question or join the discussion by visiting our Community Forum