@Sebastian-Roth Definitely looks like it is isolated to ipxe.

@Sebastian-Roth said in ipxe boot slow after changing to HTTPS:

I have never seen this on my HTTPS setups

Out of curiosity, what NICs do you typically run ipxe on?

@Sebastian-Roth said in ipxe boot slow after changing to HTTPS:

• like a packet from a different connection (but on the same ports!)

This could be the NAT’d VM IP. I ran wireshark on the Default Hyper-V Switch adapter.

Ran the curl command, instant.

@Sebastian-Roth I pm’d you a pcap

Ran these tests on my hyper-v and xcp vms:

1. In the FOG debug console (Both Hyper-V and XCP showed this result)

wget --no-check-certificate https://fogserverip/fog/service/ipxe/bzImage
wget: not an http or ftp url: https://fogserverip/fog/service/ipxe/bzImage

2. kernel bzImage took about 3-4 seconds on hyper-v, 10 seconds on xcp, then returned with

bzImage...ok

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.

@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.

@Sebastian-Roth I tried intel.efi, still slow.

Booting from snponly.efi doesn’t recognize the network adapter. I tried using Intel and ParaVirt in VirtualBox.

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.

@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?

@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]

@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 chain

wget 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.

@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.

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 - 96ms

We do in fact scan all traffic, but I noticed that the delay is only during ipxe ops.

I’ll run wireshark next.

@Sebastian-Roth That was my next guess but wanted to confirm that it wasn’t normal. Thanks!

@Sebastian-Roth Update: Yes the bzImage and init.xz also take longer to load now. Assuming because they are served via HTTP?

@Sebastian-Roth Once I start the PXE boot process, the boot kernel loads quick over TFTP, then the next part that loads boot.php takes longer. After I hit ESC to load the authentication screen, I enter my creds, then the next part where it loads the boot.php twice, then bg.png. After I get to the actual FOG ipxe menu, then load a custom ipxe entry such as WinPE, anything that loads via HTTP has a delay before starting the download. For my example of WinPE, the BCD, boot.sdi, bootmgr.efi, then finally the wim file which downloads normally, but there is a delay now before the download actually starts.

Does this make sense? My description of the issue I mean.

Running v1.5.9.231. I had to enable HTTPS since we use LDAP to authenticate when logging into FOG via web UI and the ipxe menu. Since then, anything pulled from either HTTP/HTTPS takes significantly more time to load. TFTP transfers are still fast and unaffected. The only transfers from HTTP that seem to be fine are those final WIM downloads (from the ipxe menu), but the files before that all take about 5 seconds to start fetching. It seems more like a delay than actual transfer speed.

Is this normal behavior for HTTPS?

@george1421 I tried entering a hostname after the prefix was appended, for example I entered “TestVM” thinking the full registered hostname would be “NCIT-TestVM”, but the device was registered as “TestVM”.

If I leave the hostname field blank during full reg, where it shows that the prefix is appended and the host name is autopopped, the MAC address becomes the registered hostname. Please note the “t Specified” hostname comes from the firmware of my Virtualbox VM.