| [Config] DMVPN works, restrictions needed... Hi! I have a DMVPN network configured, it works, but the traffic is going further than I would like, and I am currently at a loss as what I should use to restrict the traffic...
I have this network: »666kb.com/i/balbhqx046e6fly3p.jpg (26kb jpeg). At the right there is currently one branch router, a 851 (more branches will be configured shortly). The two routers on the left are both 871w. The dmvpn is working, I can reach all computers and routers from my work-pc (on one of the 192.168 networks), but they can also reach mine. A pc in the branch office can reach my nas-drive, for example. I don't want to let that happen. Oh: the computers in the brances should not be able to use the internet...
So: what would be the best method to work with the dmvpn (main traffic will be VNC-like and SQL-sync), so that the branch devices will only be able to talk to the network in the main office, the computers in the main office should be able to get onto the internet and contact the branches, and I should be able to do all, but I don't want to be reached by either of those networks...
Thanx in advance for some tips!
--
Using a Cisco 871w @home on a 16mbit cable-isp in Vienna, Austria. On broadband since 1997... |
|
 TomS_Git-r-donePremium,MVM
join:2002-07-19
Ireland
kudos:1 | You can use an ACL (inbound on the cloud side of your router) to stop people from accessing certain devices on your network, and only allow in what you want.
For example, so that TCP sessions will be able to establish and be maintained you could have a rule such as the following:
permit tcp any <my subnet> established
This will allow TCP sessions to establish, and be maintained, while your only other rule might be "deny ip any any", meaning that you'll be able to get out of your network to everything remotely, but no one will be able to get in.
This of course doesnt take into account UDP, which is not session based, so you'd need to add extra rules specifically for each port that needs to be left open.
Alternatively, NAT would also achieve a similar result, without having to muck around with ACL rules. By NATing traffic between the LAN segment and the DMVPN cloud, you'll be able to access everything in your DMVPN network, but without port forwards in place, no one will be able to get back into your network.
Let me know if you require further clarification. |
|
| Hi!
Sorry for not answering, but I only managed it today to try it.
And... It works! Thanx!
My current version of the ACL:
access-list 110 remark Tunnel-Firewall: TCP-Enabled...
access-list 110 permit eigrp any any
access-list 110 permit icmp any any
access-list 110 permit tcp any 192.168.10.0 0.0.0.255 established
access-list 110 permit tcp any 192.168.120.0 0.0.0.255 established
access-list 110 deny ip any any
it is in the Tunnel0 on the incoming side:
interface Tunnel0
bandwidth 1000
ip address 10.0.0.5 255.255.255.240
ip access-group 110 in
.
.
.
I let ICMP through, so I can check if the connections and tunnels are all up, but they can't reach my devices (NAS, Printer) anymore...
Thanks again!
Ardjan
--
Using a Cisco 871w @home on a 16mbit cable-isp in Vienna, Austria. On broadband since 1997... |
|
TomS_Git-r-donePremium,MVM
join:2002-07-19
Ireland
kudos:1 | Glad to hear it works. :)
You may have problems with UDP based applications, but if you do, you'll need to add some rules that permit UDP packets through. e.g. if you connect to a host on UDP port 5100, your current ACL wont allow packets back into your network.
You'll need to add a rule similar to the following to allow those packets in:
access-list 110 permit udp <remote subnet> eq 5100 any
This allows UDP packets on port 5100 from to reach any other device. You can lock this down even further by replacing "any" at the end with "host x.x.x.x" to lock it down to a specific host, or "x.x.x.x 0.0.0.255" to lock it down to a specific /24.
You might just need to play around with it a bit to get it right, and we'll always be here if you run into problems along the way. Just make sure that you add new rules before your "deny ip any any" line otherwise they'll never match. :) |
|
| reply to Ardjan
What ios version are you using with the DMVPN? i worked with Cisco TAC and after several different ones we finally came up with 12.4 15 T9 with a nat fix in place.
We use cisco zone based firewall with DMVPN and it all works pretty good. Once you understand the zbfw it makes things a littler easier to work with.
»www.cisco.com/en/US/products/ps6···6dd.html |
|
| Currently there are two versions (I should put them all on the same version...): The hub has currently 12.4(15)T1 and the spokes currently 12.4(15)T7.
--
Using a Cisco 871w @home on a 16mbit cable-isp in Vienna, Austria. On broadband since 1997... |
|
| reply to Ardjan
FYI we had problems with 15 t7 and t8 with nat. Also had problems with 20 t3 and 22t2 with the hubs only with nhrp. So far t9 with a a skinny tcp port 2000 fix seems good! |
|
| 12.4.24T (allegedly) fixed the NHRP crashes after i reported it to the TAC over 9000 times. Not running mGRE anymore so i can't really confirm. |
|
| Yea i had heard that. My TAC guy was just a little worried about new features introducing new bugs in the 24 train, plus the fact of it being a first release with no bug fixes yet. Also in my testing moving up from the 15 train to the 20 or 22 i noticed several changes in the zbfw, dmvpn, and QOS that would have added a lot more work to change over ~120+ routers. The 15 T9 just requires a simple reboot, where the others required serveral config changes. I really hope this stays stable and we can stick with it for a while. |
|
