FlexVPN Hub and Spoke

Hello Terry

Yes, you seem to be correct. I will let @Rene know…

Laz

Thanks Terry. I just fixed this.

Rene

Hello Laz ,
how does the Hub Router advertise the default Route to Spoke ? with access list permit any? BUT There is no command to advetise the default route or this will occur automatically ?

Thanks in Advanced .

Hello Mohammad

The routes in this network topology are shared using IKEv2 routing. The default route that the spokes learn about comes from the hub, and is based on the configuration found in the IKEv2 Authorization Policy found in section 1.1.2 of the lesson.

Specifically, it is the route set access-list FLEXVPN_ROUTES command that advertises the default route. Tee FLEXVPN_ROUTES access list says permit any, which is the same as 0.0.0.0 0.0.0.0 which is the default route.

This then appears as a static route that sends all default traffic via the Tunnel0 interface, which connects to the hub.

I hope this has been helpful!

Laz

Hi @ReneMolenaar

Unless I am mistaken it seems to be a mistake in this configuratin,
although the shou running config at the bottom is correct but they are not the same as the step by step configuration when you are explaine the command,

1-Spoke1(config-ikev2-profile)# aaa authorization group psk list FLEXVPN_LOCAL IKEV2_AUTHORIZATION is missing on the IKEv2 Profile - on Spoke1 router

2- on Spoke2 the above command is there but ends with “default” and not IKEV2_AUTHORIZATION here:
Spoke2(config-ikev2-profile)#aaa authorization group psk list FLEXVPN_LOCAL default

but on the full config(show run) the config is correct, I am not sure if i am missing something here or not since although i followed your config step by step but the tunnel was down and had to trubolshoot it, because when I copy your entire “sho run” into my spoke routers it worked for me, and that is when I noticed the difference between the step by step config and the running config,

apart from that I have a question, the loopback interface on the HUB1 is 172.16.1.254/32 while this subnet is /24 on the spokes, is this ok?

Cheers

Hello Ryfa

Yes, it looks like you are correct. I’ll let Rene know to make the necessary modifications. Thanks for pointing that out!

Idealy the subnets should be the same, however, because FlexVPN simply needs communication between the spoke and the hub routers, something that has been established not by simple routing, but by the virtual access ports created in the hub. If you take a look at the output of the show ip route command on the Hub router, you will see that both 172.168.1.1 and 172.168.1.2 are reachable from the hub because they are directly connected to the virtual access ports, and not because they are directly connected via the loopback interface. If the latter was the case, the subnet mask of /32 would make those two spokes unreachable.

I hope this has been helpful!

Laz

1 Like

I am not seeing the full configs of the routers only the ip interfaces are showing up in the article

Hello Timothy

The configs that appear near the beginning of the lesson are the startup configurations of each device. This includes only configurations that are necessary to prepare before applying any of the configurations you see in the lesson. These initial configs don’t include all of the default settings that are already set up in the config of IOS routers. They only include the changes you need to make before you begin. Those changes include only the configuration of the hostname and the loopback and GE interfaces.

The configurations near the end of the lesson show all of the configs that have been applied in all of the sections of the lesson, so you can see the results that you should have after applying all of the described configs.

I hope this has been helpful!

Laz

why the config of DVTI of hub doesn’t have tunnel source cmd?

Hello Nipun

When configuring a DVTI, it is unnecessary to use the tunnel source command. When creating a static VTI, you must bind that VTI to a physical interface. However, when creating a dynamic VTI, you create a virtual template that is not associated with any physical interface. Whenever a new IPSec session is needed, the router automatically creates a virtual access interface that is cloned from the virtual template. This can occur on any of the router’s interfaces, so there is no single interface that is the tunnel’s source.

For more information on DVTIs and SVTIs, take a look at this lesson:

I hope this has been helpful!

Laz

Hi all,
How to use this with ip sla?
I mean that when the connexion goes down, how to tell the router to upload another route to spoke or from hub to spoke?
Regards!

Hello Boubou

IP SLA can be used in many ways to respond to changes on a network. In this particular case, it depends upon what you want to achieve.

