Microsoft has issued KnowledgeBase article 2845152 to help administrators overcome a problem they might experience while using the Network Connectivity Assistant with a Windows Server 2012-based DirectAccess server and IPv4-only DNS Servers and Active Directory Domain Controllers. A hotfix is available for the DirectAccess Server.
In an environment with a Windows Server 2012-based DirectAccess server and IP version 4(IPv4)-only DNS servers and Active Directory Domain Controllers on the intranet, the DirectAccess server raises a false alarm that either the DNS Server or the Active Directory Domain Controller is not available, when you configure a DirectAccess client to ping the DNS server or an Active Directory Domain Controller for the Network Connectivity Assistant probe.
In this scenario, the DirectAccess server cannot ping the same DNS Server or Active Directory Domain at the same time that the DirectAccess client pings the DNS Server or the Active Directory Domain Controller.
Because the DNS server and the Active Directory Domain Controllers are IPv4-only resources, the DirectAccess server uses NAT64 and DNS64 for translation during the communication. When an ICMPv6 packet that must be converted to ICMPv4 arrives at NAT64, NAT64 allocates an ICMP ID to the packet.
This issue occurs because the ID that NAT64 uses for an ICMP packet and the ICMP ID that is generated from the local stack both start from 1. Therefore, NAT64 incorrectly forwards the ICMPv4 Echo Reply message back to the DirectAccess client, even if the message is for the DirectAccess server.
Because of this conflicting ID range, when the DirectAccess server also pings the same DNS Server or Active Directory Domain Controller, the response is sent back to the DirectAccess client.
A supported hotfix is available from Microsoft as part of KnowledgeBase article 2845152. The hotfix replaces winnat.sys.
Install this hotfix on the DirectAccess server to fix the problem that is described above on Windows Server 2012 Standard, Windows Server 2012 Datacenter, Windows Server 2012 Foundation and Windows Server 2012 Essentials.
In the past two weeks, no issues have been reported with this hotfix.
After installation, the DirectAccess server needs to be restarted, so plan to install the hotfix during a service window, or plan for a highly available DirectAccess infrastructure.
Related KnowledgeBase Articles
New features of DirectAccess in Windows Server 2012
Server Core Remote Access Services -DirectAccess and Routing
Implementing Windows Server 2012 DirectAccess behind Forefront TMG (Part 1)
What’s New in Windows Server 2012 Remote Access (Part 1)
What’s New in Windows Server 2012 Remote Access (Part 2)
Deploying DirectAccess in Windows Server 2012
Windows Server 2012 Direct Access – Part 1 What’s New