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

Hi LHerzog ,

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,

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,

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"

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"

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.