- Microsoft
Unsolicited DHCP ACK from Microsoft DHCP Server
A few days ago while reviewing my data center firewall rules I noticed that my DHCP Server was trying to make outbound connections to a subset of clients.

Upon further inspection I determined that it was sending a few packets of data only to Windows DHCP Clients, usually in the morning, presumably because the lease expired overnight and the client was powered on again the next morning.
Since a DHCP Server should not be sending out spontaneous ACK messages, I decided to enable a packet capture on the firewall and leave it running for a few days.

Here we have it: a DHCP Acknowledge message for which there was no request; moreover, we have an option (43: Vendor-Specific Information) that’s not supposed to be here.
The content of the option’s message is also interesting because it contains the string “NAP“: a functionality that was removed in Windows Server 2016. This DHCP Server, however, is running on Windows Server 2022 (for the time being).
Since the server is sending these unsolicited ACK only to Windows DHCP Clients, it must have a way to know that it is serving a Windows DHCP Client. So I reversed the capture.

Here we have a DHCP Request from a Linux DHCP Client; “nothing to see here”.

Here we have a DHCP Request from a Windows DHCP Client and we have something notable: an Option 60: Vendor class identifier with a value of “MSFT 5.0“.
There it is. The Microsoft DHCP Server knows it have a friend to talk to, which understands its bizarre way of ignoring standards that are followed by the rest of the world (as per section 1.3 of RFC 2131: https://www.rfc-editor.org/rfc/rfc2131#section-3.1).
The RFC also offers a nice view of every possible DHCP Client-Server interaction at section 4.4 (https://www.rfc-editor.org/rfc/rfc2131#section-4.4); I could not find any instance where a server should be sending a DHCP ACK message which was not previously solicited. Even if the client wants some more configuration data, it must send a DHCPINFORM message and, if that was the case, the connection would not have been denied by the firewall, because it would be part of an already established traffic flow.