Win 7 - DHCP/Netlogon/Firewall - Microsoft Confirm a Bug
To stop anyone else having the same 'fun' as me, I thought I would share my Windows 7 problem that has resulted in many hours spent testing different DHCP servers, routers, NICS and reviewing packet logs!
This problem seems to occur if you have all of the following:
- Using a DHCP reply to forward DHCP requests (e.g. using VLANs and an IP helper on the router to forward DHCP requests)
- Windows 7 clients
- Windows Firewall Public Profile turned on (default configuration - all profiles)
- DhcpConnForceBroadcastFlag = 0 (Default for Windows 7)
- NETLOGON event ID 5719 in system event log
This computer was not able to set up a secure session with a domain controller in domain <DOMAIN NAME> due to the following: There are currently no logon servers available to service the logon request.
- Group policies inconsistently applying on start-up
- Event ID 50024 logged in the Microsoft-Windows-DHCP Client Events/Operational event log (you need to enable this event log as its disabled by default)
Ack Receive Timeout has happened in the Interface Id xx
By default Windows 7 request for its DHCP reply's to be a uncast responses.
If you are using a Windows DHCP server and your client is on the same broadcast domain (not accessing the DHCP server via a DHCP reply) the DHCP server receives the request but ignores the clients request for a uncast response, and reply's in a broadcast. In this situation everything works.
The problem occurs when your client has to access the DHCP server via a DHCP relay, such as a router or switch and the DhcpConnForceBroadcastFlag registry key is still set to the default(0). In this situation, the client sends out a broadcasts requesting an IP address, the DHCP relay forwards the request to the DHCP server, the DHCP server sends the reply(ACK reply) to the relay and the DHCP relay sends a uncast reply to the client. If the Public profile is turned on in the Windows Firewall (on by default) then the ACK reply is dropped by the firewall and is never passed to the DHCPclient.dll
I passed my findings and research to Microsoft support and after more packet logs and deep Microsoft DHCP\Firewall traces, they have concluded it's a bug! they have now created an internal KB for this problem. This has now been passed to the developers and I am awaiting an acceptable workaround and Microsoft to release a patch.
I will post the workaround and a link to the patch when I get more information from Microsoft.
Hope this helps,