DHCP relay issue after upgrade to SFOS 17.0.1 MR-1

I was running DHCP Relay in version 16 with no issues.  I upgraded to version 17 and DHCP Relay stopped working.  After reviewing my config, I noticed the DHCP Relay was enabled on the interface my DHCP server was running on.  After I removed the DHCP Relay from the network interface my DHCP server was in, all the other network DHCP Relays to the DHCP server started working again.  Since the DHCP server is in the network it really does not need a DHCP Relay agent on the interface.  I tested several times to confirm this is the case.

Example:

If DHCP Server is 192.168.10.10 on Network 192.168.10.1/24 adding a DHCP Relay on this network for the server will cause all DHCP Relays to the server to stop working.

I hope this helps anyone in the same situation.

Alan 

Thank you Alan. My setup was what you have described. I upgraded to SFOS 17.0.6 MR-6 and removed DHCP relay on subnet where DHCP server is located and everything is working perfectly so far.

Regards

Kamal

Exactly the same thing happened to me, this week I decided to update the firewall from SFOS version 16.05.8 MR-8 to SFOS 17.0.8 MR-8. I have a network segmented in VLAN and everything worked fine until when updating, half of the computers went into network and the other half did not (dhcp server windows did not serve IP address). I have tried to do what Alan says (remove the DHCP relay from the subnet where i have the DHCP Server) but it has not worked. I have an open ticket with support but in the end I decided to start the firewall with the image SFOS 16.05.8 MR-8 and everything has returned to normal.

Hi Jose,

Could you try running the command under shell

Go to Option 5>3

#dhcrelay -i Port1.10 <DHCP Relay> -4 -d     for Vlan 10 on Port1

Hi Aditya Patel, 

Mention that my network has several VLANs (VLAN 37-45). The DHCP Server is located on VLAN37

I have released the command knowing that my DHCP Server is in LAG.0.37 and I get the following:

Thank,

Hi Aditya Patel, 

Mention that my network has several VLANs (VLAN 37-45). The DHCP Server is located on VLAN37

I have released the command knowing that my DHCP Server is in LAG.0.37 and I get the following:

Thank,

Hi Jose,

Could you run the command in Shell option 5>3 

tcpdump -nei any port 67 or 68

Output:

tail -f /log/networkd.log

Output

ip route get <IPaddress of relay >

Output:

Good morning, right now I have the firewall with the version XG310_WP01_SFOS 16.05.8 MR-8 To perform the test I would need to do it with version 17 and having it in production is almost impossible to do. I will wait for version 17.1 to be released and if it continues to fail I will be able to release the catch, thank you very much for your help, regards

Hi there,

I am also having such issues.

DHCP relay via physical interface without VLAN works perfect.

If I am using DHCP via VLAN it either takes 5 - 10 seconds until a device gets the IP lease back or I do not get any lease.

I am using the newest version of XG -> SFOS 17.1.1 MR-1

Looking forward to a fix.

Hello Jose Manuel Gonzalez,

no as it was not so vital for me I have deactivated the DHCP relay function for Sophos.

But I could do some test on the newest Sophos XG Version and get back to you.

Best regards,

Mathias

Hi Everyone

We are currently deploying 70 XG125 firewalls and run into the same issue.

Our setup is:

Port1 (nativ): Client VL1

Port1.10 Client VL2

Port1.20 Client VL3

Port9 ("unused with dummy IP")

Port9.110 Uplink / Default Gateway

DHCP Relay is setup on Port1, Port1.10, Port1.20 and relays to a server that is reachable over Port9.110 behind the default gateway.

We have noticed that after a reload of the XG DHCP Relay does not work properly anymore. 

TCPdump showed us:

Port1: Receives Discover

Port9.110: relays Discover

Port9.110: receives offer

Port1: does not forward offer

We removed VL10 and VL20, so that only Port1 and Port9.110 is involed, still does not work.

During the tests we noticed, that if we re-apply the dhcp relay config in the GUI, everything works fine.

From the logfiles we can see, that just after the reload, the "is_relay_ok" function fails.

If I had to guess, i would say that after the reload the XG checks the relay, but maybe because Port9.110 is not up at that time, the relay server are marked dead and there is no periodic check to remark them alive?

This issue is now finally fixed with Version 18 with the introduction of this feature:

"DHCP Relay Enhancements for Dynamic Routing Synchronizes dynamic routing updates (learned routes from OSPF) to DHCP relay, eliminating the need for manual reconfiguration."

the problem in my case was, that the DHCP Server is behind the WAN interface (MPLS) and requires the default route to be installed in the routing table to be reachable. unfortunately during boot the DHCP Relay functions runs a check if the DHCP Server is reachable, but since default route is not installed at that moment, it fails.  this check runs only one and marks the DHCP server dead. 

A workaround for pre V18 to force the DHCP Relay function to constantly check for DHCP Server:

1. 
   Mount the filesystem as read/write:
   
   mount -no remount, rw /
2. 
   Edit the startup scripts:
   
   vi /scripts/system/clientpref/customization_application_startup.sh
3. 
   Use vi to add the following line and save the file:
   
   nservice networkd:dhcprelay_up -dsnosync
4. 
   Write protect the filesystem again:
   
   mount -no remount, ro /

To confirm the expected changes have applied, running cat on the startup script should now look like the following:

# cat /scripts/system/clientpref/customization_application_startup.sh
#!/bin/sh
nservice networkd:dhcprelay_up -dsnosync

exit 0;

you need to reapply the workaround after an upgrade within the 17.x train.

The bug is fixed with V18.