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

XG DHCP Options Not Working for PXE

Hello all,

I have been trying to get PXE boot to work with files stored on a local Synology machine, using our Sophos XG as the DHCP server.

I have configured DHCP Boot Options, as described in this KB article: https://docs.sophos.com/nsg/sophos-firewall/19.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Network/DHCP/NetworkDHCPBootOptions/index.html#introduction

Please note that as of recent XG changes, CLI entries are supposed to be no longer needed to make this work, as DHCP Options 66 and 67 are now included in the GUI (as per this KB article linked above):

Based on the KB article, it it supposed to be as simple as this, and should work. Currently, my clients are on the same subnet as the TFTP store, and there should be no need for additional firewall policies to make this work. However, when attempting to boot a PXE client, I get the following error:

You can see, that my PXE clients are being issues their IP address by the Sophos XG, inside the same subnet scope as the Synology is 10.10.10.17. The XG looks like it is attempting to pass the DHCP boot options to the client, but there is a server response timeout. I have confirmed with other TFTP clients that the files are located exactly at the path located in the Boot Options screenshot, two pictures above, and am able to use TFTP GET to retrieve them easily without authentication. Because the "Server IP address" is 10.10.10.1, I'm unsure whether this is failing because the XG appliance is not forwarding the GET request to the TFTP share on behalf of the client, or if there is an error in communication between the XG and Synology.

A look at firewall logs suggests that the XG never attempts to forward the request at all. All traffic coming from the PXE client is destined for the XG (10.10.10.1) with destination port 69 (TFTP), but is denied due to "Appliance Access" which after reading, is generic enough to not really get a good answer on. There is NO destination traffic to the TFTP server at all, from the XG or the PXE client.

I know that a common suggestion is to use DHCP relay, however, these devices are on the same subnet. I do not wish to have multiple DHCP servers on this segment, so really would like to get DHCP options working as this KB article intended. At this time, I am unsure what else to do except for configuring various policies/NAT rules in at attempt to make this work, but there really should not need to be any routing or translation done at all since this setup is so simple.

Any help is much appreciated!

Thanks!



This thread was automatically locked due to age.
Parents
  • Hi 

    please check your switch to see if it is setup to broadcast requests? You will see the XG logging the traffic as fails because the traffic is hitting the XG regardless of setup.

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

Reply
  • Hi 

    please check your switch to see if it is setup to broadcast requests? You will see the XG logging the traffic as fails because the traffic is hitting the XG regardless of setup.

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

Children
  • Hi Ian,

    Thanks for the suggestion. I verified that the switch is broadcasting requests. From reviewing the switch logs, I can see that the DHCP request goes to the XG, the XG responds with an address offer as well as option information for next-server and boot-file, and that the client accepts the address. I never see any additional traffic after this from the PXE client, it simply times out and as far as I can tell never actually initiates the TFTP transfer for the boot file. I'm unsure if the PXE client is behaving unexpectedly, or if the request is getting dropped by the switch somewhere. I have tried disabling IGMP and DHCP snooping as well, both with no success. ):