Troubleshooting Name Resolution Issues on DirectAccess Clients

When troubleshooting name resolution issues on a Windows client, NSlookup is an essential tool. However, it is important to understand that using NSlookup on a DirectAccess client might not always work as you expect. Although using NSlookup on a DirectAccess client will work normally when the client is on the corporate network, it will not provide the correct results to queries for internal hostnames when the DirectAccess client is outside of the corporate network without taking additional steps. This is because when a DirectAccess client is outside the corporate network, the Name Resolution Policy Table (NRPT) is enabled. The NRPT provides policy-based name resolution routing for DirectAccess clients, sending name resolution requests for certain namespaces to specific DNS servers. You can view the NRPT on a Windows 8.x DirectAccess client by issuing the following PowerShell command:


Troubleshooting Name Resolution Issues on DirectAccess Clients

You can view the NRPT on a Windows 7 DirectAccess client by issuing the following netsh command:

netsh namespace show policy

Troubleshooting Name Resolution Issues on DirectAccess Clients

Here you’ll notice that the namespace is configured to use the DNS64 service running on the DirectAccess server at 2002:62bd:d898:3333::1. Notice also that the host is not configured to use a DNS server. This effectively exempts this host from the NRPT, forcing name resolution requests for this Fully-Qualified Domain Name (FQDN) to be delivered to the DNS servers configured on the network adapter.

A Working Example

With the NRPT enabled, which occurs whenever the DirectAccess client is outside of the corporate network, a name resolution request for would be sent to the DNS64 service on the DirectAccess server. A name resolution request for would be sent to the DNS servers assigned to the network adapter because the NRPT contains no entry for this namespace. And even though the host is a part of the internal namespace, a name resolution request for this host would also be sent to the DNS servers assigned to the network adapter because it has been specifically exempted from the NRPT.


The NSlookup utility is unaware of the NRPT. Whenever you use NSlookup it will, by default, automatically send queries directly to the DNS servers configured on the network adapter, regardless of the NRPT. If you wish to use NSlookup to test name resolution for external hostnames, use it as you normally would. However, if you wish to use NSlookup to resolve internal hostnames over the DirectAccess connection, you will need to tell NSlookup to use the DNS64 service running on the DirectAccess server. You can do this by running NSlookup interactively and using the server command to point it to the IPv6 address of the DNS64 service, which you can find in the NRPT.

Troubleshooting Name Resolution Issues on DirectAccess Clients

This also applies to the PowerShell cmdlet Resolve-DNSname. Here you’ll use the -Server switch to specify the DNS64 server’s IPv6 address.

Resolve-DNSName –Server <DNS64_IPv6_Address>

Troubleshooting Name Resolution Issues on DirectAccess Clients

