cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4187
Views
10
Helpful
12
Replies

DMVPN, deny traffic from spoke's

Bart Kersten
Level 1
Level 1

Hi,

This may be a weird qeustion but im testing DMVPN with multiple scenarios.

At the moment i have 1 Hub with 4 spoke's they are all working properly. We are testing this because we have a lot of customers that dont have a fixed IP on the outside, so everytime an IP changes we have to configure to VPN to our HQ all over again. DMVPN seems like a perfect solution..

Now my goal is, to configure DMVPN from all our customers (spoke's) to our HQ. But i dont want the customers to have access to our LAN and neither i want them to have access to other spoke's. The only one who has full permitted access to all LAN's is the HQ (Hub).

What is the best way to achieve this? do i start working with access lists or can i do it with EIGRP in some way? And do i apply ACL's on the tunnels or ethernet interfaces?

Or maybe is DMVPN not the best solution? All comments and advice ar ver appreciated!

Thanks already,

Bart

2 Accepted Solutions

Accepted Solutions

In this scenario, you better use VTI/DVTI tunnels. On the Hub you can accept VPNs from any peers with the DVTI-config. The spokes use traditional VTI-tunnels. The virtual-template on the hub ( which is used to build the virtual-access-interfaces per spoke can be configured with a default-ACL (deny ip any any) and a CBAC-firewall-rule that inspects your outgoing traffic to allow the return-packets. You even could use the zone-based-firewall, but that seem like overkill in this setup.

Sent from Cisco Technical Support iPad App

View solution in original post

shikhsha
Level 1
Level 1

Hi Bart,

You can definately use DMVPN. Also it is pretty simple in configuration what you want. All you need to do is run EIGRP in DMVPN and enable split horizon. When split horizon is enabled none of the routes learned from spokes will be advertised to other spokes so there won't be any spoke to spoke communication but hub will have routes to all destinations behind the spokes.

Now as far as your second requirement of not allowing spokes to access resources behind hub is concerned just apply a simple ACL on the HUB's internal interface blocking the access.

Shikhar Sharma

CCIE Security # 29741

Cisco TAC - VPN Team

View solution in original post

12 Replies 12

Bart Kersten
Level 1
Level 1

I have already did some research, and it is possible,

Configure the spokes with the command "tunnel mode gr ip" and dont use dynamic mapping un NHRP.

Any more suggestions are welcome

Thanks

Sent from Cisco Technical Support iPhone App

In this scenario, you better use VTI/DVTI tunnels. On the Hub you can accept VPNs from any peers with the DVTI-config. The spokes use traditional VTI-tunnels. The virtual-template on the hub ( which is used to build the virtual-access-interfaces per spoke can be configured with a default-ACL (deny ip any any) and a CBAC-firewall-rule that inspects your outgoing traffic to allow the return-packets. You even could use the zone-based-firewall, but that seem like overkill in this setup.

Sent from Cisco Technical Support iPad App

Bart Kersten
Level 1
Level 1

Great awnser!

I did a little research on vti VPN, but couldnt really find a good article to do some study, can you provide me with one?

Thanks!

Sent from Cisco Technical Support iPhone App

start with the conf-guide on VTIs:

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_vpnips/configuration/15-0m/sec-ipsec-virt-tunnl.html

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

Bart Kersten
Level 1
Level 1

Thanks,

I will look in to this. One more qeustion (maybe a dumb one) but i have never configured vti tunnels, from my point of view it seems a lot easier then DMVPN, is this true or am i mistaking?

Thanks for your help!

Sent from Cisco Technical Support iPhone App

Yes, it is easier if you only need this simple setup. But it's not directly comparable as you can't do fancy stuff like automatic spoke-to-spoke with that. But the general setup with virtual-access-interfaces is definitely the future (as the new FlexVPN also uses them; but these are probably not usable in your setup as all custumers should run then ISR G2 with 15.2T).

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

shikhsha
Level 1
Level 1

Hi Bart,

You can definately use DMVPN. Also it is pretty simple in configuration what you want. All you need to do is run EIGRP in DMVPN and enable split horizon. When split horizon is enabled none of the routes learned from spokes will be advertised to other spokes so there won't be any spoke to spoke communication but hub will have routes to all destinations behind the spokes.

Now as far as your second requirement of not allowing spokes to access resources behind hub is concerned just apply a simple ACL on the HUB's internal interface blocking the access.

Shikhar Sharma

CCIE Security # 29741

Cisco TAC - VPN Team

Bart Kersten
Level 1
Level 1

Hi shikhar,

That is the awnser i was looking for! Karsten has also gave me some great unput on VTI tunnels but since i already have the config's for a DMVPN solution this is absolutly the best awnser!

I will edit the configs when i have the chance and to tes everything!

Thanks alot Shikhar! and Karsten thanks for pointing me to VTI tunnels, these are new to me and i now have some studying to do hehe!

Be aware of the consequences of using DMVPN in that scenario. With a simple DMVPN-setup customer A can connect to the network of customer B after a little social engineering and some static mappings. The customer-router has to be included into the securing-strategies. Can you explain that to your customer that there are other customers in that shared network?

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

Karsten,

I stumbled upon this thread after doing some research on using DMVPN vs.IPsec to customer sites, very similar scenario to Bart's situation.  I've successfully have an IPsec tunnel to our first customer site, limiting access only to few servers that reside in the DMZ.  However, I've been asked to use DMVPN in tandem with the IPsec tunnel.  In my lab, I've already noticed both spoke to spoke traffic is going through right away, not ideal.  I've read that putting in EIGRP and split horizon is the answer.  I've also read that OSPF can be used, but only if the spoke routers are less than 100 as opposed to EIGRP that can handle 500 plus, depending the hardware used. 

Would still prefer to do this kind of setup using DVTI deployment over DMVPN to deploy "cookie cutter" remote sites that can connect back over the customer network (static/dynamic internet handoff) dynamically to my HUB router?

Thanks,
Andrew

Bart Kersten
Level 1
Level 1

That has crossed my mind too, at the moment it doesnt really matter. Because we are still in the testing fase. The awnser, to my qeustion is it possible? Is awnsered. But you gave me some great input on my qeustion is this the best solution? You adviced my on using dvti. Great awnser

I will take all advice en solutions in consideration. This week i am going to build a lab on vti tunnels to test it out.

Thanks Karsten!

Sent from Cisco Technical Support iPhone App

That's what this community is all about. Give hints and enable new thoughts ... ;-)

And the securing I'm talking about is also possible with DMVPN, but with DVTIs it's a little bit easier. For your planning take also other things into account like authentication with PSK (not really good as you would need wildcard PSKs) vs. RSA-Sig.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: