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
  • Why should be the firewall be involved in this traffic? 
    It is the same subnet, so the client should be able to reach the TFT Server by itself? 

    Did you configure the tft Server to be 10.10.10.17? 

    __________________________________________________________________________________________________________________

  • Hi LuCar,

    I agree that the firewall should not be involved in this traffic. I eventually would like to test this setup with a DHCP Relay to a different subnet where the firewall will be involved, but currently need to get it testing as proof of concept on this subnet.

    This primary reason for this post, was I believe I am missing something on the firewall configuration. Since the firewall is distributing option 66/67 information with the address offer, I was hoping someone more experienced with these PXE clients would be able to shed some light on something I had missed.

    To your question, yes, the TFTP server is at 10.10.10.17 and I can easily pull the file with any TFTP client using 'TFTP 10.10.10.17 GET ipxe64.efi' I have tried numerous ways to configure the TFTP server which I do not believe is the issue since the server never receives the request.

    I initially thought that the primary issue was that the firewall was NOT distributing option 66/67 information. Since, I have analyzed the switch traffic to see that the option information is getting passed. I am about to make an edit to my primary post, that, I have since added DHCP option 13 to set boot-size of the boot file. This has changed the behavior of the PXE client which now says 'Downloading NBP file...' but still ends up with the same PXE-E18 timeout error.

    I'm hoping maybe someone could use their expertise to point out that I'm missing an additional DHCP option that could be useful in resolving this, or likewise.

    Much thanks for the reply!

  • What i do not understand, why is doing the client a request to the Firewall port 69? 

    Shouldnt this be the server? 

    __________________________________________________________________________________________________________________

  • Yes, I believe that is correct. The DHCP server should be distributing the TFTP server information with the address offer (which it appears it does) and the PXE client should be making the request separately to the TFTP server. As far as I can tell, no request is ever actually made to the TFTP server, only to the firewall for some reason. I feel like a bit of an idiot, this should be simple. Maybe my issue is with the clients ignoring the next-server option and requesting directly from the firewall? That's my only guess as of this moment.

Reply
  • Yes, I believe that is correct. The DHCP server should be distributing the TFTP server information with the address offer (which it appears it does) and the PXE client should be making the request separately to the TFTP server. As far as I can tell, no request is ever actually made to the TFTP server, only to the firewall for some reason. I feel like a bit of an idiot, this should be simple. Maybe my issue is with the clients ignoring the next-server option and requesting directly from the firewall? That's my only guess as of this moment.

Children
No Data