ipxe boot slow after changing to HTTPS
-
@brakcounty As I said this is not normal I reckon. From what we heard so far I can imagine some kind of security gatway causing the delay while checking HTTPS traffic. Though on the other hand that would need to be a highly sofisticated transparent proxy setup. Please check with your network team.
Other than that I suggest you do manual tests in your browser. Open Chrome or Firefox development tool bar and then load the boot.php and other URLs you find having the delay. See if you can find out what is causing it.
As a next step you probably need to install wireshark on the PC and capture the network traffic. Feel free to send me a private message with a download link to the saved wireshark pcap file if you need help with reading it.
-
@Sebastian-Roth That was my next guess but wanted to confirm that it wasn’t normal. Thanks!
-
Ok so I browsed these links on my desktop using Firefox, and they loaded instantly:
https://<fog-ip>/fog/service/ipxe/boot.php - 96ms
https://<fog-ip>/fog/service/ipxe/boot.php##params - 96msWe do in fact scan all traffic, but I noticed that the delay is only during ipxe ops.
I’ll run wireshark next.
-
@brakcounty said in ipxe boot slow after changing to HTTPS:
We do in fact scan all traffic, but I noticed that the delay is only during ipxe ops.
So maybe the scan only happens (or is only being delayed) when the request header is not a normal browser?
-
@Sebastian-Roth I confirmed with our network team that we scan traffic by protocol, so even if an app that isn’t a browser makes an HTTP/S connection, it will get scanned.
-
@brakcounty So we still need to figure out why the browser gets a quick response while iPXE does not?! Probably using tcpdump/wireshark as mentioned or even better asking your network team to look into it.
You can to more tests as well, either download wget or curl for windows to test. Or you can boot up a Linux live OS CD to do the same testing.
-
@Sebastian-Roth I just did some testing on my desktop, which is on a different vlan than the fog server, but shouldn’t matter:
On my Windows console:
curl and wget https://10.240.160.59/fog/service/ipxe/boot.php both show this message:
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.I also have Linux sub-system on my Windows box:
curl https://10.240.160.59/fog/service/ipxe/boot.php
curl: (60) SSL certificate problem: self signed certificate in certificate chainwget https://10.240.160.59/fog/service/ipxe/boot.php
–2023-02-21 13:26:44-- https://10.240.160.59/fog/service/ipxe/boot.php
Connecting to 10.240.160.59:443… connected.
ERROR: cannot verify 10.240.160.59’s certificate, issued by ‘CN=FOG Server CA’:
Self-signed certificate encountered.
To connect to 10.240.160.59 insecurely, use `–no-check-certificate’.Obviously, I don’t have FOGs cert installed on my Windows PC, which I don’t need since I’m not doing any pxe ops from it.
I’m going to see if I can set up a VM to pxe boot while running wireshark in the bg.
EDIT: I have a Hyper-V vm booting to FOG via USB Boot method. I have a vm storage volume that has the bootx64.efi and I boot from that to start the iPXE boot process.
-
@brakcounty Sure thing you need to tell curl/wget to ignore/accept the non-official certificate:
wget --no-check-certificate ...orcurl -k ... -
@Sebastian-Roth Ran from a console, instant. Still working on getting an accurate pcap.
root@mypc:~/scripts# curl https://fogserverip/fog/service/ipxe/boot.php -k #!ipxe set fog-ip fogserverip set fog-webroot fog set boot-url https://${fog-ip}/${fog-webroot} set storage-ip fogserverip set keymap us cpuid --ext 29 && set arch x86_64 || set arch i386 iseq ${platform} efi && set key 0x1b || set key 0x1b iseq ${platform} efi && set keyName ESC || set keyName Escape prompt --key ${key} --timeout 3000 Booting... (Press ${keyName} to access the menu) && goto menuAccess || exit :menuAccess login params param mac0 ${net0/mac} param arch ${arch} param platform ${platform} param username ${username} param password ${password} param menuaccess 1 param debug 1 param sysuuid ${uuid} isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme :bootme chain -ar https://fogserverip/fog/service/ipxe/boot.php##params root@mypc:~/scripts# wget https://fogserverip/fog/service/ipxe/boot.php --no-check-certificate --2023-02-22 11:54:54-- https://fogserverip/fog/service/ipxe/boot.php Connecting to fogserverip:443... connected. WARNING: cannot verify fogserverip's certificate, issued by ‘CN=FOG Server CA’: Self-signed certificate encountered. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘boot.php.1’ boot.php.1 [ <=> ] 813 --.-KB/s in 0s 2023-02-22 11:54:55 (180 MB/s) - ‘boot.php.1’ saved [813] -
@brakcounty Ok, from the tests we have done so far it kind of looks like this is going to be an iPXE network driver issue. Interesting I have not thought of this before.
Have you tried different iPXE binaries yet? ipxe.efi vs. snponly.efi? ipxe.pxe vs. undionly.kkpxe?
-
@Sebastian-Roth I haven’t tried different binaries yet. Wouldn’t I have to recompile them to use HTTPS? Did the -s switch during setup automatically compile all those efi binaries and place them into /tftproot?
-
Now that you’ve mentioned ipxe driver issue, it seems more likely. The delay is longer on my xencenter VMs vs VirtualBox VMs and physical PCs.
-
@brakcounty said in ipxe boot slow after changing to HTTPS:
Did the -s switch during setup automatically compile all those efi binaries and place them into /tftproot?
Yes.
-
Booting from snponly.efi doesn’t recognize the network adapter. I tried using Intel and ParaVirt in VirtualBox.
-
@brakcounty Try out different ones, like
intel.efifor example. -
@brakcounty and @Sebastian-Roth
I recently did a fresh install of a fog dev server and did https and experienced similar slowness on the kernel loading.
I’ll give some of this testing a try and report back to see if this is maybe more common than we think. -
@Sebastian-Roth I tried intel.efi, still slow.
-
@brakcounty said in ipxe boot slow after changing to HTTPS:
The delay is longer on my xencenter VMs vs VirtualBox VMs and physical PCs.
Let’s go back to this information. Are physical PCs as fast as it used to be with plain HTTP?
I do use VirtualBox in my test setups and never saw it going slow on HTTPS.
-
@Sebastian-Roth physical PCs are still slower on HTTPS than HTTP. I was saying that the delay is exacerbated on VMs, especially slow (the slowest in fact) on XCP-NG guests. VirtualBox is better, physical is fastest. All three environments are still slower using HTTPS vs HTTP. I remember how instant HTTP was on any platform.
-
I just want to reiterate that when I say slow/fast, I’m referring to the time it takes to initiate a download (get) of a file via HTTPS. Once the download starts, then the speed is fine.
