Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 22803 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SOLVED: Simple DHCP Blocked by Firewall Rule 0

SeanPetty

I'm sure (hoping) there is a simple solution to this.  We've been banging our heads against the wall for a couple of days trying to figure out what we're doing wrong.

The simple setup:

XG550

PortA8 configured as LAN, 192.168.1.1.  

DHCP server scope set up to serve 192.168.1.100-250

FW rule for SOURCE LAN (Any) to DESTINATION LAN (Any) and SERVICE (Any). Rule is at the TOP of the FW rule list.

 

When we connect to A8 there's no DHCP response, and the DISCOVER is blocked by FW Rule 0 as a Local ACL issue.  Here is the detailed dropped packet capture:

 

2017-05-18 21:14:44 0103021 IP 0.0.0.0.68 > 255.255.255.255.67 : proto UDP: packet len: 308 checksum : 42135 0x0000: 4500 0148 2946 0000 ff11 915f 0000 0000 E..H)F....._.... 0x0010: ffff ffff 0044 0043 0134 a497 0101 0600 .....D.C.4...... 0x0020: de00 9123 0012 0000 0000 0000 0000 0000 ...#............ 0x0030: 0000 0000 0000 0000 ac87 a31a 8f93 0000 ................ 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ Date=2017-05-18 Time=21:14:44 log_id=0103021 log_type=Firewall log_component=Local_ACLs log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=PortA8 out_dev= inzone_id=1 outzone_id=4 source_mac=ac:87:a3:1a:8f:93 dest_mac=ff:ff:ff:ff:ff:ff l3_protocol=IP source_ip=0.0.0.0 dest_ip=255.255.255.255 l4_protocol=UDP source_port=68 dest_port=67 fw_rule_id=0 policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_done=0 proxy_flags=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node=0 inmark=0x0 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drop_fix=0 ctflags=0 connid=1978840064 masterid=0 status=256 state=0 sent_pkts=N/A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_dst_ip=N/A tran_dst_port=N/A

 

So what's the dumb thing that we've missed?  Or how should the rule be properly set up?  I'm wondering if the section "inzone_id=1 outzone_id=4" has anything to do with it?  There's really only 1 zone involved - PortA8 is a LAN source, so it seems that the source and destination should both be LAN, but it looks like the XG thinks they are in different zones, although I can't find a reference to what the zone numbers correspond to.

Thanks for any help.



This thread was automatically locked due to age.
  • 0

    Hi,

    the rules have nothing to do with address assignment by DHCP server. All devices are on the inside of the XG, the rule only applies to traffic passing through the XG.

    Firewall rule would be

    source any any network

    destination any any network

    service any

    NAT MASQ

     

  • 0 in reply to rfcat_vk

    Any/Any/Any is the only way to make DHCP work?  Clearly I'm missing something.

     

    To provide a bit more depth, our setup started a lot more complex than this.  We have a single port that is trunked with multiple VLANs to a Cisco 6509.  The XG is set up to provide DHCP on a few of the VLANs.  We weren't able to get any DHCP responses on any of the VLANs so to simplify the setup and reduce as many variables as possible we set it up with just the single port.

     

  • 0

    Hi Sean,

    Please show us a network diagram and a glimpse of tcpdump for the ports: 67 and 68.

    Thank You

  • 0 in reply to SeanPetty

    That is not what I said. I said a rule does not affect the DHCP because all the traffic is on the inside of the rule.

    The rule is in reference to allowing traffic out, but now you have expanded on it the rule is irrelevant to the discussion and your issue.

    From past experience you cannot delete vlans as much as you think you have.

    You will need a fresh installation and config that doesn't have vlans before your simple test will work.

  • 0 in reply to rfcat_vk

    Thanks.  This is a production box in HA with another unit, passing a lot of critical traffic.  A fresh installation and starting with a new config simply isn't an option.  

     

    The network diagram is pretty simple in this case.

    4075.bootp-dhcp-67-68 cap.pcapng.zip

  • 0 in reply to SeanPetty

    SOLVED --

     

    Luckily we didn't have to resort to wiping out the config and starting over.  Opened a ticket with Sophos tech support.  Tier 1 wasn't very helpful, but Tier 2 (Paul) was extremely helpful and solved the issue in 10 minutes.

    When we set up HA we configured PortMGMT2 as 192.168.254.0/16.  We made it /16 accidentally, it should have been /31.  Well, that overlapped the 192.168.1.0 range that we were trying to configure DHCP on.  Even though the DHCP server was configured on the right port, the XG wouldn't work because the ranges overlapped with another port.  As soon as we configured the right mask on the MGMT2 port everything worked, including DHCP on VLAN trunks.

    Although I wish there were some type of warning, it was our own stupid mistake.