DMVPN + 3845 network-list / access control - Help!

[gloubier]

Hi,

We currently have a setup with 500 VPN connections ( with ezvpn and connected to a Cisco 3030 ) and we bought a 3845 because the 3030 his getting old.

In the 3030 we used "network-list" to control who can access who.

With the 3845 we want to use DMVPN but we don't want everybody to be able to access everybody.

Is there a way to control that, I know there's no "network-list" in the 3845 but maybe there's something similar or any other great idea.

Feel free to help!

Thank you!

[gloubier]

And in our lab we currently have 4 Cisco 871 connected to the 3845 using DMVPN.

So this part is working fine.

I trying to figure out what we could do about the access control for each DMVPN connections.

Thanks!

[gloubier]

Hi,

Nobody have any idea of what I could do?!

Your help will be really appreciate.

Thanks.

[mmelbourne]

Have you engineered your DMVPN to disallow the dynamic creation of spoke-to-spoke tunnels, thereby forcing all traffic through the hub(s)? If so, you could simply apply an ACL to the mGRE tunnel interface at the hub to control access.

[gloubier]

No I didn't, how you do that ( the DMVPN part, I'm ok for the ACL )?

Thanks for your reply.

[mmelbourne]

The exact mechanism is subtly different depending on which phase of DMVPN is in use. However, a point-to-point GRE tunnel on the spokes will prevent any dynamic spoke-spoke tunnels being created. Are you just advertising a summary (or default) route towards your spokes?

Please rate helpful posts!

[gloubier]

I agree a point-to-point GRE tunnels could be another options, but we have 500+ routers so it's a lot of tunnel to create one by one.

We're using EIGRP for routing.

But I thought that maybe there's a good/easy way of having DMVPN on all routers and just block the access to each VPN we don't want to have dynamic tunnels to other spokes and open the access to each spokes who can built a tunnel to other spokes.

Am I right to think like that?

Thanks

[mmelbourne]

If you have a p2p GRE tunnel on the spoke (rather than an mGRE interface), then spoke-to-spoke connections will not be formed and all traffic will traverse the hub.

It is possible to have a mGRE on the spokes when there are multiple hubs for resiliency within one DMVPN network (resiliency can also be achieved with dual hubs and two DMVPN networks, but the spokes require two tunnel interfaces, but this may provide more options for load balacing by tweaking routing metrics). It's still possible to have this arrangement and prevent spoke-to-spoke traffic.