PXE Boot setup on Palo Alto PA-3020
03/24/2017 3939 views
Non-network IT type here trying to figure out how to configure our Palo Alto PA-3020 (which we use for DHCP services) to allow PXE boot from our K2000 to image new Windows laptops.
Booting from the USB stick has always worked. Now with the new release of the K2000 (v7) we're looking to move beyond the USB stick to direct network boot from the K2000.
I have looked at multiple documentation (from KACE, Quest, and general internet googling) that talks about using DHCP Options 66 and 67 (perhaps 43 for the vendor ID or even 244 if the others don't work). However the instructions to create these entries are generally written for an MS DHCP server and no other brands. While I understand KACE can't provide info for each type of server out there, I have been unable to find anything that even remotely comes close to how this Palo Alto looks and works.
From a standalone PC, I do not see anything on boot-up (F12) that relates to our network or the K2000. It's always Windows Boot Manager and the UEFI internal drive. UEFI is on; Secure boot if off. When I've tried F12 on a blank VM (Virtual Box) I can obtain a DHCP IP address from the network, but the process always times out on TFTP Server not found -- timeout after three attempts. Using other VM products (VMware Fusion, Parallels) did not get that far into the process (though, that could be my configuration of each).
I have attached several screen shots of the Palo Alto interface and the option changes we've done. I'm hoping there's someone else out there using a K2000 with a Palo Alto PA-3020 that might have some insight as to what might be going on (or going wrong!).
Appreciation in advance!
(sorry for the sideways pictures; must be this portal)
Community Chosen Answer
Please log in to answer
PANOS does not currently support the ability to set the next-server (siaddr) field within the DHCP server. The PXE clients are looking for the next-server field and not option 66 (TFTP server name). As a result the PXE clients end up sending their TFTP request to the IP address of the DHCP server which in this case is the Palo Alto Firewall.
As a workaround for this I created a NAT rule to translate incoming TFTP connections sent to the firewall IP to the IP address of the actual TFTP server. It doesn't fix the root problem but it does solve the issue.
Here is what my NAT rule looks like:
Answered 10/15/2018 by: bitanalyst