FlexVPN Spoke to Spoke

This topic is to discuss the following lesson:

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?


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!


Many thanks Laz. Indeed very helpful!

1 Like

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

Hello Jason

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

Thanks again!


Hello @ReneMolenaar @lagapides

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

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.

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!