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

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

PXE Boot DHCP Option 66 + 67 - Client falsely using the Firewall IP-Address as TFTP Server

I'm trying to copy a PXE Boot Optin from the DHCP Server of a UTM to Sophos XGS

The problem I face is, the Boot Client uses the IP-Address of the Firewall/DHCP Server as TFTP Server instead of the value provided in the Option 66 (Next Server)

I tried with GUI

and with CLI

system dhcp dhcp-options binding add dhcpname my-dhcpservername optionname TFTP_Server_Name(66) value '172.16.1.2/bblefi-x64/shim_x64.efi'

console> system dhcp dhcp-options binding add dhcpname my-dhcpservername optionname TFTP_Server_Name(66) value '172.16.1.2'
DHCP option TFTP_Server_Name(66) added for DHCP Server my-dhcpservername.

console> system dhcp dhcp-options binding add dhcpname my-dhcpservername optionname Bootfile_Name(67) value '\bblefi-x64\shim_x64.efi'
DHCP option Bootfile_Name(67) added for DHCP Server my-dhcpservername.

console> system dhcp dhcp-options binding show dhcpname my-dhcpservername
Options Configured from GUI
---------------------------
xxx-removedbyauthor-xxx


Options Configured from CLI
---------------------------
TFTP_Server_Name(66)                                        "172.16.1.2"
Bootfile_Name(67)                                           "\\bblefi-x64\\shim_x64.efi"

and get the same result at the client:

192.168.32.1 is the sophos firewall

it should use 172.16.2.1 but it does not

172.16.2.1 is behind a IPSEC-VPN from the perspective of the Client.

That is the IP-Address of the Firewall that is also the DHCP Server.

Then I tested this - I found it in an other post here from Sophos Staff but with that value, the Client did not receive an IP Address at all. It already looks ugly.

console> system dhcp dhcp-options binding add dhcpname my-dhcpservername optionname TFTP_Server_Name(66) value '172.16.1.2/bblefi-x64/shim_x64.efi'
DHCP option TFTP_Server_Name(66) added for DHCP Server my-dhcpservername.

console> system dhcp dhcp-options binding show dhcpname my-dhcpservername
Options Configured from GUI
---------------------------
xxx-removed-xxx
Options Configured from CLI
---------------------------
TFTP_Server_Name(66)                                        "172.16.1.2/bblefi-x64/shim_x64.efi"

In a tcp dump, it all looks fine so far - the offer includes the correct IP:

    Option: (54) DHCP Server Identifier (192.168.32.1)
        Length: 4
        DHCP Server Identifier: 192.168.32.1
    Option: (51) IP Address Lease Time
    Option: (1) Subnet Mask (255.255.255.128)
    Option: (3) Router
    Option: (6) Domain Name Server
    Option: (15) Domain Name
    Option: (66) TFTP Server Name
        Length: 13
        TFTP Server Name: 172.16.1.2
    Option: (67) Bootfile name
        Length: 23
        Bootfile name: bblefi-x64\shim_x64.efi
    Option: (255) End
        Option End: 255

But then the Client uses the Firewall IP again instead of the real Server IP in TFTP communication:

Any idea?



This thread was automatically locked due to age.
  • Thanks for all the digging, i had a support case of my own to get this resolved, same reply.

    I can confirm that the Sophos DHCP doesnt send the "next server ip adress" entry, in comparison with our old Windows DHCP Server which does. How that is not a feature, i don't know.

    The way i got my PXEboot working again is by letting the PXE Server send out its own DHCP offer (tried with WDS), so that the Client gets its IP from Sophos and PXE info from the WDS.

    Hope this helps you as much as your digging helped me

    cheers

  • PXE Server send out its own DHCP offer

    How does the communication between PXE client and PXE Server and server happen here? Is that all unicast?

    So client gets PXE Server IP from Sophos and is then sending unicast to it and getting unicast offer back?

    Do you require DHCP Server on the WDS Server for it?

  • You can set the WDS Server to "Answer all Clients" in the WDS Configuration tool.

    This prompts the WDS Server to react to DHCP/PXE requests it receives with giving out its information, including the "next server ip address"

    which then makes the client ask the WDS for a boot file based on its vendor class (i think, not 100% sure thats exactly what happens), and bam, PXE boot.

    Be aware that DHCP requests get dropped when going through a router/firewall, so the WDS has to be in the same network as the client, or you'll have to work with a DHCP relay. Also, you'll have to disable options 66, 67 on the Sophos DHCP, so the client doesnt get conflicting information.

    I don't know if other PXE Servers have this kind of option or how that works on other systems, but that is how it works for me, setting up laptops and PCs from a preconfigured image using WDS.

  • Thanks for this information.This may be suitable for mid-size remote locations. In our case we have some small remote sites, with a few clients only, no servers. Having a fast Internet line, it would have been no problem to let them PXE boot over WAN against a server located on the main site.

    Now with the limitations of the Sophos Firewall DHCP Server, we would need to setup 3rd party DHCP server on site or do PXE relay to the main site DHCP server - but the downside is that when there is trouble with the VPN connection, they don't get any DHCP address at all.

  • Yeah, kinda sucks that Sophos doesn't support that feature yet, as it seems pretty basic.

    I'll try to put in a feature request myself tomorrow, hopefully that will put a permanent solution on a higher priority.

  • our idea is now, that whenever we need to PXE boot a client at a small remote location to get it reinstalled, we disable the XG DHCP Server and start the DHCP Server Application tool of our choice (dhcpserver.de) on an other computer in the same network. Have it configured with the required ini options. And then do the network boot of the client that needs the reinstall. When boot is done, we stop the DHCP Server app and start XG DHCP Server again.

    If anyone is going that way, this dhcpsrv.ini works for PXE boot with next server and bootfile + options 66,67

    [SETTINGS]
    IPPOOL_1=192.168.123.246-246 ; one IP in Range only
    IPBIND_1=192.168.123.28 ; IP of computer where dhcpsrv runs
    AssociateBindsToPools=1
    Trace=1
    DeleteOnRelease=0
    ExpiredLeaseTimeout=3600

    [EC-79-49-4E-DF-C4] ; a DHCP reservation for a single machine
    IPADDR=192.168.123.246

    [GENERAL]
    LEASETIME=1800
    NODETYPE=8
    SUBNETMASK=255.255.255.0
    BOOTFILE=\bblefi-x64\shim_x64.efi ; your custom PXE boot file
    NEXTSERVER=192.168.234.1 ; your TFTP Server IP
    DNS_0=192.168.123.1 ; some DNS Servers
    DNS_1=192.168.234.2
    ROUTER_0=192.168.123.1 ; probably your Sophos Firewall IP
    OPTION_66="yourTftpServerName-or-IP.yourdomain.local" ; your TFTP Server FQDN or IP
    OPTION_67="\bblefi-x64\shim_x64.efi"

  • Resurrecting an old thread, we are facing the same issues.

    Our workaround for now is to set a DNAT rule to our destination tftp server on the local network with MASQ for the reverse direction. This way the XG appliance acts like a proxy for our tftp until this will be fixed.

    Hops this helps!

  • Hi Patrick,

    Thank you for reaching out to Sophos Community, and thank you for sharing the workaround.

    Erick Jan
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • Hello, could you attach a screen with this rule to better understand this set.

  • Hi Pawel,

    for sure! we are running on German language, but I commented the important parts Slight smile

    Cheers!

    firewall rule

    NAT rule