Issue with EFI through PFSense Firewall

[george1421]

@jonhwood360 While I find this a bit confusing lets see if this solves the issue.

in the isc-dhcp server config file modify this section

    option domain-name-servers 10.255.252.5;
    option domain-name "jukebox.local";
    ddns-domainname "jukebox.local.";
    ddns-rev-domainname "in-addr.arpa.";
    next-server 10.255.252.5;
    class "Legacy" {

Between next-server and class insert this line

option tftp-server-name 10.255.252.5;

Then for every instance of “filename…”; just below that line enter

option bootfile-name "<boot_file>";

Where <boot_file> matches the boot file name issued by the filename command.

Save that config and restart the dhcp server. If that fixes the pxe booting issue then go in and comment out the filename lines, restart the dhcp server and see if that still works for bios and uefi. You might want to grab a pcap to ensure the header (bootp) and dhcp options are still being set. I think the bootfile-name command should set both.

[jonhwood360]

@george1421 said in Issue with EFI through PFSense Firewall:

Between next-server and class insert this line
option tftp-server-name 10.255.252.5;

Then for every instance of “filename…”; just below that line enter
option bootfile-name “<boot_file>”;

Where <boot_file> matches the boot file name issued by the filename command.

George,

Just wanted to take a moment to thank you for helping to troubleshoot this with me.

I did as you requested.

if the “option tftp…” line is enabled the dhcp server will fail to start. Isn’t it the case for isc-dhcp-server that the “next-server …” line is the equivalent?

if I disable the next-server line and just use “option tftp” it also fails to start:

if I leave the “option boot-file…” lines in and leave “next-server…” on and “option tftp…” off, the server starts

However there is no difference in boot either in a VM, or hardware. I did however snag this screenshot (sorry for the glare) from the laptop which might shed some light.

I then reverted my dhcpd.conf to without the changes you recommended and confirmed the same result, sans the square at the end of the filename. Still same PXE error.

So it appears that the dhcp exchange for EFI mode on the computers are happening, they are getting the right configuration data, but the data is getting mangled at some point.

Any thoughts?

[george1421]

@jonhwood360 OK I know this now. That unprintable character is what is causing the issue. I see that in some “university” dhcp servers. Let me look at your pcap again.

[jonhwood360]

@george1421 said in Issue with EFI through PFSense Firewall:

@jonhwood360 OK I know this now. That unprintable character is what is causing the issue. I see that in some “university” dhcp servers. Let me look at your pcap again.

Just a note, once I reverted my config to my original without alterations, that character went away.

[george1421]

@jonhwood360 But I assume it still doesn’t boot.

So without the config file alterations you don’t get the screen about filesize 0 bytes, but with the alterations you get that error. Just thinking about it a bit more I think we are on the right direction, maybe just not the right path.

Did you get a workstation pcap of the process where you received the 0 bytes filesize? I’m interested to know if dhcp options 66 and 67 were being set, where it was actually kind of working. If they were there with those settings and the settings were the key for uefi dhcp booting then we just need to work on why the settings were wrong. I didn’t get a chance last night to test this in my home lab where I have a ubuntu server to understand why the settings stopped isc-dhcp from booting. But I’ll look at it tonight if we can’t get it sorted out. The commands I gave you were from the isc-dhcp config file.

[jonhwood360]

@george1421 said in Issue with EFI through PFSense Firewall:

@jonhwood360 But I assume it still doesn’t boot.

So without the config file alterations you don’t get the screen about filesize 0 bytes, but with the alterations you get that error. Just thinking about it a bit more I think we are on the right direction, maybe just not the right path.

Did you get a workstation pcap of the process where you received the 0 bytes filesize? I’m interested to know if dhcp options 66 and 67 were being set, where it was actually kind of working. If they were there with those settings and the settings were the key for EFI DHCP booting then we just need to work on why the settings were wrong. I didn’t get a chance last night to test this in my home lab where I have a ubuntu server to understand why the settings stopped isc-DHCP from booting. But I’ll look at it tonight if we can’t get it sorted out. The commands I gave you were from the isc-DHCP config file.

No no, I get the same error, just without the unprintable character.

So, yes option 66 (next-server) and 67 (filename) are being set. If I set the Endpoint VM to BIOS, it works fine in the external network.

If I put the endpoint in the same network as the DHCP server, both EFI and BIOS works fine.

I’ll check to make sure the DHCP settings between internal subnet and external subnet are the same (sans the obvious IP changes)

Thanks again for helping!

[jonhwood360]

@george1421

so one thing I keep seeing in the packet capture which is weird, is that the router option (3) is set to 10.255.252.1 which is the gateway that the fog server uses, but is not the gateway for the external network. .

and I figured out why the tftp-server-name line you gave me didn’t work. It was expecting a dns name, not an IP, there is a tftp-server-address option, which I set and did work (config loaded). This did not change anything though.

[george1421]

@jonhwood360 Do you have the option to use a mirrored network port on the external network? This would give us the best fidelity to the network exchange. On a witness port we can only see the broadcast (dhcp) side of the conversation. We miss all of the unicast traffic. There has to be something different in the exchange between a bios and uefi modes on the same computer. The same exact protocols are used so the firewall shouldn’t be blocking. While this mostlikely is not the case here, we have seen a smaller MTU than 1468 cause tftp issues. Smaller MTUs than 1468 cause the tftp packet to fragment and the receiving computer will reject the file transfer. But one would think if that was the case bios and uefi would be the same.

[george1421]

@jonhwood360 said in Issue with EFI through PFSense Firewall:

so one thing I keep seeing in the packet capture which is weird, is that the router option (3) is set to 10.255.252.1 which is the gateway that the fog server uses, but is not the gateway for the external network. .

Well lets think about this for a minute. When I looked at the packet capture I did notice the lease times were different too.

Looking at the config file you provided both the lease times and route address are set correctly. Why are we seeing a difference in the packet captures from the configuration. Its almost like we have a different dhcp server for bios than uefi. Or two instances running with different config files on the FOG server.

[jonhwood360]

@george1421 said in Issue with EFI through PFSense Firewall:

@jonhwood360 said in Issue with EFI through PFSense Firewall:

so one thing I keep seeing in the packet capture which is weird, is that the router option (3) is set to 10.255.252.1 which is the gateway that the fog server uses, but is not the gateway for the external network. .

Well lets think about this for a minute. When I looked at the packet capture I did notice the lease times were different too.

Looking at the config file you provided both the lease times and route address are set correctly. Why are we seeing a difference in the packet captures from the configuration. Its almost like we have a different dhcp server for bios than uefi. Or two instances running with different config files on the FOG server.

Yep. The only thing I can figure is that somehow either the DHCP Relay or Arp Proxy in Pfsense is doing something weird, or the DHCP server is not processing my second range definition in its entirety (which is weird because booting into an OS proper, the exchange happens normally and gets the right settings).

Although in the mean time I have had to move along in my research so I moved the DHCP/ Bind DNS to PFsense and have configured it to have the correct options. EFI boot from fog server is working in this new configuration. I am leaving the existing configuration in place on the fog server though to return to this issue (which I think has value to try and solve).