For organizations that have many remote offices a DMVPN solution is a great option. You can purchase a cheap DSL or cable modem based solution then establish a dynamically built encrypted tunnel back to the corporate office or Data Center(s). The hubs should be located in a DMZ behind a firewall at the Data Center for protection from internal and external hosts. However the spokes are going to, typically, be directly connected to the Internet. How do you secure them? Let me give you few ideas on how to do this.
Here is the information we are going to use to build these configurations.
DMVPN HUB 1: 126.96.36.199
DMVPN Hub 2: 188.8.131.52
NMS public IP: 184.108.40.206
Network admins group public IP: 220.127.116.11
DMVPN Spoke: 18.104.22.168 (Assuming static public IP)
Internal branch network: 192.168.1.0/24
What traffic needs to originate from somewhere on the Internet and access the router? Only a limited number of addresses on your network is all that should be allowed. First, you will need to allow packets from your DMVPN hubs for the protocols used in DMVPNs. Using an object group in the access list should look something like this:
object-group network DMVPN-HUBS host 22.214.171.124 host 126.96.36.199 ip access-list extended ACL-INTERNET-INBOUND permit udp object-group DMVPN-HUBS eq 4500 host 188.8.131.52 eq 4500 permit udp object-group DMVPN-HUBS eq 500 host 184.108.40.206 eq 500 permit esp object-group DMVPN-HUBS host 220.127.116.11
Now you need to allow your Network Management System (NMS) to ping the public interface to determine if the device is up or down. So we add:
permit icmp host 18.104.22.168 host 22.214.171.124
Having a static IP address on the spoke makes it easy to monitor and access it to make changes to the spoke, especially when making changes to the DMVPN tunnel. You need to be able to ping and SSH to the public address from the public IP that the network administrators come from. You should use a different public address for your network administrators than your general user population uses. Now we add:
permit icmp host 126.96.36.199 host 188.8.131.52 permit tcp host 184.108.40.206 host 220.127.116.11 eq 22
So we are only allowing traffic to come into the spoke from the two (or more) hubs, your monitoring system, and the network administrator’s public IP. If you tunnel all of your Internet bound traffic across the DMVPN tunnel, then the above is all you really need.
If you want to allow Internet bound traffic to go out the local Internet connection we need to monitor that traffic and allow the return packets to bypass the access list and come back in. We can do this one of two ways. In this post I will go over the easier, simpler way and save the more complicated for Part 2. This example only has one inside interface and one outside interface.
First we have to NAT/PAT our internal addresses to a public address on the Internet. This will be a simple PAT configuration to the outside interface IP address
interface FastEthernet0 !Inside 192.168.1.1 255.255.255.0 ip nat inside interface FastEthernet1 !Outside ip 18.104.22.168 255.255.255.0 ip nat outside ip access-list extended ACL-TO-NAT permit ip 192.168.1.0 0.0.0.255 any ip nat inside source list ACL-TO-NAT interface FastEthernet1 overload
While NAT gives you translation from an RFC1918 address to a publicly routable IP, it does not allow the return traffic to bypass the access list on the outside (Internet) interface and come back in. To do this a process on the router needs to inspect, or monitor, this traffic as it leaves and dynamically add entries to allow this traffic to come back. You will not see these dynamic entries in the access list itself. We will use the feature called Context-Based Access Control (CBAC) to monitor this traffic. CBAC allows you to configure an inside and an outside zone. For this example, let’s say we want to monitor and allow return traffic for HTTP, HTTPS, ICMP, and FTP.
First, we have to define what we are going to inspect.
ip inspect name SPOKE http ip inspect name SPOKE https ip inspect name SPOKE icmp ip inspect name SPOKE ftp
Next we apply it on the outside interface, in the outbound direction.
interface FastEthernet1 ip inspect SPOKE out
Now the router will monitor traffic going out of that interface and dynamically allow the return traffic matching these protocols back in. To see what return traffic is allowed back in you can use the command ‘show ip inspect sessions’ and you can clear specific sessions with ‘clear ip inspect session session-id ‘.
This works great for spokes that have a single inside and a single outside zone or interface. What if you have an inside data, wireless, guest wireless, etc that you want to allow some traffic out and some traffic between networks internally, but not everything. Or what if you have a device at the branch you have to put into a DMZ but don’t want to give it access to anything internally. CBAC is not very flexible for those scenarios. In Part 2 we will go over one of these types of scenarios.