Securing DMVPN Headend

[Scott Pettit]

Hi everyone,

Our DMVPN scenario is we're a managed IT provider and as such require constant access to our customer networks.  Presently our deployment has a DMVPN head end our side, and each customer is a spoke on the DMVPN.

To stop one customer seeing another, we have multipoint disabled and ACL's to the effect that our engineering VLAN can see all customer LAN's, and customer LAN's can only see our engineering VLAN.

Presently we require customers to have a static IP address as this enables us to restrict where DMVPN connections can come from.  This adds some cost as a lot of the ISP's charge for static IP addresses (where customers are on xDSL type connections).

DMVPN is quite happy to work with dynamic IP's on spokes, however my concern is if someone found out the crypto key from a spoke, in theory they can setup their own router anywhere and join our DMVPN.

Can anyone suggest a better way to secure this that might still allow dynamic endpoints?  I guess something that uses certificates might make sense.

Also with regards to our existing endpoints, while we have firewalling to prevent communication, ideally we'd like customer routes to be shared only between the head end and the spoke, presently OSPF shares routes from one spoke with routes from another spoke.  Is there a way to filter who sees what routes?

-Scott

[Marcin Latosiewicz]

Scott,

As I see this you have two questions here:

- Securing control plane (routing, IKE etc)

- Securing data plane (actual traffic)

Let me start at point #1.

- EIGRP (and RIP) has the option to allow or disable split horizon, with split hirizon disable you do not advertise routes back on the interface you've learned them, this would cause one spoke not to be aware (in routing terms) of others.

- You are correct using certificates is MUCH a better way, you still need to control access to your private RSA key (in term of it not being stolen). On top you can perform certificate authorization and gather additional settings for IKE session from RADIUS. (i.e. the ability to manage and change parameters from one/two places; the CA and RADIUS)

Regarding securing of data traffic, several options exists.

- You could check what sort of information you can push from certificate authorization (the last time I've done this was during my CCIE studies)

- Authentication proxy allows you to have control who accesses where and apply some settings, like a per-user ACL (from RADIUS for example)

On a separate note, if you need data separation within the tunnel you MIGHT consider running MPLS over DMVPN ;-)

Hope this helps,

Marcin

(edit: fixed typos)

[Scott Pettit]

Hi Marcin,

Good post.

Is there a way to achieve similar results with OSPF? We run it instead of EIGRP as a lot of the end points are SR500/800 series that support RIP or OSPF only, a couple support EIGRP. I've given though to various scenarios involving VRF's but these were either going to involve many tunnel interfaces or phenomenal amounts of configuration as we have about 200 spoke sites.

The only idea I had was filtering OSPF routes at the customer side. While we control their routers, I still prefer a scenario that filters on our end, so there is no chance of a customer reconfiguring their side and gaining access.

Certificates with RADIUS sounds perfect, we already run RADIUS for everything else - do you have any recommendations where I should begin reading? We run Microsoft NPS for RADIUS which we've extended to handle extra attributes.

I read a document on setting up the IOS Certificate Server, is this what I should use? We do run Active Directory so I suppose integrating with the MS Certificate Server would make management nice as I can revoke a certificate to kick a peer off.

-Scott

[Marcin Latosiewicz]

Scott,

OSPF is going to be trickier.

Your hub could have this configured:

http://www.cisco.com/en/US/docs/ios/iproute_ospf/command/reference/iro_osp1.html#wp1014184 (or neighbor database-filter counterpart)

All the spokes need same set of routes to reach destinations behind hub, so they can be static, no?

I'd need to check this in the lab but as you might imagine I have no time for extra stuff like this :[

Regarding cert authorization, I don't see too much in terms of possibility here:

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_cfg_auth_rev_cert_ps10591_TSD_Products_Configuration_Guide_Chapter.html#wp1135588

most attibutes you can send pertain to PKI not IKE.

For certificate authority, IOS CA works really well, I do advise you however to go for extranal storage (both certificated and CDP/OCSP). People do use MS CA and it works quite well, I do however would like you to be cautious, most notably about certificate templates and SCEP implmentation.

I do recommend using SCEP as it will allow you to easier enroll and re-enroll when time comes, just remember that OCSP/CDP needs to be available without VPNing in :]

M.