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.
Parents
  • Hi  ,

    Good day and thanks for reaching out to Sophos Community and hope you are well. 

    I'm sorry you are facing this concern, It seems you have already referred to past threads and unable to work towards a resolution. I may recommend you to open a support ticket to have this further checked while replicating the issue. Kindly share to us the would be generated caseID via DM or by replying to this thread. 

    Many thanks for your time and patience and thank you for choosing Sophos

    Cheers,

    Raphael Alganes
    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.

  • this is the DHCP Offer from a windows DHCP Server which is working compared with the Offer of the XG DHCP Server

    PXE Boot works when we use a Windows DHCP Server. The XG does DHCP Relay to the Windows DHCP Server.

    You can see next server and boot file is not included in the XG DHCP server's offer.

    Looks very much like a bug to me - because on the XG Web Admin it's listed as "next server" and "boot file" explicitely but is not served. Served are only DHCP Options 66 and 67

  • created a new case for this topic

    06372787

  • Hello there,

    Thanks for providing this. This is currently being investigated and Engr will provide an update per his last sent email to you. 

    Kindly let us know if you need any further assistance from our end. 

    Many thanks for your time and patience and thank you for choosing Sophos

    Cheers,

    Raphael Alganes
    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.

  • Just curious. Looking at those Dumps and the tcpdump above, why are they different? 

    In the tcpdumps above, you see the values given as expected. In your wireshark dump, you are not. 

    11:38:54.318771 xglaninterface, OUT: IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 359)
    192.168.9.193.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 331, xid 0x4123e46d, Flags [Broadcast]
    Your-IP 192.168.9.195
    Client-Ethernet-Address e4:46:b0:16:9b:40
    Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Offer
    Server-ID Option 54, length 4: 192.168.9.193
    Lease-Time Option 51, length 4: 84380
    Subnet-Mask Option 1, length 4: 255.255.255.248
    Default-Gateway Option 3, length 4: 192.168.9.193
    Domain-Name-Server Option 6, length 4: 192.168.9.193
    Domain-Name Option 15, length 14: "internaldomain.lan"
    TFTP Option 66, length 13: "172.16.1.2"
    BF Option 67, length 24: "\bblefi-x64\shim_x64.efi"

    __________________________________________________________________________________________________________________

Reply
  • Just curious. Looking at those Dumps and the tcpdump above, why are they different? 

    In the tcpdumps above, you see the values given as expected. In your wireshark dump, you are not. 

    11:38:54.318771 xglaninterface, OUT: IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 359)
    192.168.9.193.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 331, xid 0x4123e46d, Flags [Broadcast]
    Your-IP 192.168.9.195
    Client-Ethernet-Address e4:46:b0:16:9b:40
    Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Offer
    Server-ID Option 54, length 4: 192.168.9.193
    Lease-Time Option 51, length 4: 84380
    Subnet-Mask Option 1, length 4: 255.255.255.248
    Default-Gateway Option 3, length 4: 192.168.9.193
    Domain-Name-Server Option 6, length 4: 192.168.9.193
    Domain-Name Option 15, length 14: "internaldomain.lan"
    TFTP Option 66, length 13: "172.16.1.2"
    BF Option 67, length 24: "\bblefi-x64\shim_x64.efi"

    __________________________________________________________________________________________________________________

Children
  • By the way, sometimes it helps to convert this to HEX and use the hex values:  How to enter special-characters like '&' to DHCP-option string-values ? 

    __________________________________________________________________________________________________________________

  • I don't know. Both dumps were taken at the firewall. The one is only txt, the other was opened in wireshark later.

    I guess that is just better visiblity caused by wiresharks DHCP analysis.

    The DHCP options are served well by XG DHCP. Only the next server and boot file are missing. And I cannot enter them with a command. Only Options can be entered and - if I had them - I could enter some special characters as hex directly.

    I guess what I need to do next is compare the answer from XG with the answer by SG Firewall or Windows DHCP and see if there is just some formatting issue or so.

  • So there is a difference in the hex code of the DHCP offer.

    Probably it is some kind of marker to use what comes next in the boot option 66

    And the XG does not use that marker - only the windows server does:

    So on the left side: HEX ac 10 cd 22                                                and on the right: HEX c0 a8 09 c3

    And the boot file name is completely empty on XG offer:

    Unfortunately I'm not so familiar with coding DHCP packets so I don't know if my suspection is correct and if that can be changed somehow in the DHCP offer sent by XG.

  • probably not relevant but I found that blank space in the Windows DHCP offer in front and at the end of the boot file code irritating. I double checked it on the server and there is not blank space in the setting.

  • What happen, if you convert both values to HEX and enter them to SFOS? 

    __________________________________________________________________________________________________________________

  • XG DHCP Server is no longer working when I add values as HEX this way:

    system dhcp dhcp-options binding add dhcpname myinterface optionname Bootfile_Name(67) value 5C:62:62:6C:65:66:69:2D:78:36:34:5C:73:68:69:6D:5F:78:36:34:2E:65:66:69

    \bblefi-x64\shim_x64.efi = 5C:62:62:6C:65:66:69:2D:78:36:34:5C:73:68:69:6D:5F:78:36:34:2E:65:66:69

    That HEX is then also shown in GUI

    but I do not get DHCP Offer.

    And that with prefix 00:00:04:03:67 also results in non working DHCP:

    system dhcp dhcp-options binding add dhcpname myinterface optionname Bootfile_Name(67) value 00:00:04:03:67:5C:62:62:6C:65:66:69:2D:78:36:34:5C:73:68:69:6D:5F:78:36:34:2E:65:66:69

    Regardless of adding 00 at the end or not

    console> system dhcp dhcp-options binding add dhcpname myinterface optionname Bootfile_Name(67) value 00:00:04:03:67:5C:62:62:6C:65:66:69:2D:78:36:34:5C:73:68:69:6D:5F:78:36:34:2E:65:66:69:00

    that's how it looks on GUI

    So I deleted that again - perhaps it worked with SFOS 5 years ago but not today.