Leave a comment


  1. Hi guys let me know something when DA (EDGE server) is behind a firewall it will only use ipv4, right? so the NRPT table will still be used to resolve ipv6 names ? Regards,
    wn7client [FW] [FW] corpnet (AD , APP, IIS)

    • IPv6 is always used between the DirectAccess client and server, regardless of network configuration. What changes when DirectAccess is behind a NAT is the IPv6 transition protocol. For edge deployments, the client can choose between 6to4, Teredo, and IP-HTTPS. For NAT deployments, only IP-HTTPS is supported. The NRPT still functions the same way in either configuration.

      • Hi , we solve it disabling the the teredo, 6to4 interface in the external client, but in the lab we used ip-https passing through a router not a firewall to make it simple.

  2. Hi Richard talking about NRPT and we have a situation here where

    the internal FQDN:

    additional forward dns zone: (all the applications web, SharePoint, answers at (internaly)

    external FQDN DNS zone mycompany.commy

    all Windows 7 and 8 are working normally but when we try to resolve (published only internal it doesn’t work. How can I set it up at NRPT to solve it?

    our topology

  3. Ashish

     /  July 9, 2015

    Hello Richard,

    What happens if we have enabled force tunneling with NRTP exceptions? How ill the client try to access the site which are their in NRTP exceptions?

    • Force tunneling configures the NRTP to forward name resolution requests for ALL namespaces (not just the corporate namespace) to the DirectAccess DNS64 service. In this configuration there are no NRPT exemptions.

  4. DADemon

     /  September 11, 2015

    Richard, We recently implemented a production pilot of DA on Windows Server 2012 R2. We have a very large organization and are attempting to determine what may be causing all of our Window 7 client machines to be unable to resolve internet addresses when connected to DA. In the same environment, our Windows 8.1 and Windows 10 devices have no issues handling this. When I look at the local DNS resolver cache on the client after attempting to ping a random website (i.e. I see about 11 entries for IPv4 and IPv6 addresses for However the result returned to the command prompt is as follows: “Ping request could not find client Please check the name and try again.”

  5. matt

     /  January 13, 2016


    Thanks this has really cleared up a lot of questions on how DNS resolution is working with DirectAccess. However, I have followed your steps provided and when I try and run it against my DNS64 address I get the message:
    server 2002:6e6e:6e03:3333::1
    DNS request timed out.
    timeout was 2 seconds.
    Default Server: [2002:6e6e:6e03:3333::1]
    Address: 2002:6e6e:6e03:3333::1

    • Are you able to ping the DN64 address?

      • matt

         /  January 18, 2016

        Yes able to ping the dns64 address.

      • Do you have IPsec tunnels as well? Get-NetIpsecMainModeSA will tell you.

      • Adam

         /  February 9, 2016

        I have a similar problem; no DNS resolution. Can ping the DNS64 address but nslookup does not work. No IPsec tunnels showing after running Get-NetIpsecMainModeSA. Eternally grateful to anyone who can contribute to a resolution.

      • Drop me a note. I’ll see if I can shed some light on why things may not be working for you. 🙂

      • Hello Richard,

        I have the same problem like Adam. No DNS Resolution. No-IPsec tunnels. But i can ping and RDP the DNS64 adress. This is driving me crazy. Can you help me?


      • I can help, but I’ll need additional information. Send me an email and I’ll let you know what I need. 🙂

      • Ross

         /  May 25, 2016

        Hi Richard,
        Thanks for the excellent blog post. I’m in the same situation as these guys – ping DNS64 address but no name resolution. Name resolution works locally on the DA server. Single IP, NATed IP/HTTPS only set up.

      • If you can ping the DNS64 address and the DTEs, but can’t access internal resources, I would suspect that you also don’t have any IPsec tunnels either. If that’s the case, investigate why IPsec is failing (missing or incorrect certificates, computer account missing or disabled, etc.).

      • vaulti

         /  May 29, 2016

        Hi Ross,

        In my case it turned out that I had a trouble with my Firewall-GPO. Check if the Firewall is enabled and configured correctly on the Clients and Server


  6. ecartini

     /  March 31, 2016

    Hello All,

    One of the issues we are facing in our DA environment is the ability for our help desk technicians to use microsft SCCM to remote a machine that’s is corrected to DA. I have been doing all kinds of research and still can not get this feature to work correctly. Currently I am going do the path of isatap and DNS.

    Any help would be greatly appreciated.

    Thank you!

  7. Bruno Guerra

     /  April 25, 2016

    Great Article. We got a problem to access a website of company, that is hosted outside of organization. Configured for exception and it works successfully. Regards.

  8. Trying to troubleshoot an issue from the other direction:
    DA Clients can resolve and connect to infrastructure servers, however
    Servers cannot resolve or connect to DA Clients (PIng of short name or FQDN gives could not find hostname, nslookup however returns the ipv6 address correctly)

  9. Chris

     /  May 24, 2017

    Hi Richard, should you be able to resolve the Domains NetBIOS name using nslookup/resolve-dnsname? We are having issues with long delays before being able to resolve internal server addresses after connecting.

  10. Eddie

     /  July 3, 2017

    Just thought I should leave a comment as we were having DNS issues and could not find a solution. For us, performing a get-daconnectionstatus returned NameResolutionFailure no matter what we did. All components on the Remote Access Dashboard had green ticks. All client side diagnostics were positive aside from ‘netsh advfirewall monitor show mmsa’ returning ‘No SAs match specified criteria’. All certificates were working and being validated. The firewall and all Group Policies were applied correctly on the client devices. However, the clients were always in a state of connecting.

    The solution in our case was Group Policy on the DA server. An upstream policy had disabled the Windows Firewall causing the connection failures. Once the offending policy was blocked and the server firewall was functioning the clients connected without issue. So, check the Windows Firewall status on your server.

    It would be good if the Remote Access Dashboard checked this in the Operations Status page.

    • Hi Eddie. Thanks for sharing your experience. As you learned, the Windows firewall is crucial for the operation of DirectAccess. It must be enabled on the DirectAccess client and the server as well. It is a shame that the Remote Access Management console doesn’t check its operation and report on it though! It’s a serious oversight on the part of the DirectAccess developers, that’s for sure!

  11. Andrew

     /  November 7, 2017

    Hey Richard, I’m curious if you’ve ever run into IPsec tunnels not being established on some client computers while other client computers have no issues. I think I have narrowed it down to a certificate issue. On a computer with no IPsec tunnels, I can delete the computer certificates and re-enroll from our CA. After that, DirectAccess is able to establish a connection and I can reach internal resources. About 30 seconds later, it drops back out. Rinse and repeat. I haven’t found a reason the certificates could be the issue. Only a few of our client machines (~10 out of 800) are affected. Any thoughts on how to proceed? Crazy issue to troubleshoot. 🙂

    • Wow, that is very strange. I’ve never encountered a scenario like that. Have you enabled IPsec auditing to see if that yields any clues?

      • Andrew

         /  November 8, 2017

        I have – most of the events that were generated while I was troubleshooting said that negotiation timed out. Because of that, I went down the certificate path. Since then, I haven’t seen anymore logs in Event Viewer related to IPsec. I will keep an eye on it as I continue troubleshooting. I am considering migrating our CA from 2012 to 2016. I am also making sure that these clients (Windows 10 Edu Creators Edition) are fully patched. I will also see what updates are available for our DA server and apply them if they make sense (it is running on Server 2016).

      • If you plan to upgrade your PKI, be advised that it is disruptive to clients outside of the network when you make the change. You’ll have to bring them back inside or connect via VPN to update group policy after you make the change in the Remote Access Management console.

      • Andrew

         /  November 15, 2017

        My original issue with IPsec tunnels was self-inflicted. I caused the issue by removing certificates and re-enrolling with our CA while I was troubleshooting this problem… I probably chose the wrong certificate. With that off the table, our symptoms show in this order:

        1. A connection via IPHTTPS is established *I haven’t tested whether or not this is an issue over Teredo* – DCA shows Connecting…
        2. IPsec tunnels are created (both MMSA and QMSA show in Windows Firewall) – DCA shows Connecting…
        3. DirectAccess attempts to validate the connection back to the corporate network. We chose to ping our DC and use a HTTP test back to the web probe host. – DCA shows Connecting…
        4. The connection is established (the above tests passed) – DCA shows Connected.
        5. About 5-30 seconds later, the DCA status changes from ‘connected’ to ‘connecting’ – it says it is attempting to contact the DirectAccess server. Oddly enough, there are still IPsec tunnels established. The IPHTTPS connection shows as active too.
        6. The corporate network is unreachable. The DNS server is unreachable.

        It ended up being software on the client machines, not a server issue, causing the problem. We are running Lenovo recommended updates on our laptops anytime they are at our Help Desk. ‘Intel Online Connect’ is included in that list of recommendations. Basically, any computer our Help Desk sees will have Windows updates and system updates installed. So, a good number of laptops in our environment were getting ‘Intel Online Connect’. Removing it and restarting has resolved the connection issue. Luckily, all of our teachers and students return to campus every day so removing it via SCCM won’t be an issue.

        It looks like Lenovo and Intel worked closely with each other to get this software to all devices with 7th and 8th gen chips ( We just updated all of our hardware so that is why it was recommended to us. It isn’t inherently bad software, it just breaks DirectAccess. I suspect it has to do with DirectAccess’ encryption. Somehow the software is interfering with it. There are reports of this issue on Lenovo’s and Intel’s forums when the product was still called ‘Intel Technology Access Driver’… At least I am assuming that is what it was called in the past. Maybe this is coincidental and ‘Intel Online Connect’ is a completely new product.


        Thanks for your help! I hope this information helps someone in the future. We have reached out to Microsoft and Lenovo to report the problem.

      • Thanks so much for sharing this! I’m sure it will help others who may be experiencing the same problem. It’s a good troubleshooting less though, and one I learned a long time ago. Whenever I encounter unusual behavior like this, I always insist on testing with a clean machine or, at a minimum, removing all unnecessary GPOs and any installed third-party software. Not just disabling it, but removing it. As you learned here, and based on my extensive experience, often the culprit is third-party software interfering with DirectAccess operation in some way!

  12. Hello, I’ve got a strange issue where DA clients connecting to the internal LAN are delayed in detecting the domain profile. So, for the 1st few minutes all network resources fails. It seems as thought when the connection first initiates, it tries to connect to the /insideoutside website on the DA server, but the Windows Firewall on the client is blocking DNS resolution of the FQDN to the NLS website. I guess it tries on IPV6 a few times, times out, then succeeds on IPV4. After successful domain detection, which could take several minutes, everything works fine on IPV6. We have native IPV6. An 11 month support case with Microsoft was closed because they could not find the problem. -Thanks for any help.

  13. Michał Grzegorek

     /  May 29, 2019

    Hi Richard,

    I’m experiencing the same issue where I can ping DNS server, but when I try to resolve DNS name, it doesn’t work. The client machine is Windows 10 1903. Direct Access works perfect and Windows 10 1809 and below. Can you please advise?

    • If you can ping the DNS server but it doesn’t respond to DNS queries I would question if you have a fully established DirectAccess connection. To me it sounds like you’ve got an IPv6 transition technology established but no IPsec connections. ICMP/Ping is exempt from IPsec policy processing, so you’d be able to ping but nothing else. I’d have a close look to make sure IPsec is functioning properly.

  14. Muditha

     /  May 30, 2019

    Hi Richard

    I configured the DA server & tested Client connection. GP is fine. Client not connecting from outside network.

    This is the output from Connectivity troubleshoot tool.

    31/05/2019 3:24:38 PM]: In worker thread, going to start the tests.
    [31/05/2019 3:24:38 PM]: Running Network Interfaces tests.
    [31/05/2019 3:24:38 PM]: Ethernet (Realtek PCIe GBE Family Controller): fe80::cdc1:9dc2:173c:8185%18;:;
    [31/05/2019 3:24:38 PM]: Default gateway found for Ethernet.
    [31/05/2019 3:24:38 PM]: Ethernet has configured the default gateway
    [31/05/2019 3:24:38 PM]: Default gateway for Ethernet replies on ICMP Echo requests, RTT is 0 msec.
    [31/05/2019 3:24:38 PM]: Received a response from the public DNS server (, RTT is 32 msec.
    [31/05/2019 3:24:38 PM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
    [31/05/2019 3:24:38 PM]: Running Inside/Outside location tests.
    [31/05/2019 3:24:38 PM]: NLS is https://DirectAccess-NLS.xxxxxxxxx:62000/insideoutside.
    [31/05/2019 3:24:38 PM]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
    [31/05/2019 3:24:38 PM]: NRPT contains 3 rules.
    [31/05/2019 3:24:38 PM]: Found (unique) DNS server: fddc:e3d0:7c2:3333::1
    [31/05/2019 3:24:38 PM]: Send an ICMP message to check if the server is reachable.
    [31/05/2019 3:24:38 PM]: DNS Server fddc:e3d0:7c2:3333::1 does not reply on ICMP Echo requests.
    [31/05/2019 3:24:38 PM]: Running IP connectivity tests.
    [31/05/2019 3:24:38 PM]: The 6to4 interface service state is default.
    [31/05/2019 3:24:38 PM]: Teredo inferface status is offline.
    [31/05/2019 3:24:38 PM]: The configured DirectAccess Teredo server is
    [31/05/2019 3:24:38 PM]: The IPHTTPS interface is operational.
    [31/05/2019 3:24:38 PM]: The IPHTTPS interface status is IPHTTPS interface not installed..
    [31/05/2019 3:24:38 PM]: IPHTTPS is used as IPv6 transition technology.
    [31/05/2019 3:24:38 PM]: The configured IPHTTPS URL is https://xxxxxxxxxxxx:443.
    [31/05/2019 3:24:38 PM]: IPHTTPS has a single site configuration.
    [31/05/2019 3:24:38 PM]: IPHTTPS URL endpoint is: https://xxxxxxxx:443.
    [31/05/2019 3:24:39 PM]: Successfully connected to endpoint https://xxxxxxxxx:443.
    [31/05/2019 3:24:39 PM]: No response received from
    [31/05/2019 3:24:39 PM]: Running Windows Firewall tests.
    [31/05/2019 3:24:39 PM]: The current profile of the Windows Firewall is Public.
    [31/05/2019 3:24:39 PM]: The Windows Firewall is enabled in the current profile Public.
    [31/05/2019 3:24:39 PM]: The outbound Windows Firewall rule Core Networking – Teredo (UDP-Out) is enabled.
    [31/05/2019 3:24:39 PM]: The outbound Windows Firewall rule Core Networking – IPHTTPS (TCP-Out) is enabled.
    [31/05/2019 3:24:39 PM]: Running certificate tests.
    [31/05/2019 3:24:39 PM]: No usable machine certificate found.
    [31/05/2019 3:24:39 PM]: Found 0 machine certificates on this client computer.
    [31/05/2019 3:24:39 PM]: Running IPsec infrastructure tunnel tests.
    [31/05/2019 3:24:39 PM]: Failed to connect to domain sysvol share \\xxxxxxx\sysvol\xxxxxxxxxxx\Policies.
    [31/05/2019 3:24:39 PM]: Running IPsec intranet tunnel tests.
    [31/05/2019 3:24:39 PM]: Failed to connect to fddc:e3d0:7c2:1000::1 with status IcmpError.
    [31/05/2019 3:24:39 PM]: Failed to connect to fddc:e3d0:7c2:1000::2 with status IcmpError.
    [31/05/2019 3:24:39 PM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.xxxxxxxx.
    [31/05/2019 3:24:39 PM]: Running selected post-checks script.
    [31/05/2019 3:24:39 PM]: No post-checks script specified or the file does not exist.
    [31/05/2019 3:24:39 PM]: Finished running post-checks script.
    [31/05/2019 3:24:39 PM]: Finished running all tests.

    • Unfortunately this log file isn’t fully meaningful without some additional context. If you’ll send me an email directly I’ll tell you what additional information I need to offer advice for you. 🙂

  15. Pas

     /  July 17, 2019

    Hi Richard,
    Thank you for posting very useful information.
    From your experience, have you built multisite/single-site DA solutions in Google GCP?
    Quoted from the link
    I found the above from GCP documentation and was not sure if the Google platform would be the ideal platform to deploy a DA solution?
    Thanks in advance,

  16. Robert Meany

     /  April 9, 2020


    Is it possible to configure DirectAccess to register its client IPV6 addresses with the intranet DNS servers so that our internal devices can connect out to the clients for management purposes? Very specifically I need to be able to use SCCM remote control on the direct access clients so we can provide support… Right now when I try to ping or connect to our DA clients from anything on the intranet other than the DA server itself, DNS cannot resolve their addresses..

    Thank you for any insight you can provide on this.

    • Yes, and typically it happens by default and doesn’t require any special configuration. Not sure why that isn’t happening in your case…

  17. Corey R

     /  May 10, 2020

    We’ve been using DirectAccess for quite a few years on a Server 2012 R2 server. We have everything working great, including Manage Out using ISATAP. However, with the adoption of Cloud Services we have a small annoyance. We use Cloudflare to Proxy many of our cloud services. We have many internal CNAME DNS entries pointing to something like, which obviously resolves externally. However, when accessing these addresses over DA we end up with an issue. Exempting the DNS entries from NRPT is the obvious solution, just like we do with many services that already have edge services. But I’m wondering if there’s an easier solution to handle internal DNS entries that resolve to an external server… I hope that make sense or perhaps exempting is the only solution? Thanks!

    • If you want traffic going to to go over the DirectAccess tunnel, your only option is to put that entry in your NRPT configuration. No other way to accomplish that.

      • Ansmar

         /  November 17, 2020

        How about entering aliases (CNAMEs) of Azure service – for example storage-accounts have aliases but the actual record is This record may change I believe so I wouldn’t want to use it.

        We would like to restrict the use of these storage accounts to our companys public ip and that’s why we need to tunnel traffic to those storage accounts

      • That might work, but it’s not something I’ve tested. Azure may have an issue with it, but I’m not sure.

  18. Guillaume

     /  June 14, 2020

    Hello, Richard,

    The above connection problem is now solved. However the customer can’t find the DC for example, I think there is a name resolution problem. It is possible to go on the internet to open a session with his login, but it is not possible to go on a machine of the domain for example. With the commands \\NB-123456\c$ or \\

    Thank you for your help.

  19. Guillaume

     /  June 18, 2020

    Not precisely if I ping one of his machines I get a response from the public IPv4 address of the machine that comes out in the responses to the ping.

  1. Friday Five - January 17, 2014 - The Microsoft MVP Award Program Blog - Site Home - MSDN Blogs
  2. Git clone for Windows working with Direct Access - BlogoSfera
  3. Top 5 DirectAccess Troubleshooting PowerShell Commands | Richard M. Hicks Consulting, Inc.
  4. DirectAccess NRPT Configuration with Split DNS | Richard M. Hicks Consulting, Inc.

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading