My IPsec-protected Computer Cannot Get an IP Address from DHCP

Article
07/02/2012

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

When you implement a server isolation or domain isolation solution on your network, the computers in the domain receive connection security rules that block unsolicited inbound network traffic that is not IPsec-protected. DHCP network traffic is typically not IPsec-protected, but because a DHCP exchange is initiated by the client computer, replies from the DHCP server are typically permitted because they are responses to client requests.

However, in some environments where the DHCP infrastructure is not fully RFC compliant, the DHCP servers and relay agents reply to the client-initiated broadcast packet with a unicast response. Because the incoming unicast packet from DCHP does not match the broadcast packet that was sent, the packet is viewed by the firewall as unsolicited, and is dropped. For this reason, DHCP network traffic is typically exempted from IPsec authentication requirements.

Note

This problem affects only computers that are running Windows Vista or Windows Server 2008.
By default, computers that are running Windows 7 or Windows Server 2008 R2 help to simplify connection security and firewall rule configuration by exempting DHCPv4 and DHCPv6 traffic from IPsec authentication requirements. The DHCP client service on these versions of Windows comes with rules that exempt the DHCPv4 and DHCPv6 packet from authentication during communication with a DHCP server. The DHCP client service automatically enables these exemption rules as needed, and then removes the exemptions when the DHCP exchange is complete. This setting can be configured by using the netsh advfirewall set global ipsec defaultexemptions command. For more information, see the article DHCP Broadcast flag handling in Windows 7 (https://go.microsoft.com/fwlink/?linkid=143684) on the Microsoft Windows DHCP Team Blog.

In addition to client computers in an environment with non-RFC-compliant DHCP servers, this symptom can also occur on computers that have the following registry key value set to 0.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\{GUID}\DhcpConnForceBroadCastFlag

IPsec Exemption for DHCPv4

To resolve this problem for computers that are running earlier versions of Windows and using IPv4-based DHCP, create a connection security rule that exempts this “unsolicited” inbound DHCPv4 traffic from any authentication requirements. The rule must have the following characteristics:

Parameter	Value
Rule type	Custom
Endpoint 1	Any
Endpoint 2	Any
Authentication requirements	Do not authenticate
Protocol	UDP (17)
Endpoint 1 port	68
Enpoint 2 port	67

To create this connection security rule by using the Netsh command-line tool, use commands similar to the following at an administrator command prompt:

netsh

netsh>advfirewall

netsh advfirewall>set store gpo = <domain>\<gponame>

In the previous command, <domain> and <gponame> represent the actual domain name and name of the Group Policy object (GPO) you want to modify.

netsh advfirewall>consec add rule name=”DHCPv4 Exemption” endpoint1=any endpoint2=any port1=68 port2=67 protocol=UDP action=noauthentication

Deploy this rule to all of the members of your server or domain isolation groups.

IPsec Exemption for DHCPv6

To resolve this problem for computers that are running earlier versions of Windows and using IPv6-based DHCP, create a connection security rule that exempts this “unsolicited” inbound DHCPv6 traffic from any authentication requirements. The rule must have the following characteristics:

Parameter	Value
Rule type	Custom
Endpoint 1	Any
Endpoint 2	Any
Authentication requirements	Do not authenticate
Protocol	UDP (17)
Endpoint 1 port	546
Enpoint 2 port	547