How to Allow DHCP Traffic on Zone-Based Interfaces?

[Matthew Martin]

Hello All,

Device: ISR4321

Our ISR is configured to use a zone-based firewall + Access-lists for controlling traffic. One of our GigabitEthernet Interfaces is connected to a local ISP cable modem supplying internet access. The interface in question is Gi0/0/0, which is configured for getting its IP Address via DHCP.

For some reason Gi0/0/0 is not getting an IP Address and I'm wondering if its being blocked by the security settings?

If I have the following ZBFW and Access-Lists, do you think this could be causing DHCP packets to get blocked?

!
interface GigabitEthernet0/0/0
 description to ISP Modem
 ip dhcp client client-id GigabitEthernet0/0/0
 ip address dhcp
 ip nat outside
 zone-member security INTERNET
 media-type rj45
 negotiation auto
!
!.....................
!
class-map type inspect match-any PUBWIFI_INTERNET
 match protocol udp
 match protocol tcp
 match protocol icmp
class-map type inspect match-any INSIDE_WAN
 match protocol skinny
 match protocol sip
 match protocol rtsp
 match protocol http
 match protocol h323
 match protocol udp
 match protocol tcp
 match protocol icmp
class-map type inspect match-any WAN_INSIDE
 match protocol skinny
 match protocol sip
 match protocol rtsp
 match protocol http
 match protocol h323
 match protocol udp
 match protocol tcp
 match protocol icmp
class-map type inspect match-all INSIDE_WAN_PASS
 match access-group 160
class-map type inspect match-all WAN_INSIDE_PASS
 match access-group 170
class-map type inspect match-any INSIDE_INTERNET
 match protocol udp
 match protocol tcp
 match protocol icmp
!
policy-map type inspect INSIDE_WAN-Policy
 class type inspect INSIDE_WAN_PASS
  pass
 class type inspect INSIDE_WAN
  inspect pmap-fw
 class class-default
  drop log
policy-map type inspect WAN_INSIDE-Policy
 class type inspect WAN_INSIDE_PASS
  pass
 class type inspect WAN_INSIDE
  inspect pmap-fw
 class class-defaulttyp	
  drop log
policy-map type inspect INSIDE_OUT-Policy
 class type inspect INSIDE_INTERNET
  inspect
 class class-default
policy-map type inspect PUBWIFI_INTERNET-Policy
 class type inspect PUBWIFI_INTERNET
  inspect pmap-fw
 class class-default
!
zone security INSIDE
zone security INTERNET
zone security WAN
zone security PUBWIFI
zone-pair security INSIDE-OUT source INSIDE destination INTERNET
 service-policy type inspect INSIDE_OUT-Policy
zone-pair security INSIDE_WAN source INSIDE destination WAN
 service-policy type inspect INSIDE_WAN-Policy
zone-pair security PUBWIFI-OUT source PUBWIFI destination INTERNET
 service-policy type inspect PUBWIFI_INTERNET-Policy
zone-pair security WAN_INSIDE source WAN destination INSIDE
 service-policy type inspect WAN_INSIDE-Policy
!
!
access-list 100 permit ip any any
access-list 120 deny   ip any any
access-list 160 permit tcp any any eq 9100
access-list 160 remark Inside to WAN traffic
access-list 170 permit tcp any any eq 9100
access-list 170 remark WAN to Inside traffic
!

Any help would be greatly appreciated!


Thanks in Advance,
Matt

[Richard Burts]

Matt

I believe that you need to add logic to permit traffic Internet to self

HTH

Rick

[Matthew Martin]

Hey Richard and George, thanks for the replies.

So I found some instructions at the link below for allowing DHCP through ZBFW configurations, and I attempted BOTH of the configurations shown in the link individually. However, I did not see any change after adding the configurations... Except in the logs I could see that it was dropping packets (*used the "drop log" option instead of just "drop" for the class-default action). Which I thought was strange because it seemed as though the traffic should have matched the "pass" portion of the config...

Instructions: http://www.cisco.com/c/en/us/support/docs/security/ios-firewall/116117-configure-dhcp-zbf-00.html

Question.... If I wanted to see if the ZBFW configuration was the cause for the DHCP not going through. Would I just need to remove the line "zone-member security INTERNET" from Gi0/0/0 in order to prevent the ZBFW from blocking ANY traffic on that port? Then, I can just add that command back after I've tested...


