{"id":17,"date":"2025-03-04T20:33:36","date_gmt":"2025-03-05T01:33:36","guid":{"rendered":"https:\/\/thenetworksdown.com\/tnd\/?p=17"},"modified":"2025-11-26T11:33:29","modified_gmt":"2025-11-26T16:33:29","slug":"l02-legacy-dmvpn-with-ipsec-backup","status":"publish","type":"post","link":"https:\/\/thenetworksdown.com\/?p=17","title":{"rendered":"DMVPN with Crypto Map Backup"},"content":{"rendered":"\n

So, since I tend to plan and design for worst case scenarios, I was thinking\u2026 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\u2026 It\u2019s a Cisco Router, and we probably have 2 of them doing HSRP and BGP or something fancy, and we never<\/em> have to do code upgrades to fix vulnerabilities or memory leaks (riiight<\/strong>); but let\u2019s 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<\/em> have migrated Site-to-Site connectivity off of to get your fancy DMVPN network setup on the Hub router.  Would it work?<\/p>\n\n\n\n

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<\/em>] is already running IPSec to encrypt the GRE transport of the tunnel\u2026  So, assuming you live in the reality that we all do, of creepers being on the internet, and you are establishing an Encrypted<\/em> DMVPN tunnel to your hub leveraging IPSec; can the DMVPN spoke create a second independent IPSec tunnel that doesn\u2019t jack up your DMVPN config?  Will it get confused?  Am I confused? Let\u2019s think about this. 🤔<\/p>\n\n\n\n

Why are we even using DMVPN?  Well because I\u2019m a CCIE candidate (at the time of writing this article in 2015<\/em>) and it\u2019s on the blueprint.  [crickets<\/em>] Oh, right\u2026 Well, one of DMVPN\u2019s major advantage over traditional Crypto Map IPSec is its ability to build routed tunnels that support every engineer\u2019s favorite routed<\/strong> protocol\u2026 multicast.  Yes, believe it or not we all do<\/em><\/strong> 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\u2026<\/p>\n\n\n\n

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\u2019s being distributed via multicast.  Fantastic. Well, another benefit of having the tunnel supporting multicast is it\u2019s ability of learning dynamic routes via your favorite routing<\/strong> 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}<\/code><\/em>.  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<\/strong>!<\/p>\n\n\n\n

Having NHRP resolve your NBMA (Public<\/em>) IP Address to your Tunnel IP (Private<\/em>) 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.<\/p>\n\n\n\n

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\u2019t 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…<\/p>\n\n\n\n

So, once the DMVPN Hub goes down for its imaginary<\/em> 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<\/em>).  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\u2019t actually destined for the internet?  What if, your DMVPN Spoke, who was just told by the Hub \u201cGoodbye; I\u2019m no longer routing with you\u201d, could build another encrypted tunnel to another VPN endpoint, that was fully operational, but was an “old school style” static Crypto Map IPSec Tunnel?<\/p>\n\n\n\n

But wait a minute; didn\u2019t we establish earlier that we are already using IPSec to secure our DMVPN tunnels due to the creepers on the internet?  Won\u2019t trying to encrypt outside of our tunnel interface mess up or conflict with that policy?  Well\u2026 It shouldn\u2019t.  Right<\/strong><\/em>? <\/p>\n\n\n\n

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\u2026 But both the Tunnel and the ISP facing interface are the same thing; aren\u2019t they<\/strong><\/em>?  Let\u2019s see how it would be configured in the lab.<\/p>\n\n\n\n

So here\u2019s the topology. Pretty basic, nothing to exiting to write home about here:<\/p>\n\n\n\n

\"DMVPN\"<\/figure>\n\n\n\n

<\/a><\/p>\n\n\n\n

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

NOTE:<\/em><\/strong> <\/em>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<\/em>” from the super weak examples listed below.<\/p>\n\n\n\n

Phase 1 (ISAKMP) Steps.<\/strong><\/p>\n\n\n\n