DMVPN with Crypto Map Backup

So, since I tend to plan and design for worst case scenarios, I was thinking… What if you need to do maintenance on a DMVPN Hub Router, and you only have a single router terminating those DMVPN Spoke connections at that site?  I know, I know… It’s a Cisco Router, and we probably have 2 of them doing HSRP and BGP or something fancy, and we never have to do code upgrades to fix vulnerabilities or memory leaks (riiight); but let’s just pretend.  What if you have an ASA available for “unleaded” (Crypto Map based) IPSec and AnyConnect VPN access to your main site, that you may or may not have migrated Site-to-Site connectivity off of to get your fancy DMVPN network setup on the Hub router.  Would it work?

The question we are actually asking here is, “Can the DMVPN Spoke-side be configured to leverage DMVPN and also tunnel out with a straight old-school Crypto Map based static IPSec tunnel for failover?”  Let me qualify that last statement real quick… Of course your DMVPN Spoke [I really hope] is already running IPSec to encrypt the GRE transport of the tunnel…  So, assuming you live in the reality that we all do, of creepers being on the internet, and you are establishing an Encrypted DMVPN tunnel to your hub leveraging IPSec; can the DMVPN spoke create a second independent IPSec tunnel that doesn’t jack up your DMVPN config?  Will it get confused?  Am I confused? Let’s think about this. 🤔

Why are we even using DMVPN?  Well because I’m a CCIE candidate (at the time of writing this article in 2015) and it’s on the blueprint.  [crickets] Oh, right… Well, one of DMVPN’s major advantage over traditional Crypto Map IPSec is its ability to build routed tunnels that support every engineer’s favorite routed protocol… multicast.  Yes, believe it or not we all do love multicast no matter how many times we have to keep referencing who the Static RP is vs an Auto-RP and how to replicate all your fancy mulitcasting with MSDP through different AS in BGP.  OK, enough of that; we can talk multicast in another post…

So big deal, we can push multicast traffic over these tunnels, now you can put someone on hold using your IP Phone and they can hear your hold music that’s being distributed via multicast.  Fantastic. Well, another benefit of having the tunnel supporting multicast is it’s ability of learning dynamic routes via your favorite routing protocol (EIGRP/RIP/OSPF,) {yes, bgp is fully supported for DMVPN but using unicast tcp port 179 is not helping my case here for multicast support lol}.  And lastly, DMVPN will save you from needing to create a full mesh of static site to site tunnels. Just pin up one static tunnel to your hub (in this example) and let NHRP and IPSec do the rest of the work for you. Thanks Technology!

Having NHRP resolve your NBMA (Public) IP Address to your Tunnel IP (Private) will allow the spoke routers to “automatically” build tunnels between each other on an as needed basis. Sounds pretty sweet right? Gotta love that first redirect packet sent back from the Hub to the Spoke to find the shortcut defined to build that Dynamic Spoke-to-Spoke connectivity.

So now I get why DMVPN is kind of nice, but how would the backup Crypto Map IPSec Tunnel we spoke about earlier ever kick in if the routing table already has routes being learned via the DMVPN Hub?  If we are running both DMVPN and Crypto Map based IPSec at the same time, won’t the router get confused?  After all, the Tunnel interface is virtual in nature, and is really using the ISP facing physical interface to communicate with the DMVPN Hub router. Hmmmm… If only there were an order of operations…

So, once the DMVPN Hub goes down for its imaginary maintenance, the peering between the Hub and Spoke will go down, which will withdraw the dynamic route(s) which were learned from the Hub on the spoke router. This will also will break the neighbor relationship that was previously in place between the Hub and Spoke router (assuming we were running a routing protocol over DMVPN).  So now, as long as you have either a static route configured to your VPN endpoints, or are routing quad zeros (0.0.0.0) on the DMVPN Spoke router, everything will get routed to the ever so existing realm of the internet.  But, what if the traffic we are trying to route, wasn’t actually destined for the internet?  What if, your DMVPN Spoke, who was just told by the Hub “Goodbye; I’m no longer routing with you”, could build another encrypted tunnel to another VPN endpoint, that was fully operational, but was an “old school style” static Crypto Map IPSec Tunnel?

But wait a minute; didn’t we establish earlier that we are already using IPSec to secure our DMVPN tunnels due to the creepers on the internet?  Won’t trying to encrypt outside of our tunnel interface mess up or conflict with that policy?  Well… It shouldn’t.  Right?

Since we apply the IPSec Protection Profile on the Virtual Tunnel interface of the router, what is stopping us from applying another IKE and IPSec Profile on the physical link heading to our ISP hand off?  Interesting… But both the Tunnel and the ISP facing interface are the same thing; aren’t they?  Let’s see how it would be configured in the lab.

So here’s the topology. Pretty basic, nothing to exiting to write home about here:

We want to setup the DMVPN SPOKE router (top left corner) with something similar to the following syntax for additional IKEv1 (ISAKMP) & IPSec configs:

NOTE: This is assuming we have already setup the ASA Firewall with the relevant non crypto config (Tunnel Group, NAT Exemptions, Proxy Lists, Routing, ETC). Also, I encourage you to “step your encryption game up” from the super weak examples listed below.

Phase 1 (ISAKMP) Steps.

• Create Additional ISAKMP policy to be used for connecting to the DMVPN Spoke.

crypto isakmp policy 2
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400

• Define the ISAKMP PSK config to be used for connecting to the DMVPN Spoke.

crypto isakmp key $UP3R$3CR3+P$k address W.X.Y.Z

Phase 2 (IPSec) Steps.

• Create your ACL for interesting traffic to be pushed over the vpn

ip access-list extended VPN-BACKUP
permit ip MY.LOCAL.NETWORK MY.LOCAL.INV-MASK REMOTE.SIDE.NETWORK REMOTE.SIDE.INV-MASK

• Create your new Transform Set

crypto ipsec transform-set NAME-YOUR-TS-SET PARAMETERS-OF-TS

• Create your new Crypto Map

crypto map VPN-FAILOVER 10 ipsec-isakmp
set peer W.X.Y.Z
set transform-set NAME-YOUR-TS-SET
match address VPN-BACKUP

• Apply the new Crypto Map to your ISP facing interface

interface FastEthernet4
crypto map VPN-FAILOVER

• Don’t forget to modify your NAT Config on the router!

ip access-list extended SPOKE-NATS
deny ip MY.LOCAL.NETWORK MY.LOCAL.INV-MASK REMOTE.SIDE.NETWORK REMOTE.SIDE.INV-MASK
permit ip MY.LOCAL.NETWORK MY.LOCAL.INV-MASK any

Remember, the deny above in this access-list says please ignore the urge to be sent to the NVI interface to be natted.  Aka, the HQ location needs to route directly back to me with my private IP address; not the External NAT everyone else is using to read blog articles on this site and other items on the interwebs…

So there you have it. The answer is yes, we can do this. By having this additional config setup on your already existing DMVPN router, it will help you automatically fail over to your ASA (in the example above).

Hopefully you stuck with me through this and now have another alternative for fail over on top of your existing DMVPN setup.  Stay tuned for some more blogging and articles!

– This article was originally written back in September of 2015, and I finally got around to reviewing and wrapping it up now-ish… Keep learning and keep labbing – 51406