pfSense & Windows Deployment Services

  • Hello!

    I have a Win2016 Standard Server, which is host a Hyper-V host with the latest pfSense (2.4.4-RELEASE-p3 (amd64)) firewall.

    My network shown below:

    The Hyper-V hosted firewall has 2 NICs:


    They are exclusively bound to pfSense VM.

    NIC3 is bound to Windows Server 2016. It reach the LAN and Internet via this NIC.

    On the network, only the pfSense serving as a DHCP and DNS server.
    The SWITCH1 is a unmanaged NetGear 8 port switch, the SWITCH2 is a HP ProCurve 24 port switch, but everything is disabled on it. The ACCESS POINT is a Ruckus Zoneflex 7372 and everything diabled on it, except the authentication of the wireless clients. I'm not using any VLAN settings.

    The DHCP serving on a LAN, form to
    Only three device have static lease, the Windows Server is the, my Workstation is the and my HP Printer is the

    I want to use the Windows Deployment Services on my server, but if I set the firewall to enable network booting in the DHCP settings, strange things happened.

    What i've try:

    In the Additional BOOTP/DHCP settings I set two DHCP option:
    Option 66 - IP address or host -
    Option 67 - text - boot\x86\

    Trying to boot from the network on a VMware virtual machine on my workstation.

    First try:
    FreeBSD 11 64-bit-2019-06-23-15-38-17.png

    Second try:
    FreeBSD 11 64-bit-2019-06-23-15-40-53.png.

    After the second try I always get the PXE-E52 error until I turn off and on the VM and clear the DHCP lease.

    Could you any advice for me to work the WDS server on my network?
    With these settings it was worked for me with my old (and now dead) Mikrotik router, so I can't figured out, why not working with pfSense.

    Thank You so much for your effort to solve my problem!

  • Why are you making it so complex? Focus on the problem
    A pfsense serving as a dhcp server and windows server as a bootp host
    Nothing between client and bootp server (one can suppose)
    Since it says tftp open timeout
    one needs to put ip and A. try to ping the tftphost
    B. Try to figure out why windows server timeouts on tftp

    As for second try one needs to investigate why it did get an ip on the first try and not the second.
    I would suggest wireshark.

  • @netblues

    That was not complicated with Mikrotik. I created the appropriate DHCP options (66 for WDS server IP and 67 for the boot file name) and it works.

    I checked first the WDS logs, where I find this:

    [WDSServer/WDSTFTP] TFTPConstruct[ERROR]: Code=4(0x4), Desc=Access violation.
    [WDSServer/WDSTFTP] TFTPParse[Request]: OpCode=1, File=boot†, Mode=1, BlkSize=1456, WinSize=1, Timeout=2, TSize=0, MsftWindow=0

    As i see, few backslash in the path is missing.

    With these pfSense DHCP settings:


  • I don't see anything complicated anyway.
    A typo can creep anywhere.
    As for mikrotik, it is a powerfull solution, however it is much more based on command line. Not bad, just different.

  • Now I chek the rfc2132, and I found an interesting thing on option 67.

    I change the pfSense Additional BOOTP/DHCP settings to Option 67 is set to string with value 62:6f:6f:74:5c:78:38:36:5c:77:64:73:6e:62:70:2e:63:6f:6d. (This is the boot\x86\ in hexadecimal format.)

    Now, on the WIN2016 the filename seems to be correct in the WDS logs.

    [WDSServer/WDSTFTP] TFTPConstruct[OACK]: BlkSize=1456 (1456), WinSize=1, Timeout=2, TSize=30832, MsftWindow=0
    [WDSServer/WDSTFTP] TFTPParse[Request]: OpCode=1, File=boot\x86\, Mode=1, BlkSize=1456, WinSize=1, Timeout=2, TSize=0, MsftWindow=0

    But, unfortunately, the PXE TFTP client is quit with timeout.

  • So, this is a windows server to pxe boot client, on the same broadcast domain. No traffic even touches pf.
    What do the logs on winserver say?
    Does the request for tftp download ever arrive?
    Is the pxe client assigned a valid ip (always? )?
    Is there any packet loss?
    And on the weird side, try substituting \ with / You never now, but its a nix thing anyways.

  • @netblues



    If You have time, you can check the logs 😄

    As I see, the connection is created, the client ask the correct file from the WDS Server, but the Client can't accept the file and running until timeout occured.

  • @tlecso Yep, the pcap shows the client sending acks for the file and then it requests it again.
    Any chance the file is corrupt ?

  • @netblues

    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?

  • @bmeeks

    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.

  • @bmeeks

    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
    An error occurred while trying to create the directory for the architecture.

    Error Information: 0x3

    Event Xml:
    <Event xmlns="">
    <Provider Name="BINLSVC" />
    <EventID Qualifiers="49413">1284</EventID>
    <TimeCreated SystemTime="2019-06-24T12:51:52.559069300Z" />
    <Security />

    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.

Log in to reply