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
  • Before you start to troubleshoot the initial DHCP discovery stage of the PXE booting process, consider the following points:

    In SMSPXE.log, you should see the MAC address or the DHCPREQUEST of the device that you're trying to start. If you don't see that, a router configuration issue might exist between the client and the DP.
    Don't use DHCP options 60, 66, or 67. It isn't supported.
    Test whether the device can start when it's plugged into a switch on the same subnet as the PXE-enabled DP. If it can, the issue likely involves the router configuration.
    Make sure that the DHCP (67 and 68), TFTP (69), and BINL (4011) ports are open between the client computer, the DHCP server, and the PXE DP.
    At this stage, there are no logs to refer to. A PXE error code is usually displayed if the PXE boot process fails before WinPE starts. Here are examples of the error messages that you might see:

    PXE-E51: No DHCP or proxyDHCP offers were received.
    PXE-E52: proxyDHCP offers were received. No DHCP offers were received.
    PXE-E53: No boot filename received.
    PXE-E55: proxyDHCP service did not reply to request on port 4011.
    PXE-E77 bad or missing discovery server list.
    PXE-E78: Could not locate boot server.
    Although it helps narrow the focus of troubleshooting, you might still have to capture a network trace of the issue by using a network monitoring tool, such as Netmon or WireShark. The network monitoring tool must be installed on both the PXE-enabled DP and a computer that's connected to a mirrored port on the switch. For more information about how to configure mirrored ports, refer to the manual provided by the manufacturer of the specific switch or routing device.

    Regards,

    Rachel Gomez

  • Hi Rachel,

    Thanks you for your reply, but unfortunately most of your post does not apply to my scenario.

    I'm not using SCCM for this deployment, so I will not have an SMSPXE log file. There are no windows devices involved in this deployment.

    These devices are already plugged into the same network switch, in the same VLAN on the same broadcast domain. I don't know what I could use instead of DHCP options 66/67, since these are devices on the same network which eliminates DHCP relay and I do not want to add an additional DHCP server to this subnet.

    I initially thought that the XG was not distributing option 66/67 information, which since analyzing switch traffic I have found out is not true. The XG is distributing option information as it is configured to. When I attempt to boot the PXE client, I initially received a response that the boot file was 0 bytes (which it was not), followed by a PXE-E18 timeout. I have since added DHCP option 13, which changed behavior of the PXE client, which now states "Downloading NBP file..." followed by the same PXE-E18 error. From analysis of switch traffic, it appears that the PXE client never even attempts to make a broadcast request for the TFTP server to get the boot file. The TFTP logs show no attempt at access, and the switch logs show no activity from the MAC/IP after the client received its offered configuration from the XG DHCP server. It appears that clients are simply ignoring the DHCP next-server option that they are distributed, even though the file path to the boot-file does show up on the clients.

    Appreciate any suggestions for this setup. Should be simple but is not ):

Reply
  • Hi Rachel,

    Thanks you for your reply, but unfortunately most of your post does not apply to my scenario.

    I'm not using SCCM for this deployment, so I will not have an SMSPXE log file. There are no windows devices involved in this deployment.

    These devices are already plugged into the same network switch, in the same VLAN on the same broadcast domain. I don't know what I could use instead of DHCP options 66/67, since these are devices on the same network which eliminates DHCP relay and I do not want to add an additional DHCP server to this subnet.

    I initially thought that the XG was not distributing option 66/67 information, which since analyzing switch traffic I have found out is not true. The XG is distributing option information as it is configured to. When I attempt to boot the PXE client, I initially received a response that the boot file was 0 bytes (which it was not), followed by a PXE-E18 timeout. I have since added DHCP option 13, which changed behavior of the PXE client, which now states "Downloading NBP file..." followed by the same PXE-E18 error. From analysis of switch traffic, it appears that the PXE client never even attempts to make a broadcast request for the TFTP server to get the boot file. The TFTP logs show no attempt at access, and the switch logs show no activity from the MAC/IP after the client received its offered configuration from the XG DHCP server. It appears that clients are simply ignoring the DHCP next-server option that they are distributed, even though the file path to the boot-file does show up on the clients.

    Appreciate any suggestions for this setup. Should be simple but is not ):

Children
No Data