This will depend upon your topology. Generally, a hub and spoke topology will have only one route from the hub to each spoke. There are no alternative routes, so an IP SLA would not help us here at all. To achieve redundancy in such a case, you would have to create a dual hub. An example of a FlexVPN dual hub and spoke configuration can be found in this Cisco documentation:

If you want to learn more about IP SLA in general and how you can apply it in various situations, take a look at this lesson:

I hope this has been helpful!

Laz


Hi Lagapides,
Good morning,
At first I configured the connection between the HQ and the 7 remote sites through a WAN and then I configured the WAN2 to make a backup link by configuring cisco ip SLA. The tracking has been put on the main WAN and everything is working correctly.
From HQ I track all remote ip addresses. And from the remote sites I track the HQ ip address. When an address does not respond, the router loads the route that passes through the WAN2 on the HQ side as well as on the remote site side.

Now I have configured FLEXVPN on the main WAN. WAN2 is safe. and everything works. I still have to implement ip sla.
From HQ I can track the ip addresses of the FLEXVPN of the spokes, but from the remote sites which ip address of the HQ to track?
So as you can see, the DUAL HUB does not suit me.

Hello Boubou

That’s an interesting setup. Typically, the hub loses connectivity with the IP address of a spoke, the same will occur with the spoke on its end, so both IP SLAs on both devices will begin using the backup link. That makes sense.

I believe it would be best to track the IP addresses of the tunnel and not of the physical interfaces. So if we look at the lesson as our example, Spoke 1 should monitor the 172.16.1.1 IP address. If the tunnel fails, but the physical address is still reachable, that would not result in traffic rerouting if a failure occurred.

In your topology, you have marked the interface of the hub connected to the FlexVPN WAN as 10.10.20.10. If that is the IP address of the tunnel interface and not of the physical interface, then you can track that address. As soon as a spoke loses connectivity to that address, it can switch to WAN2. Does that make sense?

I hope this has been helpful!

Laz

Hi Lazaros,
I have follow your advises.
So now from the Hub, when failure accur (physical interface admistrative down or link loss), backup routes are not loaded in routing table as virtual-access interfaces still remain.
I have to issue manually the command : clear crypto session
Then backup routes are all loaded and the connexions to spokes networks become up.

And when physical interface become available, flexvpn connexions come up very slowly.

So please how can solve this.

Hello Boubou

In a FlexVPN Hub and Spoke setup, backup routes do not load automatically when the hub fails because the spoke routers are still maintaining an active IPsec Security Association (SA) with the hub. The virtual-access interfaces that are associated with the IPsec SAs remain up, even though the hub is no longer reachable. This is because the routing used in the setup is not aware of the underlying IPsec tunnel’s actual state. Otherwise, any backup routes would kick in.

Issuing the clear crypto session command forces the IPsec SAs to be torn down and the associated virtual-access interfaces to be removed. This triggers the routing to re-evaluate the routes and load the backup routes into the routing table.

The SA will remain up for the configured lifetime duration, which by default is 86400 seconds or one full 24-hour day.

One solution would be to reduce the lifetime to something on the order of several seconds, but this will cause the router to reestablish the SA continually, which may not cause disruption to the network, but will increase the burden of resources on the router. Another solution would be to automate the process of issuing the clear crypto session command in the event the hub fails. You can do this by incorporating an Embedded Event Manager (EEM) applet with an IPSLA, where the command will be run whenever communication with the hub has failed.

Yes, this is because of a related issue. If the SAs on the spokes haven’t expired yet when the hub comes back up, they will still be active, so the spokes won’t attempt to reestablish the new SAs with the hub. The spokes will wait until the SAs time out before attempting to reestablish. If Dead Peer Detection (DPD) is activated, which is a mechanism used by IPSec VPN devices to detect if the remote peer is still alive. The default timeout is 30 seconds with a retry interval of 10 seconds. The delay in detecting the peer’s state can affect the reestablishment of the connections.

To be able to further troubleshoot the issue, it would be a good idea to take a look at the syslogs and do some debugging to determine the specific reason behind the delay.

I hope this has been helpful!

Laz

Hello can FlexVPN implemented on Cat 9500 and 9300 switches pls ?

Hello Hab

FlexVPN is a feature that is available only on Cisco routers. You can see more info about compatibility and platform support of FlexVPN in the following documentation:

