Forcing all traffic through Public Interface / Tunnel

I was interested in possibly moving off of our leased circuits in favor of DMVPN for our remote offices. I checked out the very helpful tutorials, but had a question regarding security. I noticed that in the IPSEC for DMVPN there is no mention of a crypto map. I wanted to make sure that our remote routers place ALL traffic down the encrypted tunnels and that no connections are accepted from any unauthorized sources / services on the public side. So my question is two fold: should I setup zone based firewall that only accepts incoming GRE from authorized public IPs, or would a straight ACL make more sense? Furthermore, how do I force all internally sourced traffic through the tunnel? eg I don’t want the users at remote sites to be able to access the internet directly

Hi @enewburn,

Apologies for the delay in replying. This is a great question and not specific to DMVPN. There are two main ways to for a router to decide it should place traffic into a VPN tunnel:

  1. Matches some list, e.g. ACL

  2. Matches a route with a next hop or exit interface

In the case of older IPSec point-to-point VPNs crypto maps were traditionally used as ACLs to determine which traffic to catch. This is not a very scalable or easily modifiable solution so was largely replaced with routing based design. In this case we create a tunnel construction for the VPN and route data into those tunnels.

In your case it would be sufficient to carefully route data but you could also enforce some reasonable ACLs and route filters on end-points so that any routing mistakes have limited impact. If the remote routers are already running ZBF you can leverage that existing config, otherwise traditional interface ACLs can be used to keep things simple.

As always, there is a trade-off in security between making things detailed enough to meet requirements vs simple enough to document and maintain. To prevent GRE connection attempts from non-truster routers, you could use a single ACL that permits tunnels from a CIDR block that you have reserved for this purpose, rather than listing each individual IP as a /32. You can then re-use this single line as boilerplate config on many routers and, when you need to update it in the future, it’s easy to do.

Kind regards,

Jon I have no idea how I managed to miss this reply for the length of time that went by. Thank you for the response. As it happens the DMVPN project got delayed on account of a major migration off Checkpoint Security Appliances in favor of Cisco’s FTD platforms. Now that that insanity has quieted down we’re going revisiting the DMVPN solution for our end points. Thanks again for the reply. We’ll be starting from scratch, again - so this will be helpful