In previous articles on this site, DMVPN, Cisco IOS Zone based Policy Firewall (ZBF) and Cisco IOS Network Address Translation (NAT) have all been considered separately but what we will do in this article is to configure them all together on one router.

There are instances when it is desirable to enable firewall services (ZBF) on the same router that is configured with DMVPN so as to provide extra security. It is also possible that this same router will have NAT configured for internal users to access the Internet. To reproduce such a scenario, we will use the following network setup:

Before we begin our configuration, we need to define the security policy:

  • DMVPN should be configured between the Hub and two spoke routers. EIGRP should be used to advertise the LAN subnets among these routers.
  • Internal users on all routers should be able to access the Internet. Use NAT Overload to achieve this.
  • ZBF should be enabled on the Hub router.

Let’s pause to discuss the ZBF policy. The number of zones you define for your ZBF policy will depend on your particular circumstance. Usually, you have two options: two zones (e.g. inside and outside) or three zones (e.g. inside, outside, and dmvpn).

CCNA Training – Resources (Intense)

The first option means that the DMVPN tunnel will be part of the inside zone; thus, there will no restriction between traffic from the DMVPN tunnel to the inside. This may not be wise from a security standpoint. The second option of three zones means that a policy must be configured for traffic to flow between the dmvpn and inside zones, which is a better alternative.

We will go with the three-zone option and now we can define our ZBF policies as follows:

  • Inspect TCP, UDP and ICMP traffic from the inside zone to the outside zone.
  • Allow SSH to inside host 10.1.1.100 from the outside zone.
  • ICMP and HTTP traffic should be allowed from the dmvpn zone to the inside zone.
  • ICMP, SSH and HTTP traffic should be allowed from the inside zone to dmvpn zone.

I prefer to build my configuration in a modular fashion so let’s start with the DMVPN and NAT configuration. ZBF can be quite tricky so we will add that configuration last.

The configuration on the HUB router is as follows:

hostname HUB
!
interface FastEthernet 0/0
 ip address 192.0.2.1 255.255.255.0
 ip nat outside
!
interface FastEthernet 0/1
 ip address 10.1.1.1 255.255.255.0
 ip nat inside
!
crypto isakmp policy 10
 hash sha
 encryption aes
 authentication pre-share
!
crypto isakmp key dmvpn-cisco address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set DMVPN_TSET esp-aes esp-sha-hmac
!
crypto ipsec profile DMVPN_IPSEC_PROF
 set transform-set DMVPN_TSET
!
interface Tunnel0
 ip address 172.16.1.1 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 no ip split-horizon eigrp 10
 no ip next-hop-self eigrp 10
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN_IPSEC_PROF
!
router eigrp 10
 no auto-summary
 network 172.16.1.0 0.0.0.255
 network 10.1.1.0 0.0.0.255
!
ip access-list extended NAT
 permit ip 10.1.1.0 0.0.0.255 any
!
ip nat inside source list NAT interface FastEthernet0/0 overload

The configuration on the SPOKE1 router is as follows:

hostname SPOKE1
!
interface FastEthernet 0/0
 ip address 192.0.2.2 255.255.255.0
 ip nat outside
!
interface FastEthernet0/1
 ip address 10.2.2.2 255.255.255.0
 ip nat inside
!
crypto isakmp policy 10
 hash sha
 encryption aes
 authentication pre-share
!
crypto isakmp key dmvpn-cisco address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set DMVPN_TSET esp-aes esp-sha-hmac
!
crypto ipsec profile DMVPN_IPSEC_PROF
 set transform-set DMVPN_TSET
!
interface Tunnel0
 ip address 172.16.1.2 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp map 172.16.1.1 192.0.2.1
 ip nhrp map multicast 192.0.2.1
 ip nhrp network-id 1
 ip nhrp nhs 172.16.1.1
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN_IPSEC_PROF
!
router eigrp 10
 no auto
 network 172.16.1.0 0.0.0.255
 network 10.2.2.0 0.0.0.255
!
ip access-list extended NAT
 permit ip 10.2.2.0 0.0.0.255 any
!
ip nat inside source list NAT interface FastEthernet0/0 overload

The configuration on the SPOKE2 router is as follows:

hostname SPOKE2
!
interface FastEthernet 0/0
 ip address 192.0.2.3 255.255.255.0
 ip nat outside
!
interface FastEthernet0/1
 ip address 10.3.3.3 255.255.255.0
 ip nat inside
!
crypto isakmp policy 10
 hash sha
 encryption aes
 authentication pre-share
