DirectAccess NRPT Configuration with Split DNS

DirectAccess NRPT Configuration with Split DNSThe 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”.

DirectAccess NRPT Configuration with Split DNS

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

DirectAccess NRPT Configuration with Split DNS

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.

DirectAccess NRPT Configuration with Split DNS

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.

DirectAccess NRPT Configuration with Split DNS

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.

DirectAccess NRPT Configuration with Split DNS

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

Leave a comment

2 Comments

  1. Hi,

    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

    Reply
    • 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!

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

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

%d bloggers like this: