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

DHCP Relay doesn't seem to work

Hi All,

Running an SG105 (SFOS 16.05.1 MR-1) and am having major issues getting the DHCP relay working.

I've got our VoIP network on eth0.900 (tagged VLAN 900) and everything works on a static IP address but the DHCP relay just isn't working. I've set it under Networks > DHCP > DHCP Relays as:

Name: VoIP_Relay
Interface: #eth0.900
DHCP Server IP: 10.0.48.252 (our DHCP IP on eth0 untagged)
IP Family: IPv4

Now nothing seems to be getting an IP from the 10.0.50.0/27 scope I've defined on our DHCP server (#eth0.900 is 10.0.50.1/27 on the Sophos). I can see this on the console if I run a firewall log on the console:

Date=2017-02-22 Time=10:58:38 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=eth0.900 out_dev= inzone_id=1 outzone_id=4 source_mac=38:bb:3c:be:e6:67 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=3851835264 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

Any ideas? It looks to me like the Sophos is blocking the broadcasts.



This thread was automatically locked due to age.
Parents
  • HI Tom, 

    Could you disable Firewall acceleration on your device, also this command would stop internet service for few seconds. So make sure you have a downtime for such interruption.

    Console > system firewall-acceleration disable  

  • Hi Aditya,

     

    I did this but it doesn't make any difference, I'm still getting these firewall logs:

     

    Date=2017-02-22 Time=18:51:08 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=eth0.900 out_dev= inzone_id=1 outzone_id=4 source_mac=38:bb:3c:be:e6:67 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=3622270848 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

  • Worth trying:

    Under "administration" , "device access" , add an Local Service ACL Exception Rule, allowing dest udp port=67 from source zone where eth0.900 is located

  • I did look earlier, unfortunately you cant specify extra ports or services in that form :/

    I even tried adding a FW rule for any > any DHCP but that didn't seem to have any effect

Reply Children
  • I still want to get this fixed, but for now I've just set up one of our layer 3 HP switches as the VoIP gateway with an IP in our server LAN and the IP helper is working flawlessly, so it's definitely something up with the Sophos appliance.

    I'm really disappointed at how bad the Sophos XG software is compared to the old Sophos UTM software - our license is up for renewal this year and I'm heavily leaning towards Palo Alto or Fortinet simply because of these silly issues.

    Any help greatfully appreciated anyway :(

  • HI TomFerguson1 ,

    Could you open a Service request for the same , so an engineer would troubleshoot the issue further. Let us know the Case# via DM, so we may monitor the case for you.

  • Hey, I'm having the same problem, looks like replies from the DHCP server are being dropped by a local ACL and no matter what I do with f/w rules etc I can't seem to override the default deny policy. This is really annoying for something so basic, I have wasted hours on this today. Did you ever get a solution to this?

    Cheers,

    Paul

  • Paul,

    I did eventually fix this but I can't remember exactly how. I believe I had to add the subnet for the VLAN with our DHCP server on into the relay config page, too. It seems counter intuitive but I believe that's what made it begin working.

  • Thanks Tom, that kinda rings a bell as had to do something similar with Vyatta/Vyos many years ago.

    Unfortunately I didn't see your message in time and I have been upgrading firmware, I'm now on 17.0.2 MR-2 and don't even see the DHCPDISCOVERs hitting my DHCP server any more, so wondering now if it's completely broken.

    Was thinking of rolling back to v16 but looks like it wants to do a factory reset and don't really want to lose all my settings, although having said that I do have a backup I could maybe load in.

  • Hello PaulRoberts,

    Hello Community,

    i have 2 SG230 as active passive Cluster and i have direct the same problem with the dhcp relay system.

    Because of the problem on the utm system, where you can only add one server as dhcp relay, we had upgraded the 2 systems to the xg system.

    I need 2 to 4  dhcp servers as target in the dhcp-relay for 6 different vlans.
    As i set up the Relay, i can see that the answer from the dhcp server is blocked as a "Appliance Access" but i see no way to allow it.

    2017-12-27 14:25:43Firewallmessageid="02002" log_type="Firewall" log_component="Appliance Access" log_subtype="Denied" status="Deny" con_duration="0" fw_rule_id="0" policy_type="0" user="" user_group="" web_policy_id="0" ips_policy_id="0" appfilter_policy_id="0" app_name="" app_risk="0" app_technology="" app_category="" in_interface="Port1.21" out_interface="" src_mac="68:b5:99:6f:b5:fe" src_ip="10.124.216.41" src_country="" dst_ip="10.124.219.254" dst_country="" protocol="UDP" src_port="67" dst_port="67" packets_sent="0" packets_received="0" bytes_sent="0" bytes_received="0" src_trans_ip="" src_trans_port="0" dst_trans_ip="" dst_trans_port="0" src_zone_type="" src_zone="" dst_zone_type="" dst_zone="" con_direction="" con_id="" virt_con_id="" hb_status="No Heartbeat" message="" appresolvedby="Signature"

    All VLANs are in LAN Zone. I have Firewall Rules which allow LAN-LAN-any. I have Firewall Rules which allow from DHCP Server to any-any. But nothing works.

    Does anybody has another Idea?

    Thanks for your help.

    Regards Daniel

  • Hi,

    after setting up several branches with XGs and DHCP-Relay it seems to me that this is a self-regulating error.

    It took an estimated time between 30 minutes to two hours looking at port 67/68 regarded as "appliance access" and then being dropped (firewall log viewer).

    Meanwhile I can tell my customer to just be patient and it suddenly begins to turn green on ports 67/68 and fetching IP-Adresses.

    Good Luck

    Marc

     

    P.S. I enabled "Relay through IPSec" on all branches, dont' know if that matters.