DirectAccess NRPT Configuration with Split DNS

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.

6 Comments

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

It 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

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?

If 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

I 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?

That’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.