So, unfortunately, the 9500 and 9300 do not support FlexVPN, because these devices are primarily designed for campus and data center switching, rather than being VPN concentrators.

I hope this has been helpful!

Laz

I followed the outline but I’m getting a few errors.

001609: *Jan  6 03:26:24.389: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel1 - looped chain attempting to stack
001610: *Jan  6 03:26:26.037: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
001611: *Jan  6 03:26:26.037: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
001612: *Jan  6 03:26:26.289: IKEv2:(SA ID = 1):Retransmitting packet

001613: *Jan  6 03:26:26.289: IKEv2:(SA ID = 1):Sending Packet [To 98.xx.xx.xx:4500/From 192.168.1.190:4500/VRF i0:f0]
Initiator SPI : 06D974DD25B1A0DF - Responder SPI : 0FEBD183B05898BB Message id: 2
IKEv2 INFORMATIONAL Exchange REQUEST
Payload contents:
 ENCR

001614: *Jan  6 03:26:26.297: IKEv2:Detected an invalid IKE SPI

001615: *Jan  6 03:26:26.297: IKEv2:Couldn't find matching SA

001616: *Jan  6 03:26:26.297: IKEv2:(SA ID = 0):Received Packet [From 98.xx.xx.xx:4500/To 192.168.1.190:4500/VRF i0:f0]
Initiator SPI : ABCEA0BC8F907150 - Responder SPI : 037F1AFB09699BCE Message id: 0
IKEv2 INFORMATIONAL Exchange REQUEST
001617: *Jan  6 03:26:26.297: IKEv2:A supplied parameter is incorrect

001618: *Jan  6 03:26:26.297: IKEv2:
001619: *Jan  6 03:26:30.157: IKEv2:Detected an invalid IKE SPI

001620: *Jan  6 03:26:30.157: IKEv2:Couldn't find matching SA

001621: *Jan  6 03:26:30.157: IKEv2:(SA ID = 0):Received Packet [From 98.xx.xx.xx.xx:4500/To 192.168.1.190:4500/VRF i0:f0]
Initiator SPI : ABCEA0BC8F907150 - Responder SPI : 037F1AFB09699BCE Message id: 0
IKEv2 INFORMATIONAL Exchange REQUEST
001622: *Jan  6 03:26:30.157: IKEv2:A supplied parameter is incorrect

Hello Matthew

The error messages you’re encountering while configuring FlexVPN on Cisco devices indicate several issues that need to be addressed:

The first one has to do with Recursive Routing Issues. The messages %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing and %ADJ-5-PARENT: Midchain parent maintenance... suggest a recursive routing problem. This typically happens when the route to the tunnel destination is learned through the tunnel itself, causing a loop.

Secondly, it seems that you have IKEv2 Errors. The repeated IKEv2 errors (Detected an invalid IKE SPI, Couldn't find matching SA, A supplied parameter is incorrect) point to issues with the IKEv2 Security Association (SA) negotiation. This could be due to a mismatch in the IKEv2 policy parameters (encryption, hash, authentication, etc.) between the FlexVPN peers.

Without knowing more about your configuration, I can make some suggestions and give you some guidelines as to how you can proceed in your troubleshooting:

  1. Check Routing Configuration: Ensure that the routes to the tunnel endpoints are not learned through the tunnel itself. You might need to define specific static routes or adjust your dynamic routing protocol configuration to prevent recursive routing.

  2. Verify IKEv2 Configuration:

    • Check the IKEv2 policies on both ends of the VPN to ensure they match exactly in terms of encryption algorithms, hash algorithms, and other parameters.
    • Ensure that the correct keyring and profiles are being used and that the endpoint addresses in the IKEv2 profiles are correctly configured.
    • The IKEv2:A supplied parameter is incorrect error suggests that there might be a misconfiguration in one of the IKEv2 parameters. Double-check all the parameters carefully.
  3. Review Tunnel Configuration: Verify the tunnel interface settings, including source and destination addresses, and ensure they are correctly configured.

Looking at these configuration parameters you should be able to determine the problem in your topology. Let us know how you get along and if you need any further assistance.

I hope this has been helpful!

Laz