Losing DHCP Gateway

This problem started with 17.5.0 GA.  The firewall is handling DHCP for my lan.  Users have started to lose the default gateway(the Firewall) randomly throughout the day.  I have to either reset the switch or the desktop network adapter in order to regain internet connectivity.  This does NOT happen to all users at the same time.

I updated to XG 115 SFOS 17.5.5 MR5 but the problem still exists.  This actually introduced another problem of not being able to access the gui from Sophos Central, but that's not as pressing.  Any thoughts on this would be appreciated.



  • In reply to Tibor Soós:


    Just curious.  What version of Hyper-V (on server 2019 by chance ?) and which intel adapter ?

    Paul Jr

  • In reply to Big_Buck:

    Hi Paul,


    it was on Windows 10 1903 and had 3 adapters. If I just remeber correctly perhaps it is get wrong after the upgrade. Till then it was fine.


    Realtek Gbit Ethernet adapter - this was the WAN port

    TP-LINK Gigabit PCi Express dapter - this was the LAN port

    ASIX AX88179 USB 3.0 to Gigabit Ethernet Adapter - this was the Public Wifi port


    Hyper-V configuration version 8.0


    For me the resolution was to install the latest firewall firmware to Intel HW: https://ark.intel.com/content/www/us/en/ark/products/42408/intel-desktop-board-dh55tc.html

    and added to PCIe cards: TP-LINK Gigabit PCi Express dapter and Samsung 120GB SSD


    on this HW the issue is not present. everything is fast and working well.

  • In reply to Tibor Soós:


    Realtek uses their own silicon.  TPlink were using Intel at a point of time.  And I have no clue what ASIX is using.

    You could you use a dual port or even quad ethernet adapter in PCIe 1X.  Depending on the motherboard you are using, it may not be possible to use 4, 8 or 16 lanes ... That said, dual or even quad ports are very cheap on e-Bay.


    Paul Jr

  • Anyone still have this "DHCP lost" problem with MR7 ? Or did MR7 fixed this ?

    Paul Jr

  • In reply to Big_Buck:

    Do we have MR 7 now? i still have same problem, users have to reset NIC or reboot their PC to get internet and it's been alot of front and back with sophos support

    Got tired and frustrated.. Am just here with my problems, blaming myself for making the sophos switch!

  • In reply to Oluseye Arinde:

    Released last week with a WiFi update as well ...



    Like I've written before, I do not see LOGs bug or DHCP bug fixed in that list.  TCP SACK PANIC is resolved as a consolation prize.

    Paul Jr

  • Yes, I still having problem with MR7 :/

    Inadmissible this ..

  • In reply to Carlos Cesario:

    Hi all,

    Did you open up a Case and got a confirmed by Sophos, that you are affected by this ID? NC-48031

  • In reply to Carlos Cesario:


    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? :)


  • In reply to JanSadlik:

    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. 

  • In reply to LuCar Toni:

    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.

  • In reply to deeptibhavsar:

    Is this for Sophos XG hardware, white box, or both?

  • In reply to LuCar Toni:

    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.

  • In reply to Mark Koenig:

    Thanks a lot for that wrapping Mark.  Very Helpfull.

    Paul Jr

  • In reply to Mark Koenig:


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