05-15-2018 12:52 PM - edited 03-12-2019 05:17 AM
Hello everybody,
I'm new to FlexVPN but I was implementing FlexVPNs during the last weeks in my lab.
I was asking myself if there is a way where I have two Routers configured as FlexVPN Clients at a branch office and have a kind of active/passive setup.
At HQ Site I have two FlexVPN Hubs configured as Load Balancer. At the branch I want to setup two FlexVPN Clients in Active/Passive Mode (if possible) where the active FlexVPN Client build the tunnel to the Load Balancer IP and in case the "active" FlexVPN Client has a failure, the second FlexVPN Client as a backup will build the new tunnel. After FlexVPN Client 1 comes back online it will take back the active status.
05-15-2018 01:07 PM
05-15-2018 11:19 PM - edited 05-15-2018 11:20 PM
Hi RJI,
thanks for your reply. Your recommendation with HSRP is totally clear but the problem will appear on the other site at HQ, because both FlexVPN Clients at the Spoke will establish a tunnel to the hub. Then the hub will have two identical static routes via IKEv2 to the Spoke. I'm not running any dynamic routing protocol at the spoke or between hub and spoke. So I can't manipulate the metric for one route via one tunnel.
05-16-2018 04:49 AM
Hi Hans,
Ok, I understand. I've had a look around and don't see anything official. I've put some thought into a solution, however it is not an elegant solution.
You could use a combination of a ip sla, tracker and a null route to the hub. Configure a ip sla to monitor the state of the Spoke R1 router, when this is UP then the null route to the Hub(s) will prevent Spoke R2 forming a VPN tunnel. When/If Spoke R1 external interfaces stops responding the tracker will remove the null route(s) and Spoke R2 will now be able to setup a tunnel. You'll want to configure DPD as well to clear down stale connections. I try this in a lab and it works.
I'll put some more thought into an alternate solution, whether we can filter the routes on the hub.
HTH
05-17-2018 12:54 AM - edited 05-17-2018 12:55 AM
There is no canned solution to achieve that at the moment though we have some demand for dynamic IKEv2 routing to pass limited information such as a metric. We are seriously considering the feature but as always, any use case (and ideally business case) is always welcome to help our Product Managers take a decision. This remains hypothetical until it ships.
In them meantime, I will build on the HSRP option that seems to match the question really well.
To ensure the return traffic goes to the secondary when it is online, we can give each device in the branch a distinct identity. Assuming certificates, the OU can be used to contain "primary" or "backup".
Two hub profiles can be created to match either primary or backup. Each profile can apply a distinct authorization profile. Each authorization profile can accept remote prefixes but apply a different administrative distance (and tag) on the received route. In this case, we would make sure that the admin distance from the primary spoke is _higher_ than the admin distance of the secondary spoke.
When the secondary spoke connects, it will exactly overlap with the primary branch prefix but have a lower admin distance and thus the secondary branch route will override the primary in the routing table (RIB) of the hub.
This boils down to having the hub select the preferred path based on the branch identity/identities that connect to it.
Depending on the exact use case, there may be alternative (completely different) designs.
Please note that if security is not crucial (e.g. no need for RADIUS route filtering etc.), you can still use a routing protocol to get back the possibility of advertising the prefix.
05-17-2018 02:32 PM
05-17-2018 11:47 PM
Hi RJI,
that is great news. Would you mind paste your code?
05-18-2018 05:27 AM
Here is the FlexVPN specific configuration. I've used the ou field in the branch spoke router's to determine role (primary/secondary), this needs to match the IKEv2 authorization policy. Hopefully it should be self explanatory.
BRANCH SPOKE-1 CONFIGURATION
crypto pki trustpoint VPN_TP
subject-name CN=branch-1-1.lab.net,OU=Branch-Primary,O=LAB,ST=London,C=GB
BRANCH-1-1#show cry pki certificates
Certificate
Status: Available
Certificate Serial Number (hex): 61176E6B000000000094
Certificate Usage: General Purpose
Issuer:
cn=lab-PKI-CA
dc=lab
dc=local
Subject:
Name: branch-1.lab.net
cn=branch-1-1.lab.net
ou=Branch-Primary
BRANCH SPOKE-2 CONFIGURATION
crypto pki trustpoint VPN_TP
subject-name CN=branch-1-2.lab.net,OU=Branch-Secondary,O=LAB,ST=London,C=GB
BRANCH-1-2#show crypto pki cert
Certificate
Status: Available
Certificate Serial Number (hex): 61403DAC000000000096
Certificate Usage: General Purpose
Issuer:
cn=lab-PKI-CA
dc=lab
dc=local
Subject:
Name: branch-1-2.lab.net
cn=branch-1-2.lab.net
ou=Branch-Secondary
HUB CONFIGURATION
aaa authorization network FLEX local
!
crypto ikev2 name-mangler NM
dn organization-unit
!
crypto ikev2 profile IKEV2_PROFILE
aaa authorization group cert list FLEX name-mangler NM
!
crypto ikev2 authorization policy Branch-Primary
route set interface
route set access-list LOCAL_NETWORK
route accept any distance 10
crypto ikev2 authorization policy Branch-Secondary
route set interface
route set access-list LOCAL_NETWORK
route accept any distance 15
BEFORE, Hub has routes learnt from both Branch Spoke routers
HQ-RTR#show ip route 10.10.1.0
Routing entry for 10.10.1.0/24
Known via "static", distance 1, metric 0 (connected)
Tag 1
Redistributing via eigrp 1
Advertised by eigrp 1
Routing Descriptor Blocks:
directly connected, via Virtual-Access2, permanent
Route metric is 0, traffic share count is 1
Route tag 1
* directly connected, via Virtual-Access1, permanent
Route metric is 0, traffic share count is 1
Route tag 1
AFTER, Primary Branch Spoke router UP
HQ-RTR#show ip route 10.10.1.0
Routing entry for 10.10.1.0/24
Known via "static", distance 10, metric 0 (connected)
Tag 1
Redistributing via eigrp 1
Advertised by eigrp 1
Routing Descriptor Blocks:
* directly connected, via Virtual-Access1, permanent
Route metric is 0, traffic share count is 1
Route tag 1
HQ-RTR#
AFTER, Secondary Branch Spoke UP, Primary DOWN
*May 18 12:14:33.884: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
HQ-RTR#
HQ-RTR#show ip route 10.10.1.0
Routing entry for 10.10.1.0/24
Known via "static", distance 15, metric 0 (connected)
Tag 1
Redistributing via eigrp 1
Advertised by eigrp 1
Routing Descriptor Blocks:
* directly connected, via Virtual-Access2, permanent
Route metric is 0, traffic share count is 1
Route tag 1
HTH
05-19-2018 01:07 AM
Hi RJI,
thank you. That helped me a lot.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide