Losing DHCP Gateway

Yes, I still having problem with MR7 :/

Inadmissible this ..

Hi,

SFOS 17.5.7 MR7 on XG125 - regardless of the setting "dhcp system conf-generation-method" old or new - DHCP does not work properly, it is necessary to restart the interface on the client. Maybe MR1x will fix it? :)

Regards
Jan

Hi,

SFOS 17.5.7 MR7 on XG125 - regardless of the setting "dhcp system conf-generation-method" old or new - DHCP does not work properly, it is necessary to restart the interface on the client. Maybe MR1x will fix it? :)

Regards
Jan

Actually, i would like to ask, if you can get a pattern of this Issue? 

Are only certain Devices (OS) affected? 

Because i can only observe this issue in my personal network (not my customer networks) and only my Windows Clients are loosing the Gateway. 

None of my IoT Devices seems to be affected. 

Maybe somebody can confirm this or give more details. 

On SFOS 17.5.7 MR7 Sophos Home licence

iOS (iPad, iPhone) , Windows client are definitely affected. Those devices have static DHCP address on Sophos.

But I couldn’t test all devices I have before changing it the “old” method

Reverted to “old” method, all clients (iOS, Windows, MacOS,IOT...)work fine.

Hello LuCar Toni,

This is in response to your question for details from those affected by the problem.  To begin, changing the DHCP generation method from NEW to OLD fixed the issue in the environment where we noticed degraded services. 

In this environment, any device, regardless of type, appeared affected if it received a DHCP address, whether reserved or not.  Systems with statically assigned IP's (i.e., inter-networking devices, servers) were not affected.  Here are the device types:

1. Windows 10 Workstations - This was difficult to diagnose as all workstations are exactly the same model.  My assumption and direction of attack was that this was a driver/hardware/OS-related problem.  Since the loss of the gateway was evident (the network connection icon presented a yellow caution icon), a release and renew would generally fix the problem, sometimes not.  Even after a cold boot, there'd often be no gateway.
2. Allworx VoIP Phones - Linux-based.  This was not readily evident.  It was the phones that clued me into the DHCP service not working correctly.  When VoIP calls routed from one network to another, the calls would initiate (starting at the VoIP server) but parties could not talk to each other.  Cycling the power on the phones would generally resolve the problem.
3. Printers - All printers, a mixture of Brother, HP, and Konica-Minolta, would become inaccessible.  These include both wired and wireless printers.  Cycling the power would generally resolve the problem.
4. No Apple, Android, or other IoT devices are present on the network.

From the Windows machines, doing an IPCONFIG would show the gateway as empty.  What is really interesting is that sometimes all network traffic from the device seemed affected when the gateway would be lost.  I often could not ping the device from another machine nor could the user access internal resources, like file shares and databases.  It was usually the fact that they could not access their ERP server, housed on a local server on the same subnet as the workstations, that would result in a call to me, not the fact that they couldn't get to the internet.  It did not always result in a loss of traffic, only sometimes.

Here's a network configuration overview:

• Firewalls - XG210 w/HA at one site; XG135's w/HA at two remote sites
• DHCP - Exclusively provided by Sophos firewalls 
  • Almost all objects possess reservations
  • No MAC filtering (no whitelisting/blacklisting)
  • Domain is specified
  • Multiple DHCP ranges established
  • Each DHCP range is distributed on unique VLAN
  • Via command line, specified option 66 for VoIP phone DHCP
• DNS - Exclusively provided by Sophos firewalls
• Sites connected through site-to-site VPN
  • No DHCP relaying
  • Each site on unique subnet

The firewalls were purchased and installed at the beginning of June with version 17.5.5 image pre-loaded.  Each of the three sites experienced the problem since the introduction of the firewalls into the network.  Since changing the generation method to OLD, everything has been solid.  I've since updated each firewall to version 17.5.7 but left the generation method as OLD so I haven't any idea if the issue persists with version 17.5.7.

Thanks a lot for that wrapping Mark.  Very Helpfull.

Paul Jr

Mark,

Did you power off and power on XG devices after upgrading to MR7 ?
And DHCP still works well in OLD mode ?

Regards
Jan

It's perplexing how much troubles this feature-less DHCP brings. The only thing it provides is an IP address !!!  Absolutely nothing more.  How many lines of codes there is in a DHCP module ? Few hundreds ???  And you can find OpenSource code everywhere.  No need to re-write from A to Z.  There must be something I seriously miss here !!!

This problem existed for many month now.  Is it gonna last a full year ?

And for what it is, what is an "old" and "New" mode anyway ?  And why it is required for such a basic and simple DHCP task ? Anyone has a clue ???

I am not that much hit since I'm using either static addresses or Windows Server DHCP.  But I'm getting very nervous for my IP phones.

Paul Jr

Hello Jan,

After the upgrade, I just did a warm reboot.  Is it recommended to do a full power down?

I upgraded to MR7 on 7/17 @ ~1:45 AM Arizona time.  I see no loss events on the handful of machines I've looked at so far.  The DHCP method is still OLD.  It appears to be working as expected.  Actually, I see absolutely no loss events since 7/10/2019 @ 6:30 PM when I changed the method to OLD. 

As for it working well, yes, it appears it is.  All settings are propagated correctly, including option 66 for the phones.  I'm going to keep going through the log files on the devices to see if anything jumps out at me.  I'll report back when I'm done.

Mark Koenig