pfSense & Windows Deployment Services
-
@tlecso Yep, the pcap shows the client sending acks for the file and then it requests it again.
Any chance the file is corrupt ? -
I download from the MSDN a untouched Win 8.1 Pro image. CRC check is ok. Symptoms is the same, I got PXE-E32: TFTP open timeout error always
I check with normal slash in the path too. Without success.
I reinstall the Deployment Services on the server. Without success.
What can I do to make it work?
-
Pretty much every Windows installation these days comes with an enabled firewall on the WIndows box itself. Have you checked to be sure that the WIndows firewall is allowing the TFTP traffic?
-
Yes, it is turned off on my workstation, while testing.
-
And finally, after a long night... it works! Sometimes.
I'm sure, the problem is in the WDS Server itself. More investigation needed.
But the pfSense DHCP is not gave IP address to the Client PC, when i restart the Client. First time is OK, but after restart the PXE got only DHCPproxy offer from the WIN2016, but IP address not given by the DHCP Server on the pfSense. If I clear the lease manually, it works again, until the next try.
-
You didn't specify in your post, but if this is part of an Active Directory configuration you would probably be better off to let Windows AD do everything -- DHCP and DNS (along with the TFTP from the WDS server). Even if not an AD setup, you still might be better off to just install the Windows DHCP and DNS services on the WDS box and then either let that DNS resolve from directly the root servers or else point it to the pfSense box and let Unbound on pfSense resolve for you.
-
Yes, I didn't specify. There is no AD.
But only one time, it worked... :D
As I wrote, I'm pretty sure, the problem is not with the firewall settings now, but also i have problem with the WDS Service. I found few error in the logs, but the solution is'nt worked for me.
For example:
Log Name: Application
Source: BINLSVC
Date: 6/24/2019 2:51:52 PM
Event ID: 1284
Task Category: BINLSVC
Level: Error
Keywords: Classic
User: N/A
Computer: LECSOSRV2016
Description:
An error occurred while trying to create the directory for the architecture.Error Information: 0x3
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="BINLSVC" />
<EventID Qualifiers="49413">1284</EventID>
<Level>2</Level>
<Task>5</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2019-06-24T12:51:52.559069300Z" />
<EventRecordID>2545</EventRecordID>
<Channel>Application</Channel>
<Computer>LECSOSRV2016</Computer>
<Security />
</System>
<EventData>
<Data>
</Data>
<Data>0x3</Data>
</EventData>
</Event>Maybe this is the reason why the PXE client not reach the requested image. But i'm not really sure. With the Windows Updates, the MS is make a real challenge to operate a WDS server.
I've tried many things, checking/changing access rules to the appropriate folders and registry branches. Remove/Add the WDS role. Disabling the Variable Variable Window Extension, etc, etc.
Without success. As I wrote, only one time worked for me. -
I have no experience with Windows Deployment Services, so I can't really offer any advice on that area other than to say that, generally speaking, in the Windows Server world it is usually better to let the Windows services do all the basic network plumbing stuff such as DHCP and DNS. When you try to split the duties with say DHCP or DNS or both split off on a non-Windows host, there can be issues. Not saying that is the cause of your specific issue now, but letting Windows do it all at least for testing would take one variable (pfSense) out of the equation.
-
It is worked perfectly for me a few weeks ago. When My old Mikrotik router died, then i bought the HP switch and the Ruckus AP. I reinstall the WIN2016 to create a network from scratch, and my nightmare started from this point. I believe, the pfSense is work correctly, but my WIN2016 is buggy.
-
The first ting I do when troubleshooting PXE is removing option 66 and 67 from DHCP. They are not needed as long as your clients and WDS server is on the same subnet.
WDS uses Proxy DHCP aka the WDS server will provide the server and boot file name over DHCP while leaving the IP adress part to the "real" DHCP server. In this case the client saw the offer from the WDS server (Proxy DHCP offers were received)The only time this wont work is when the server and clients are on different subnets and in that case IPhelpers/DHCP forwarders works better (at least for me)
-
I reinstall the Server today. The BINLSVC 1284 error is still here. I was'nt install any update. I download the ISO from the MS Evaluate site to create the installation media. I check the permissions on the RemoteInstall folder and on the WDSSERVER registry branch. Thats ok. The I'm totally confused what's wrong here.
-
Just a little info.
MS screw up something in the Server 2016 WDS service... I move to Server 2019 an everything works like a charm
