Firewall DHCP Relay stops working until you delete an recreate a random DHCP Relay object

There was one fix coming in for DHCP Relay in V20.0 with a catch.

See: 

https://support.sophos.com/support/s/article/KB-000045837?language=en_US

Essentially i know, a relay could stop, if the interfaces are "invalid" like a virtual interface like RED, which is offline. 
Could that be a way to reproduce it? 

So if you have a timeframe, where the issue started, could you check the logviewer / system and check if there was a change? Like RED disable? 

from the graph above and the Admin Audit log i would say it started with RED deletion

I'm in the process of creating a new support case

->

I have some spare RED15 I could delete - wonder if I will junk them all? see my other recent post...

some still work. So I deleted and recreated them but the issue did not come back.

the Cluster had been rebooted last 4 days ago. I think this was the first network change after. Maybe it only happens in that combination - FW reboot, delete RED, DHCP issue? not so easy to test - this is no playground.

But I found a comment of mine in earlier case notes:

9/20/2022 4:59 PM 05662019 / direct to 2nd Level: XG DHCP server or DHCP relay failing after some time - clients not receiving DHCP offer

We cannot reproduce it. It just comes. Eventually it has to do with RED changes. Last time I deleted and recreated a RED. 1 hour later or so we noticed the issue. You should have it in the logs.

Also at that time I tried to delete and recreate RED again - issue not reproduced but some how related.

So - my understanding from a past issue with this situation was: If there is a "Huge" DHCP relay config and one interface went offline, it can cause problems. After removing the faulty options (there were instances like customers added not support XFRM to the DHCP Relay and break it), it worked again for ages. 

Not sure, what causes your problem, the Team will look into your time stamp on your appliance to check, if we can find an indicator of your problem. But still, in IT it is the hardest to debug an problem, which is not reproducible (Like you properly know with the SATC issue). 

I'd say it's not a huge DHCP config. 20 DHCP servers on XG and a bunch of relays.

I'd expect hundreds to be huge.

Last weekend I rebooted both FW nodes and will recreate a RED deletion tomorrow if that may reproduce it. The initial RED I deleted is broken unfortunately so it will be a different one. But both have (had)  their own DHCP servers.

In the meantime the support case is going to my statisfaction - I guess I have to thank Vivek Jagad  for that. They are looking in the backup before the first deletion of the RED and communication is really well currently.

LHerzog said:

will recreate a RED deletion tomorrow if that may reproduce it.

unfortunately it did not

Hi LHerzog,

Upon checking your case, the case handler is seeking assistance with the access-id.

"I have started the investigation and I am still going through the available logs, but I have to re-check the old case as well.
Therefore I need a bit more time to get a better overview of what we have so far.

In parallel could you please provide me a new access id because the known one seems to be expired"

update sent via case mail. thank you!

Hello,

To update the community, this is being investigated under NC-130879

Rewards,

Hi LHerzog , 

NC-130879 - Current plans are to include this fix as part of 20.0MR2 and release the fix by Q2 2024.  Should it be delayed, we will inform you accordingly.

By the way, this was fixed in v20.0 MR2 - released by now. 

By the way, this was fixed in v20.0 MR2 - released by now.