FlexVPN Spoke to Spoke

Lessons Discussion
1

This topic is to discuss the following lesson:

3

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 to my specific software image or it is a normal behavior. Maybe NHRP is only working with GRE encapsulation like we do with classic DMVPN? Any thoughts on this would be much appreciated?

Thanks

4

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.

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

5

Many thanks Laz. Indeed very helpful!

1 Like
6

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

7

Hello Jason

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

Thanks again!

Laz

8

Hello @ReneMolenaar @lagapidis

why we don’t use virtual-template 1 under crypto ikev2 profile in spokes?

9

Hello Nipun

When configuring a crypto ikev2 profile, the minimum requirements that must be configured are the authentication method and a match statement of some kind. This is confirmed by the message that is displayed when creating an IKEv2 profile:

R1(config)#crypto ikev2 profile MY_PROFILE
IKEv2 profile MUST have:
   1. A local and a remote authentication method.
   2. A match identity or a match certificate or match any statement.
R1(config-ikev2-profile)#

The virtual template contains parameters that can be cloned and used multiple times by the crypto IKEv2 profile, including QoS, NetFlow, or ACLs. However, it is not a mandatory configuration parameter. The following is the configuration of the crypto IKEv2 profile in Spoke 1. Notice that the prerequisites are all fulfilled:

crypto ikev2 profile IKEV2_PROFILE
 match identity remote fqdn HUB.FLEXVPN.LAB
 match identity remote fqdn SPOKE2.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

Note that a dynamic VTI is being configured on the spokes, so the virtual template is being created and then referenced by the Tunnel 0 interface.

I hope this has been helpful!

Laz

11

Hello, a questions:

In Spokes, you can use the commands:

crypto ikev2 keyring FLEX_KEY
   peer FLEXVPN
    address 0.0.0.0 0.0.0.0

and thus avoid placing the IPs of each Spoke. Just as the HUB works. I tried but direct connectivity between Spokes does not work.

  • Are the tunnel interfaces on the spokes only used to communicate with the hub? I notice that a new access interface is not created to communicate with the hub, correct? then the access interfaces on the spokes are for communication with other spokes.

  • Can’t capture the resolution messages since they are encrypted with IPsec?

12

Hello Lucero

The configuration you’ve mentioned is commonly used in FlexVPN configurations where the Hub doesn’t know the IP addresses of its Spokes, which is often the case in dynamically addressed environments. The ‘address 0.0.0.0 0.0.0.0’ command tells the router to accept any IP address.

However, for direct connectivity between Spokes (Spoke-to-Spoke), you need to have the specific IP addresses. This is because when a Spoke wants to communicate with another Spoke, it needs to know the other Spoke’s IP address to establish a direct tunnel. If you use the ‘address 0.0.0.0 0.0.0.0’ command, the Spoke wouldn’t know where to direct the traffic to.

So, for Spoke-to-Spoke tunnels, you would need to specify the IP addresses. If the IP addresses of the Spokes are dynamically assigned and you’re not able to specify them, you may need to use a solution like Dynamic Multipoint VPN (DMVPN) or use a central Hub to relay the traffic between Spokes.

I hope this has been helpful!

Laz