This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DHCP RELAY issue after upgrading to MR-8

Hi all,

just closed a ticket with Sophos Support.

There is a confirmed bug (NC-20755). After uprading to MR-8, DHCP relays do not work properly.

I have a configuration the several VLANS, and DHCP relay configured to serve dynamic IPs.

A temporarily workaround was to delete the DHCP relay, and configure a DHCP server instead. And it works.

Sophos Support connected to the firewall in SSH to fix the issue. The problem will be solved int V17 rev 1.

Beware that an upgrade to V17 will erase this fix, that theoretically has to be reapplied to V17 also (and it should work, but not sure at the moment). If not, a rollback from V17 to V16 need to erase totally the XG and restore configuration from a backup. Not so easy.

Best regards



This thread was automatically locked due to age.
  • Antonio,

    Strange support told you that is was MR8 that caused it but I'm not supprised anymore. Sophos support is a joke. It broke in MR5, I opened a case, and was tracked as NC-19984. Our case is still open so we could track how long it takes Sophos to fix a core function. Opened June 19th. Support told me then it would not be fixed until V17 which I am worried to try. The workaround was to enable "Relay Through IPsec" which was found by another forum member, not even a Sophos engineer. We are on MR8 and have not made any changes to DHCP relay settings since the workaround we applied with MR5.

    Original post.

    https://community.sophos.com/products/xg-firewall/f/network-and-routing/93247/dhcp-relay-not-working-in-mr5

     

    Mike

  • Hi all,

    my situation is the following:

    - Customer 1: 2x XG310 (HA), actually MR-4. DHCP relay is working, and when I updated to Mr-8 it stopped working, and now fixed as described above.
    - Customer 2: 1x XG125 actually MR-7. Always promptly updated every time. DHCP relay working from MR-4 (maybe earlier). After updating to MR-8 it stopped working; revert to MR-7 restarted working well

    Both the configurations involves DHCP relay and VLAN.

    I don't know if NC-19984 and NC-20755 are related to the same problem.

    I tried also to configured VLAN on LAG interface (Customer 2) but seems that there are some other problems to fix, related to NC-10402 (quite old). Support says that also this one should be fixed into 17.1

    Regards

  • Do you happen to know what support did to fix this issue? I'm having the same issue, and I would rather use a work around then drop the network for a rollback.

     

    When is rev1 coming out?

  • Hi,
    I suppose that rev 1 will take some time.

    I opened a ticket, and the Support diagnosed the problem, then requested SSH access from remote to fix manually with some kind of scripts.

    Temporary workaround for me was to configure DHCP server on XG for specific VLANs, instead of DHCP relay.

    Best regards

  • Thanks Antonio!

     

    I found a work around for my lab environment, and thought I would share it.

     

    Since all of my machines are are virtualized I just added a nic for each vlan on my dhcp box via esx. 

     

    So in my case the dhcp server has 3 more network interfaces and the settings look like the following:

    IP Address: x.x.x.x

    Subnet Mask: x.x.x.x

    Default Gateway: this is left blank to ensure the primary nic is used for all traffic

     

    Preferred DNS Server: this is left blank as well

     

    That has me up and running again. I hope this solution will help someone else in need.

     

    Cheers

  • Hi,
    this could be a solution, but usually subnets that require DHCP service are DMZ that should not be allowed to access to a server on that should be connected to another network.
    With other works, you are bypassing the firewall, granted the access to that server without passing through the firewall. This, sometimes, is not a good idea.

    Example: guest network that should be isolated from Office network, BUT the DHCP server is on the Office server. Even if you protect the server with S.O. firewall, it is not a good idea...

    Best regards