First Attempt:

	class-map type inspect match-all DHCP
	 match protocol udp
        !
	policy-map type inspect OUT-TO-SELF
	 class type inspect DHCP
	  pass
	 class class-default
	  drop log
	policy-map type inspect SELF-TO-OUT
	 class type inspect DHCP
	  pass
	 class class-default
	  drop log
        !
	zone-pair security OUT-TO-SELF source INTERNET destination self
	  service-policy type inspect OUT-TO-SELF
	zone-pair security self-to-out source self destination INTERNET
	  service-policy type inspect SELF-TO-OUT

Second Attempt:

	ip access-list extended 111
	 10 permit udp any any eq 67
	ip access-list extended 112
	 10 permit udp any any eq 68
        !
	class-map type inspect match-any self-to-out
	 match access-group 111
	class-map type inspect match-any out-to-self
	 match access-group 112
        !
	policy-map type inspect out-to-self
	 class type inspect out-to-self
	  pass
	 class class-default
	  drop log
	policy-map type inspect self-to-out
	 class type inspect self-to-out
	  pass
	 class class-default
	  drop log
        !
	zone-pair security out-to-self source INTERNET destination self
	  service-policy type inspect out-to-self
	zone-pair security self-to-out source self destination INTERNET
	  service-policy type inspect self-to-out

I attempted each of those configurations above individually, but it didn't seem to help any. Are both of those configurations supposed to be used, or just one of them??

Thanks Again,
Matt

[Georg Pauwen]

Hello Matt,

without the NAT command on the outside interface, do you have Internet connectivity ?

[Matthew Martin]

Nope, you're correct, the Internet dropped for clients connected in that location. So after the interface got the  DHCP address I re-added "ip nat outside" back to the interface and they could now reach the Internet.

I spoke with Cisco after finding this out because I assumed with the "ip nat outside" command back on the interface, the next time it would try to renew the IP Address, I would get the same result... So he pointed out that the following lines were the cause of this issue:

### Having the access-list below applied to this command was the problem:
ip nat inside source list 100 interface GigabitEthernet0/0/0 overload
!
!
access-list 100 permit ip any any
!

So if I change the above config to the following, it should be ok:

ip nat inside source list 101 interface GigabitEthernet0/0/0 overload
!
!
access-list 101 permit ip 10.0.0.0 0.0.0.255 any
!

So I believe that will only NAT the internal/private 10.0.0.0 network...

Currently its still configured with the ip any any, but tonight I am going to apply the new "101" access-list to the "ip nat inside source..." command.


Thanks Again,
Matt

[Georg Pauwen]

Hello Matt,

good stuff. Glad you got it (hopefully) resolved...

[Matthew Martin]

So I found out that with the "ip nat outside" command removed, connected clients could no longer reach the internet through that interface. So I added the ip nat outside command back to the interface and they can now reach the Internet again... But, I assumed that the next time the interface would try to renew the IP or the next time the ISR was rebooted, I would have the same problem.

So I asked TAC, and he pointed out the problem was with the access-list applied to the nat overload command... See below:

!
ip nat inside source list 100 interface GigabitEthernet0/0/0 overload
!
!
access-list 100 permit ip any any

So TAC gave the following recommended change which I am going to attempt tonight:

!
ip nat inside source list 101 interface GigabitEthernet0/0/0 overload
!
!
access-list 101 permit ip 10.0.0.0 0.0.0.255 any

Thanks Again,
Matt

[Georg Pauwen]

Hello Matt,

as far as I can tell, you need to configure UDP/67 for the zone where your DHCP server is sitting to the self zone (for DHCP server replies), and UDP/68 for the self zone to that same zone (for DHCP requests).

[Matthew Martin]

Just got it working...!

Once I removed the "ip nat outside" command from the interface it started working instantly...

Any ideas why this would cause a problem?

The strange part is this interface was working perfectly fine until we upgraded the ISR4321 from IOS-XE 3.13.4S  to  3.16.5S. Once upgraded the interface stopped getting a DHCP address. And I now have the exact same configuration now (*minus the "ip nat outside" command) as I did while it was NOT working. And the interface still has the same zone membership as it did before (*i.e. nothing new was added to the zbfw policies, classes, etc...)


Thanks Again,
Matt