!
crypto isakmp key dmvpn-cisco address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set DMVPN_TSET esp-aes esp-sha-hmac
!
crypto ipsec profile DMVPN_IPSEC_PROF
 set transform-set DMVPN_TSET
!
interface Tunnel0
 ip address 172.16.1.3 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp map 172.16.1.1 192.0.2.1
 ip nhrp map multicast 192.0.2.1
 ip nhrp network-id 1
 ip nhrp nhs 172.16.1.1
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN_IPSEC_PROF
!
router eigrp 10
 no auto
 network 172.16.1.0 0.0.0.255
 network 10.3.3.0 0.0.0.255
!
ip access-list extended NAT
 permit ip 10.3.3.0 0.0.0.255 any
!
ip nat inside source list NAT interface FastEthernet0/0 overload

The first test to know whether our configuration is working is if the EIGRP adjacencies are formed between the DMVPN peers. For example, on the HUB router, I can check the EIGRP neighbors.

We can also ping between all the internal networks to make sure there’s connectivity:

! ### Ping 10.2.2.0/24 and 10.3.3.0/24 from the HUB router ####
HUB#ping 10.2.2.2 so fa0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms
HUB#ping 10.3.3.3 so fa0/1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/24 ms
HUB#
! #### Ping 10.3.3.0/24 from SPOKE1 ######
SPOKE1#ping 10.3.3.3 so fa0/1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/43/84 ms
SPOKE1#

You can also check the ISAKMP and IPsec SAs to make sure traffic is being encrypted between those internal subnets.

The next thing we should test is our NAT configuration. If I ping a server on the Internet (192.0.2.100), from any of the Internal networks, the source IP address should be translated to the public IP address of the corresponding router. For example, if host 10.1.1.100 ping 192.0.2.100, the source IP address should be changed to 192.0.2.1 as shown below:

PC1> show ip
NAME : PC1[1]
IP/MASK : 10.1.1.100/24
GATEWAY : 10.1.1.1
DNS :
MAC : 00:50:79:66:68:00
LPORT : 10001
RHOST:PORT : 127.0.0.1:10012
MTU: : 1500

PC1> ping 192.0.2.100 -c 2
84 bytes from 192.0.2.100 icmp_seq=1 ttl=254 time=20.726 ms
84 bytes from 192.0.2.100 icmp_seq=2 ttl=254 time=15.747 ms
! ############ Response on SERVER #########
SERVER#debug ip icmp
ICMP packet debugging is on
SERVER#
*Mar 1 00:10:20.871: ICMP: echo reply sent, src 192.0.2.100, dst 192.0.2.1
*Mar 1 00:10:21.871: ICMP: echo reply sent, src 192.0.2.100, dst 192.0.2.1

Note: I initially used the 3725 router in GNS3 with IOS version 12.4(15)T and NAT was not working so I changed to a 7200 router with IOS version 15.2(4) and it worked. Perhaps there’s a bug on the IOS I used before.

With the DMVPN and NAT configuration out of the way, let us now enable ZBF on the HUB router and configure the policies we specified above.

ip access-list extended OUTSIDE_TO_INSIDE_ACL
 permit tcp any host 10.1.1.100 eq 22
!
class-map type inspect match-any INSIDE_TO_OUTSIDE_CMAP
 match protocol tcp
 match protocol udp
 match protocol icmp
class-map type inspect match-any OUTSIDE_TO_INSIDE_CMAP
 match access-group name OUTSIDE_TO_INSIDE_ACL
class-map type inspect match-any INSIDE_TO_DMVPN_CMAP
 match protocol http
 match protocol ssh
 match protocol icmp
class-map type inspect match-any DMVPN_TO_INSIDE_CMAP
 match protocol http
 match protocol icmp
!
policy-map type inspect INSIDE_TO_OUTSIDE_PMAP
 class type inspect INSIDE_TO_OUTSIDE_CMAP
  inspect
policy-map type inspect OUTSIDE_TO_INSIDE_PMAP
 class type inspect OUTSIDE_TO_INSIDE_CMAP
  inspect
policy-map type inspect INSIDE_TO_DMVPN_PMAP
 class type inspect INSIDE_TO_DMVPN_CMAP
  inspect
policy-map type inspect DMVPN_TO_INSIDE_PMAP
 class type inspect DMVPN_TO_INSIDE_CMAP
  inspect
!
zone security inside
zone security outside
zone security dmvpn
!
zone-pair security INSIDE_TO_OUTSIDE_ZP source inside destination outside
 service-policy type inspect INSIDE_TO_OUTSIDE_PMAP
