DHCP options and PXE boot

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

DHCP options and PXE boot

L2 Linker

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

40 REPLIES 40

L6 Presenter

Get the PCAP from the Palo or client side (if possible) to see what palo is delivering in DHCPOFFER

L4 Transporter

Hi Tlea

 

I have identical situation like You

 

My config looks like:

2017-06-12_153715.png

 

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

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:

 

DHCP Palo.GIF

 

 

 

 

 

L4 Transporter

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

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

Hi Slawek, the change to boot\x86\wdsnbp.com did not help. Here's the output from the client

 

TFTP open timeout.jpg

 

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

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

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

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:

 

df.PNG

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

First, make sure that you allow the appropriate applications between the client/server zones!

Will do that. Thanks.

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

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?

  • 31811 Views
  • 40 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!