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

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.

We are facing the same issue, but with Sophos UTM 9.714-4.
We have to deploy ip based deskphones and they use the tftp address to know where to look for the central management.
In UTM the DHCP option is called "tftp-server-name", but its the same Code 66.
If the client phones get a dhcp address from the firewall they recieve their ip address, netmask, gateway and dns correctly, but tftp stays empty.
I have tried it with windows dhcp server, but that one is sending out the ip address of the first set DNS server as TFTP instead of the set parameter.

Main difference to your case: I did not specify a boot file since that is automatically chosen depending on the ip deskphone type.

Update: I just rechecked the Sophos UTM. TFTP Server and Next Server are different setable options.
After also setting the "Next Server" flag to the wanted tftp address it worked. the clients recieved the correct address from the sophos utm dhcp.
Maybe you need to set the "Next Server" flag via CLI additionally? 

Maximilian Wild said:

Maybe you need to set the "Next Server" flag via CLI additionally? 

unfortunately that is not possible. The XG Setting is called Next Server on GUI but is uses 66 on the backend.

On CLI there is nothing to configure Next server, only Option 66.

And we have it also working on UTM. That is just a missing feature on XG if not a bug (Next Server on GUI).

asked  the support tech if that (orange text) is testworthy:

edit that file dhcpd.conf manually and reload dhcpd after like followed:

/cfs/system/dhcp/dhcpd.conf

shared-network reds28 {

        subnet 192.168.9.40 netmask 255.255.255.248 {

        }

        pool {

                 # DHCPCONFID=15;

                 range 192.168.9.42 192.168.9.44;

                 ping-check false;

                 server-identifier 192.168.9.41;

                 option subnet-mask 255.255.255.248;

                 option routers 192.168.9.41;

                 option domain-name-servers 192.168.9.41;

                 option bootfile-name "test.efi";

                 option tftp-server-name "192.168.9.45";

                 filename "test.efi";

                 next-server 192.168.9.45;

                 max-lease-time 172800;

                 default-lease-time 86400;

        }

}

Most likely this will at at least get overwritten, when someone changes a DHCP setting somewhere else on GUI. Don't want to test this unless I have OK from support for that.

Tech Support closed my support case now with status

This is to inform you that under this JIRA NC-117690, the issue is considered as feature request (...) please contact your Reseller or local Sales Engineer. 

The question about changing the config as asked above is still unanswered.