Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 42 subscribers
  • Views 5430 views
  • Users 0 members are here
Options
Suggested
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

Hard_Working_LANman

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.
  • 0

    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.0.3 MR-3 - Home

    XG on VM 8 - v21 GA

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

  • 0

    Hello ,

    Thank you for reaching out to the community, you can also refer the following community link if it helps: https://community.sophos.com/sophos-xg-firewall/f/discussions/134758/help-me-to-configuration-of-dhcp-option-66-67-for-pxe-in-sophos-firewall/497547

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Technical Support, Global Customer Experience

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case  | Security Advisories 
    Compare Sophos next-gen Firewall | Fortune Favors the prepared
    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to rfcat_vk

    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. ):

  • 0 in reply to Vivek Jagad

    Hi Vivek,

    Thank you for posting your suggestion. I have previously read the linked article which is outdated for the current version of XG, however the article does link to other pages that do apply to the current version that I have also read. Unfortunately, I have not been able to find a resolution to this issue. I have been able to discover through traffic logging and review, that the XG is sending option 66/67 information with the address offer, but after that the chain dies and I see no further traffic from the PXE client (to the XG or the TFTP server) and the operation simply times out.

  • 0

    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? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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!

  • 0 in reply to Hard_Working_LANman

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

    Shouldnt this be the server? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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.

  • 0

    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

  • 0 in reply to 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 ):

Unfiltered HTML