zone-pair security OUTSIDE_TO_INSIDE_ZP source outside destination inside
 service-policy type inspect OUTSIDE_TO_INSIDE_PMAP
zone-pair security INSIDE_TO_DMVPN_ZP source inside destination dmvpn
 service-policy type inspect INSIDE_TO_DMVPN_PMAP
zone-pair security DMVPN_TO_INSIDE_ZP source dmvpn destination inside
 service-policy type inspect DMVPN_TO_INSIDE_PMAP
!
interface FastEthernet 0/0
 zone-member security outside
interface FastEthernet 0/1
 zone-member security inside
interface Tunnel 0
 zone-member security dmvpn

You should always test your ZBF configuration extensively to make sure everything works as it should but for this article, I will only test between the inside and dmvpn zones, as they are our focus.

! ##### Ping from host in 10.1.1.0/24 (inside) to host in 10.2.2.0/24 (dmvpn) ####
PC1> ping 10.2.2.100      
10.2.2.100 icmp_seq=1 timeout
10.2.2.100 icmp_seq=2 timeout
84 bytes from 10.2.2.100 icmp_seq=3 ttl=62 time=32.500 ms
84 bytes from 10.2.2.100 icmp_seq=4 ttl=62 time=36.039 ms
84 bytes from 10.2.2.100 icmp_seq=5 ttl=62 time=35.336 ms

PC1> 
! #### Check ZBF policy on HUB router ####
HUB#show policy-map type inspect zone-pair INSIDE_TO_DMVPN_ZP | section icmp   
      Match: protocol icmp
        1 packets, 64 bytes
        30 second rate 0 bps

        icmp packets: [5:5]
HUB#

! #### Ping from 10.2.2.100 (dmvpn) to 10.1.1.100 (inside) ####
PC2> ping 10.1.1.100
10.1.1.100 icmp_seq=1 timeout
10.1.1.100 icmp_seq=2 timeout
84 bytes from 10.1.1.100 icmp_seq=3 ttl=62 time=34.722 ms
84 bytes from 10.1.1.100 icmp_seq=4 ttl=62 time=37.602 ms
84 bytes from 10.1.1.100 icmp_seq=5 ttl=62 time=36.176 ms

PC2>
! #### Check ZBF policy on HUB router ####
HUB#show policy-map type inspect zone-pair DMVPN_TO_INSIDE_ZP | section icmp
      Match: protocol icmp
        1 packets, 64 bytes
        30 second rate 0 bps

        icmp packets: [5:5]
HUB#

Before we complete this article, I would like to discuss the effect of applying ZBF policies to the self zone when DMVPN is configured. Let’s take a sample policy that DMVPN users should only be able to ping the router and vice versa; the configuration will be something like:

class-map type inspect match-all SELF_DMVPN_CMAP
 match protocol icmp
!
policy-map type inspect SELF_DMVPN_PMAP
 class type inspect SELF_DMVPN_CMAP
  inspect
!
zone-pair security SELF_TO_DMVPN_ZP source self destination dmvpn
 service-policy type inspect SELF_DMVPN_PMAP
zone-pair security DMVPN_TO_SELF_ZP source dmvpn destination self
 service-policy type inspect SELF_DMVPN_PMAP

With this configuration, you may notice that your EIGRP adjacencies will begin to flap.

HUB(config)#
*Jul  9 15:29:24.755: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 172.16.1.2 (Tunnel0) is down: Interface PEER-TERMINATION received
HUB(config)#
*Jul  9 15:29:27.287: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 172.16.1.2 (Tunnel0) is up: new adjacency

The reason this is happening is that the configuration above has blocked some “control” protocols from working. Protocols like GRE, ISAKMP, ESP/AH and EIGRP need to be allowed (“pass” not “inspect”) so that the tunnel can operate correctly. The following configuration will fix this issue:

ip access-list extended SELF_DMVPN_ACL
 permit gre any any
 permit udp any any eq 500
 permit esp any any
 permit eigrp any any
!
class-map type inspect match-all SELF_DMVPN_PASS
 match access-group name SELF_DMVPN_ACL
!
policy-map type inspect SELF_DMVPN_PMAP
 class type inspect SELF_DMVPN_PASS
  pass

Summary

In this article, we have looked at how to configure DMVPN, ZBF and NAT on the same Cisco router. We have also seen that if a policy is going to be applied to/from the self zone, certain control protocols need to be allowed to pass through the firewall.

I hope you have found this article helpful.

References and Further reading