The Name Resolution Policy Table (NRPT) in Windows provides policy-based name resolution request routing for DNS queries. DirectAccess uses the NRPT to ensure that only requests for resources in the internal namespace, as defined by the DirectAccess administrator, are sent over the DirectAccess connection. DNS queries for all other namespaces are sent to the DNS servers defined on the client’s network interface.
Note: This behavior changes when force tunneling is enabled. In this case, all DNS queries are sent over the DirectAccess connection with the exception of the NLS and the DirectAccess server’s public hostname(s). If force tunneling is enabled, the configuration guidance described below is not required.
Split DNS
NRPT configuration is straightforward when the internal and external namespaces are unique. However, when split DNS is used, meaning when the internal and external namespaces are the same, DirectAccess configuration is more challenging. Typically, there may be many resources that should not go over the DirectAccess connection, such as public-facing web servers, email and unified communications servers, federation servers, etc. Without additional configuration, requests for all of these services would go over the DirectAccess connection. That may or may not be desirable, depending on the requirements of the implementation.
DirectAccess Server
One crucial public resource is the DirectAccess server itself. When using split DNS, the DirectAccess implementation’s public hostname will, by default, be included in the internal namespace. In this scenario, the DirectAccess client will fail to establish a connection to the DirectAccess server.
Troubleshooting
When troubleshooting failed connectivity, the output of ipconfig will show the IP-HTTPS tunnel interface media state as “Media disconnected”.
The output of Get-NetIPHttpsState will also return an error code 0x2AF9 with an interface status “Failed to connect to the IPHTTPS server; waiting to reconnect”.
To further troubleshoot this issue, examine the output of Get-NetIPHttpsConfiguration. Test name resolution of the FQDN listed in the ServerURL field. If the issue is related to NRPT configuration, the client will fail to resolve this name to an IP address. Testing from a non-DirectAccess client should resolve correctly, however.
NRPT Configuration
If split DNS is employed, it is necessary to include the DirectAccess server’s public hostname in the NRPT as an exemption. This will cause the DNS query for the public hostname to use public DNS servers, allowing the DirectAccess client to establish a connection successfully.
To resolve this issue, open the Remote Access Management console on the DirectAccess server, highlight DirectAccess and VPN under Configuration, and then click Edit on Step 3. Select DNS, and then double-click on an empty row in the table.
Enter the public hostname for the DirectAccess deployment in the DNS suffix field (the public hostname can be found by clicking Edit on Step 2). Do NOT specify a DNS server. Click Apply, click Next twice, and then click Finish.
Note: For multisite deployments, be sure to include the public hostname for each entry point in the enterprise. Also, if multisite is configured to use GSLB, include the GSLB hostname as well.
PowerShell
Alternatively, you can run the following PowerShell commands to automatically configure the NRPT for split DNS. For multisite deployments, be sure to run these commands on at least one DirectAccess server in each site.
$hostname = Get-RemoteAccess | Select-Object -ExpandProperty ConnectToAddress
Add-DAClientDnsConfiguration -DnsSuffix $hostname -PassThru
If multisite is configured to use GSLB, run the following PowerShell commands on one DirectAccess server in the enterprise.
$gslbfqdn = Get-DAMultiSite | Select-Object -ExpandProperty GslbFqdn
Add-DAClientDnsConfiguration -DnsSuffix $gslbfqdn -PassThru
Additional Information
Troubleshooting DirectAccess IP-HTTPS Error 0x2af9
DirectAccess DNS Not Working Properly
DirectAccess DNS Records Explained
Troubleshooting Name Resolution Issue on DirectAccess Clients
Omar Abu Hazeem
/ March 17, 2018Hi,
My external and internal domain is the same, I include the domain in the NRPT , plus i excluded the NLS and DA records, all seems to be good , except it is not connected, I used the DA troubleshooting client, but i’m stuck on
[18/03/2018 5:24:30 AM]: In worker thread, going to start the tests.
[18/03/2018 5:24:30 AM]: Running Network Interfaces tests.
[18/03/2018 5:24:30 AM]: Wi-Fi (Intel(R) Dual Band Wireless-AC 7260): fe80::90fe:e0e7:1cff:c812%8;: 192.168.43.219/255.255.255.0;
[18/03/2018 5:24:30 AM]: Default gateway found for Wi-Fi.
[18/03/2018 5:24:30 AM]: iphttpsinterface (iphttpsinterface): fde1:6abd:2ce7:1000:6812:3293:1756:a84d;: fde1:6abd:2ce7:1000:590b:1f2d:99b7:7ef4;: fe80::6812:3293:1756:a84d%9;
[18/03/2018 5:24:30 AM]: No default gateway found for iphttpsinterface.
[18/03/2018 5:24:30 AM]: Wi-Fi has configured the default gateway 192.168.43.1.
[18/03/2018 5:24:30 AM]: Default gateway 192.168.43.1 for Wi-Fi replies on ICMP Echo requests, RTT is 1 msec.
[18/03/2018 5:24:30 AM]: Received a response from the public DNS server (8.8.8.8), RTT is 639 msec.
[18/03/2018 5:24:30 AM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[18/03/2018 5:24:30 AM]: Running Inside/Outside location tests.
[18/03/2018 5:24:30 AM]: NLS is https://nls.domain.local:62000/insideoutside.
[18/03/2018 5:24:30 AM]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
[18/03/2018 5:24:30 AM]: NRPT contains 3 rules.
[18/03/2018 5:24:30 AM]: Found (unique) DNS server: fde1:6abd:2ce7:3333::1
[18/03/2018 5:24:30 AM]: Send an ICMP message to check if the server is reachable.
[18/03/2018 5:24:31 AM]: DNS server fde1:6abd:2ce7:3333::1 is online, RTT is 887 msec.
[18/03/2018 5:24:31 AM]: Running IP connectivity tests.
[18/03/2018 5:24:31 AM]: The 6to4 interface service state is default.
[18/03/2018 5:24:31 AM]: Teredo inferface status is offline.
[18/03/2018 5:24:31 AM]: The configured DirectAccess Teredo server is win1710.ipv6.microsoft.com..
[18/03/2018 5:24:31 AM]: The IPHTTPS interface is operational.
[18/03/2018 5:24:31 AM]: The IPHTTPS interface status is IPHTTPS interface active.
[18/03/2018 5:24:31 AM]: IPHTTPS is used as IPv6 transition technology.
[18/03/2018 5:24:31 AM]: The configured IPHTTPS URL is https://DA.domain.local:443.
[18/03/2018 5:24:31 AM]: IPHTTPS has a single site configuration.
[18/03/2018 5:24:31 AM]: IPHTTPS URL endpoint is: https://DA.domain.local:443.
[18/03/2018 5:24:32 AM]: Successfully connected to endpoint https://DA.domain.local:443.
[18/03/2018 5:24:43 AM]: No response received from domain.local.
[18/03/2018 5:24:43 AM]: Running Windows Firewall tests.
[18/03/2018 5:24:43 AM]: The current profile of the Windows Firewall is Public.
[18/03/2018 5:24:43 AM]: The Windows Firewall is enabled in the current profile Public.
[18/03/2018 5:24:43 AM]: The outbound Windows Firewall rule Core Networking – Teredo (UDP-Out) is enabled.
[18/03/2018 5:24:43 AM]: The outbound Windows Firewall rule Core Networking – IPHTTPS (TCP-Out) is enabled.
[18/03/2018 5:24:43 AM]: Running certificate tests.
[18/03/2018 5:24:43 AM]: Found 1 machine certificates on this client computer.
[18/03/2018 5:24:43 AM]: Checking certificate CN=ITT-OABH-L.domain.local with the serial number [170000003261D0ED2FA43967D3000000000032].
[18/03/2018 5:24:43 AM]: The certificate [170000003261D0ED2FA43967D3000000000032] contains the EKU Client Authentication.
[18/03/2018 5:24:43 AM]: The trust chain for the certificate [170000003261D0ED2FA43967D3000000000032] was sucessfully verified.
[18/03/2018 5:24:43 AM]: Running IPsec infrastructure tunnel tests.
[18/03/2018 5:24:43 AM]: Failed to connect to domain sysvol share \\domain.local\sysvol\domain.local\Policies.
[18/03/2018 5:24:43 AM]: Running IPsec intranet tunnel tests.
[18/03/2018 5:24:43 AM]: Successfully reached fde1:6abd:2ce7:1000::1, RTT is 86 msec.
[18/03/2018 5:24:43 AM]: Successfully reached fde1:6abd:2ce7:1000::2, RTT is 83 msec.
[18/03/2018 5:24:43 AM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.domain.local.
[18/03/2018 5:24:43 AM]: Running selected post-checks script.
[18/03/2018 5:24:43 AM]: No post-checks script specified or the file does not exist.
[18/03/2018 5:24:43 AM]: Finished running post-checks script.
[18/03/2018 5:24:43 AM]: Finished running all tests.
It seems that The problem lays in the DNS , please i can’t resolve and i have tried everything and possible solutions , Please any Ideas.
Regards
Richard M. Hicks
/ March 21, 2018It would appear that your client was able to establish a transition tunnel as both tunnel endpoint IPv6 addresses respond to ICMP. If you can’t access internal resources, have a look at the client and see if there are any IPsec security associations established. If not, ensure the Windows firewall is on (on the server and client!) and if that doesn’t fix your problem, you’ll have to investigate why the client isn’t authenticating correctly. Hope that helps!
Bhupesh
/ February 13, 2019Hi Richard,
This is a great article, I have an excel add-in (vendor provided) that makes a look up to an internal routed server, however the connection by this method is failing. The NRPT looks good and all connectivity test suggest no issues. Assuming the add-in is acting like the NSlookup and failing to resolve the DNS query internally, how one go about getting the Add-in (or even NSlookup) to read the NRPT?
Richard M. Hicks
/ February 13, 2019If your tool is using something like nslookup it will never work. Nslookup bypasses the NRPT completely because it is designed to test the DNS server’s response, not how the client would resolve the name. That is by design, of course. The only way to fix this would be to change the code of the add-in to use the Windows standard name resolution API, which would work with the NRPT.
Jon Scriven
/ March 23, 2020I am having a problem where I have deleted some NRPT entries by leaving them blank as above. They are showing as Empty in DirectAccess (DNS servers) within DirectAccess Client but when I check on my client, they are populated with the IPV6 address for the DA server and GPRESULT says that it has got this from Local Group Policy. If I use gpedit.msc on the client, there is nothing showing in local group policy for NRPT so I am very confused. Same behaviour is on multiple clients. Is there a different way to force a NULL entry instead of leaving it blank?
Richard M. Hicks
/ March 23, 2020That’s quite unusual. I would have to assume that somehow the client isn’t fully applying the GPOs? I’d suggest removing the client from DirectAccess completely and re-adding it just to see what happens.
Adam
/ July 8, 2020I have an environment where the internal Domain name is a .local (non routable) domain which is fine, however there are resources on a .com domain that I would like to be available over DA. DNS requests to the .com domain seem to be ignoring the internal DNS zone for the .com domain and being forwarded to the locally configured DNS servers on the DA client. Is there any way I can tell DA to send DNS requests for this specific domain to our internal DNS servers?
Richard M. Hicks
/ July 10, 2020Yes, you can do this. Details here: https://directaccess.richardhicks.com/2018/05/14/directaccess-selective-tunneling/.
Rajan
/ November 15, 2021Is there any Powershell script to add bulk NRPT rules to the table in DA.
Richard M. Hicks
/ November 16, 2021I don’t have anything published at the moment, but I’m happy to provide some sample code if you like. Reach out to me directly and I’ll send you something.
Ant
/ February 25, 2022Hi Richard – appreciate everything you do on this website!
Just a quick question, if you’ve got time.
I’ve got a few apps hosted on prem which are externally facing and thus have public DNS records.
Basically, these apps are using app.domain.com. My internal domain is domain.local.
At the moment, clients using DA are resolving using the public/external IP and DNS server. This creates extra overhead, as DA clients should be treated as ‘internal’ and thus use internal DNS servers when using corporate resources.
My question is thus: how do I make it so the DA client, once connected, will resolve ‘app.domain.com’ using our internal DNS, rather than public DNS?
From the reading I’ve done here, it seems like I should add:
domain.com as a name suffix with the associated local DNS server address (i.e. the directaccess server)
direct.domain.com (our Remote Access Server url) as an exemption
Should this do the trick?
Cheers.
Richard M. Hicks
/ March 1, 2022Yes. Add the public namespace to your NRPT and define your internal DNS servers (DNS64 server). The DirectAccess client will then resolve that namespace over the data tunnel.
Rudresh
/ July 21, 2023hello Richard, similar issue we are facing, corporate DA client still getting resolved to external DNS looks like, it is connecting from or through direct access server, rather than looking internal network, looking for your suggestion
Richard M. Hicks
/ July 26, 2023If you are trying to resolve internal hostnames over the DirectAccess tunnel, those hostnames or namespaces would need to be included in the NRPT. If you want an external site to be routed over the DirectAccess tunnel, you will include the external hostname in the NRPT as well.
Rudresh
/ July 21, 2023MY corporate DA client unable to locate local network, network location server shows certificate error
Richard M. Hicks
/ July 26, 2023Sounds like an expired NLS certificate. Is your NLS server on a separate server? Or is it installed on the DirectAccess server itself?