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

The firewall showing a DHCP packet that should have not been there.

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.

A DHCP acknowledge packet that should not be there.

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.

A DHCP Request coming from a Linux Host

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

A DHCP Request coming from a Windows Host.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.