@Sebastian-Roth, yes I change my server. I installed in another distro (Fedora 30) and set IP 172.24.3.71, because I’m tired to deal with Ubuntu is FOG Enemy.

As a workaround, we’re doing deploy in these Appliances by Schedule Deploy Tasks, as it bypass the authentication screen. But i would be interesting if we could do deploys without this need.

@JGeear check at Fog Settings (index.php?node=about&sub=settings) if the password is stored here is the same you can access ftp server:

I think this is an issue envolving this kind of nic hardware (Intel I226-V). I opened an issue (18125) where I have some appliances for pfsense, they have got four NICs with this kind of hardware, and we are not getting successfull to deploy an image because it’s not processing authentication, even typíng correct user and password.

@Tom-Elliott @Tom-Elliott it’s not authentication issue. We don’t have problem when deploying images to other hosts, like PCs and minipcs with just one NiC. But over these Appliances with 4 Nics we got stuck in the authenticon screen even putting correct username and password. Look, we are trying to disable 3 nics in Bios but we can’t . We excluded them to Boot Order and left just the first, but even so, the error persists.1000110829.jpg - I found the issue 16746 about this problem, but it’s happening to us!

@pcnr I noticed this issue so many years a go. It may be issues refering undionly.kpxe file. You can find some solutions from this forum about this. In my case I did following:

• Make a backup of /tftpboot/undionly.kpxe to undionly.kxpe.bak;
• Copied /tftpboot/undionly.kkpxe to undionly.kpxe.

So at next time, this stuck problem was solved.

I’m trying to deploy an image to a PFsense Appliance (APPLIANCE FIREWALL 4 LAN I226-V PROC J6412 8GB DDR4 E 256 SSD NVME HDMI/DP) and I cannot authenticate. PXE could get IP by DHCP in each of 4 NICs present in the appliance (obviously I plug network cable in just one of them), but after the actions menu and before images menu, when FOG asks for autentication, we fill auth fields but nothing happens, and FOG cannot overcome the screen I attached here below.

Any ideas?

Let me give a feedback to this issue, as I faced it recently. In my case, the culprit was faulting parameters in Microsoft DHCP.

It was faulting “MSFT Quarantine” User Class and PXE Vendor Class is not properly configured (It was typed “PXEclient:Arch:00007” instead of “PXEClient:Arch:00007”).

After doing this corrections, PXE got successfully redirected Boot instructions to FOG Server.

@george1421 I make another test with another client 172.24.12.65 running on same subnet to 172.24.12.35 - talking to the same server and got successfull - 12.65 - 3.70.pcap

@george1421 No, 172.24.5.180 is not the FOG Server, it’s 172.24.3.70… I don’t even know where PXE come with this idea…

@george1421 Look at this pcap file about the other FOG server (172.24.3.71) - It’s working. That’s a 1.5.9 FOG running in Fedora 32 - I think it’s a client issue, because another client could caugth naturally PXE TFTP… I will exam differences between the two clients.