RED List disappears with more than one dynamic DHCP range configured

My heart just missed some beats.

After increasing the size of the subnet of one RED Device and then, because there was an existing static lease in the middle of the new available Net-Range, I decided to add an other dynamic range after that static entry.

After that, the DHCP Server on that object was first disabled automatically. At the same time, the RED List (24 pcs) on XG became empty except one device!

We're on XG430_WP02_SFOS 18.0.5 MR-5-Build586

I enabled the DHCP Server on the object again and it served IPs to the devices. So it looks like it is technically working.
But the RED list remained empty.

This DHCP config will cause all REDs ti disappear from the RED list on the XG:

This DHCP server config with only one dynamic Range will not cause REDs to disappear and will also "unhide" the previously disappeared REDs:

This is the exact issue as described here by .  I'm glad I found this as a proof. Phew!

How can this really be "This is not a bug this is as design"? This looks like a huge bug to me.

Edited TAGs
[edited by: emmosophos at 8:49 PM (GMT -7) on 17 Sep 2021]
  • this also causes an other GUI bug: while the REDs are not shown and you have a Bridge with a RED, the Bridge Configuration seems to duplicate below each time you click the Bridge device

  • Did you convert a interface to a bridge (by adding a existing interface to a bridge?) or is this a rather fresh installation? 


  • This bridge is there since 18.0 MR1 or so. Port8 is one of the standard hardware ports.

    But this is more a cosmetical GUI issue while the severe problem with the missing RED objects exists.

  • Seems like by creation of the bridge, the system mixed up the Interfaces. You should create a Support Case to get this sorted out. No way, there can somebody figure this out without database access, i guess. 


  • the bridge thing is not important for me, just an other bug which is only happening when the REDs are not shown.

    As the other customer reported the same issue months ago caused by the DHCP object on the RED device, it is most likely not related to the existance of a bridge device.

    Maybe I find the time to create a case for it.

  • Like in the other thread, the first answer from Sophos Support to my case was

    "we reached to the conclusion that this actually isn't a bug. It's an expected behavior. It's always recommended to apply DHCP changes directly from RED interface, not from Network > DHCP server."

    I replied and hope they review and somehow rethink about it.

    "How can this behaviour be as designed? Who ever designed this, simply did a bad job.

    What else could it be, when this configuration leads to all REDs to simply disappear? That is just the result of incomplete programming.

    As designed should be that the WUI is not allowing you to create more than one DHCP dynamic range on a RED and present a meaningful notification."

  • the case is now at GES who confirmed that this is known as NC-77642 (not listed in public known issues though)

    Update: 2021 Nov 02:

    Development reference number:


    Current Status:
    Assigned to backlog (Release planned with v19.0 MR1)

    Issue type:
    Feature Request