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: 184.108.40.206
DMVPN Hub 2: 220.127.116.11
NMS public IP: 18.104.22.168
Network admins group public IP: 22.214.171.124
DMVPN Spoke: 126.96.36.199 (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:
12345678 object-group network DMVPN-HUBShost 188.8.131.52host 184.108.40.206ip access-list extended ACL-INTERNET-INBOUNDpermit udp object-group DMVPN-HUBS eq 4500 host 220.127.116.11 eq 4500permit udp object-group DMVPN-HUBS eq 500 host 18.104.22.168 eq 500permit esp object-group DMVPN-HUBS host 22.214.171.124
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:
1 permit icmp host 126.96.36.199 host 188.8.131.52
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:
12 permit icmp host 184.108.40.206 host 220.127.116.11permit tcp host 18.104.22.168 host 22.214.171.124 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
123456789101112 interface FastEthernet0 !Inside192.168.1.1 255.255.255.0ip nat insideinterface FastEthernet1 !Outsideip 126.96.36.199 255.255.255.0ip nat outsideip access-list extended ACL-TO-NATpermit ip 192.168.1.0 0.0.0.255 anyip 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.
1234 ip inspect name SPOKE httpip inspect name SPOKE httpsip inspect name SPOKE icmpip inspect name SPOKE ftp
Next we apply it on the outside interface, in the outbound direction.
12 interface FastEthernet1ip 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.