- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
06-12-2017 03:37 AM
Hi,
we have just recently made a change in where we moved clients from one segment to a new one. We are using WDS for PXE boot and the WDS server (MDT 2013) is on a different segment than the clients. The Palo is our DHCP server for clients and we have defined some options in our DHCP scope (option 66 pointing to the WDS server and option 67 pointing to the bootfile).
This setup is not working, the PXE boot process stops telling me it cannot find the TFPT server (PXE-032). Any suggestions are much appreciated.
Regards,
Tony Lewis
06-12-2017 03:57 AM
Get the PCAP from the Palo or client side (if possible) to see what palo is delivering in DHCPOFFER
06-12-2017 06:45 AM
Hi Tlea
I have identical situation like You
My config looks like:
On "new one" segment DHCP server You have to set option 66 and 67 - both options must point to your WDS server
Where is Your DHCP on PA or Windows servers?
REgards
SLawek
06-12-2017 07:09 AM
The DHCP is handled on the Palo Alto. Both the 66 and 67 options are set and pointing to the WDS server. Here's my config:
06-12-2017 07:55 AM - edited 06-12-2017 07:57 AM
Hi
In my opinion something wrong is with your path \Boot\x64\wdsmgfw.efi
Maybe You can try with my path? - of course if Your WDS server have boot\x86\wdsnbp.com file - You can check it.
Are You sure that have sescurity policies thats allow traffic from 10.18.0.1/24 to 10.18.16.46?
Regards
Slawek
06-12-2017 10:25 AM
Hi Slawek and thanks for your response. I will change the boot file name to the one you are using. When it comes to security policies I'm not sure and will have to check this closer. I guess there will some policy in regards of TFTP needed?
I will check this first thing tomorrow morning.
Regards,
Tony
06-13-2017 12:05 AM
Hi Slawek, the change to boot\x86\wdsnbp.com did not help. Here's the output from the client
I'm guessing we have some problems with TFTP and I'm just thinking we might have to create a Policy-Based Forwarding rule for TFTP (port 69) between the client net and the server net? If you have any suggestions I'd be really happy!
Regards,
Tony
06-13-2017 12:45 AM - edited 06-13-2017 12:49 AM
Hi,
When your client receives a TFTP server information from the palo DHCP server, what can you see in the traffic logs on palo? Is your TFTP server in the same subnet as client or not (looks like it is not)? Are they in the same zone (same zone traffic is allowed by default).
06-13-2017 12:51 AM
Hi TranceforLife and thanks for your input. I cannot see any traffic using the monitor, and the TFTP server is in the server subnet, ie. not in the same subnet as the PXE client.
Regards,
Tony
06-13-2017 12:57 AM
Client subnet and the server subnet are they in the same zone? If yes can you please override default Intra-zone policy or make sure you have login enabled on your current policy so you can see client attempts:
06-13-2017 01:09 AM
They are in different zones. I will make sure to follow your prevoius suggestion and enable logging, I'll post the result asap.
Regards,
Tony
06-13-2017 01:11 AM
First, make sure that you allow the appropriate applications between the client/server zones!
06-13-2017 01:27 AM
Will do that. Thanks.
06-13-2017 02:19 AM
Hi, I've now checked the following;
We have a zone where the TFTP/WDS server is located (Frontend) and a zone where the PXE clients are located (Client). We have a security rule that permitts TFTP application (service > application default) between these zones. Could it be I'm not allowing the correct services, eventhough TFTP is permitted?
Regards,
Tony
06-13-2017 02:21 AM
Could be. Just for test permit any any limiting security policy just for your client source ip address. What can you see in the logs?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!