DMVPN with IPSEC but only want Spoke to Hub comms and no spoke to spoke

[CiscoPurpleBelt]

What would be the best way or approach. If you have  a lot of tunnels and you want to lessen the admin overhead and provide better scalability as well,  however you only want to allow Spoke to Hub comms, would DMVPN still be a good solution?

What would be best way to only allow Spoke/Hub comms would it be ACLs?

Also, if you want to migrate sites from communicating via regular IPSEC to IPSEC over DMVPN, would would be the best approach to change over? Should you just build additional ISPEC over DMPVN configs in addition to existing IPSEC then delete original tunnel once DMVPN tunnel connectivity is tested?

[balaji.bandi · Accepted solution]

You can deploy DMVPN Phase 1 only - So all spoke only connection with Hub, Hub have control.

Other side you can also have strict ACL they can not reach other also good protection.

Ohter side DMVPN is more like Hub and Spoke and gave flexibility to also spoke can aslo can interact with spoke with out Hub intervention.

Other suggestion if you looking more strict,- why deploy Site to Site VPN, so you have full control over each VPN.

[CiscoPurpleBelt]

Yes that was what I was thinking. If you only want Hub to spoke comms, doing DMVPN would just cut down the configs on the hub really be eliminating need for peer to peer IPSEC.
So you are saying why not just do normal Site to Site IPSEC instead of DMVPN?

[balaji.bandi]

If you want to more control over each link, if the spoke to spoke comms required, its each to manage in case of maintenance.

Not sure how many VPN we are considering to deploy here, if more VPN, DMVN simplifies your setup (make sure you have Dual HUB ) for redundancy for easy maintenance.

Look @Georg Pauwen (he is big ahead of me thinking the approach)  comments in eigrp with split horrizion config to restrict spoke to spoke config

[CiscoPurpleBelt]

Yes I was thinking maybe just leaving IPSEC site to site would keep things less complicated, although I still would build configs for each individual tunnel on the hub and/or HQ router and then on the remote sites routers.

[Cristian Matei · Accepted solution]

Hi,

    1. If you have many tunnels and want to reduce the admin overhead, clearly move towards DMVPN, and choose BGP or EIGRP as your overlay routing protocol

    2. If you want no spoke-to-spoke communication at all (either directly spoke-to-spoke or spoke-hub-spoke), your first step is to run DMVPN Phase1 (so point-to-point GRE tunnels on the spokes), and this way spokes cannot establish spoke-to-spoke direct communication. DMVPN Phase1 will only restrict spoke-to-spoke tunnels being formed, but spoke-to-spoke traffic will still be allowed, through the hub, if the routes are being advertised to the spokes. To restrict spokes being able to communicate, there are many options, but it depends on other factors:

             - if you advertise a default route from the hub downstream towards the spokes (and this has to be advertised for Internet access unless you have a proxy), you would need to configure ACL's to filter spoke-to-spoke traffic, and i would do it ingress on the spokes, to stop traffic there, as it doesn't make sense to go all the way up to the hub and costume BW to filter it there.

             - if there is no default route advertised to the spokes, configure route summarisation on the hub and do not advertise the spokes subnets out; this requires a good IP planning, as if spoke subnets cannot be summarised in order not to be included in the summary, it becomes unmanageable. Route-Filtering from the hub towards the spokes (and filtering spoke subnets) is a better option if summarisation is not easily achievable 

From the migration point of view, make DMVPN with IPsec functional, run EIGRP/BGP on top of it without actually advertising anything, just peering/adjacency being functional, and afterwards migrate site-by-site, test functionality, remove old config. If you use BGP you can further reduce admin overhead by configuring dynamic BGP peering on the hub, so you don't need to configure neighbor statements for all spokes.

Regards,

Cristian Matei.

Regards,

Cristian Matei.

[CiscoPurpleBelt]

Great thanks!
Yes there is a route for each particular spoke pointing to the transport provider IP/next hop.
What if I want to have two Hubs/router for redundancy. I am more familiar with using HSRP, what would be the better solutions to configure the two hubs to act as a primary and secondary or even utilize both to load balance?

[CiscoPurpleBelt]

Also, lets say a CSR1000v will be used as the Hub router. Would you still be able to use 2 CSR1000v hubs for redundancy (perhaps dual cloud) although there really is one physical connection to the transport provider default gateway?

[CiscoPurpleBelt]

Sorry just bouncing back to this topic again.
You stated "as if spoke subnets cannot be summarised in order not to be included in the summary, it becomes unmanageable." You mean summarize so spokes are not included?

"run EIGRP/BGP on top of it without actually advertising anything". So just advertise reachability to the peer addresses of the spokes to form the tunnel and that is it correct?

[Georg Pauwen · Accepted solution]

Hello,

what you could do is use EIGRP and disable split horizon on the hub, and keep the spokes from using NHRP dynamically (see the lines marked in bold below). As stated by others, the obvious purpose and benefit of DMVPN is the direct spoke to spoke communication, so if you don't want that, you might as well use point to point tunnels between the hub and each site...

HUB

interface Tunnel1
ip address 10.0.1.1 255.255.255.0
no ip redirects
ip mtu 1400
no ip next-hop-self eigrp 1
no ip split-horizon eigrp 1
ip nhrp authentication NHRPAUTH
ip nhrp map multicast dynamic
ip nhrp network-id 101
ip nhrp holdtime 300
ip nhrp redirect
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel key 101

SPOKE

interface Tunnel1
ip address 10.0.1.2 255.255.255.0
ip mtu 1400
ip nhrp authentication NHRPAUTH
ip nhrp map 10.0.1.1 10.10.10.1
ip nhrp map multicast 10.10.10.1
ip nhrp network-id 101
ip nhrp holdtime 300
ip nhrp nhs 10.0.1.1
ip nhrp server-only
ip nhrp shortcut
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/1
tunnel destination 10.10.10.1
tunnel key 101