How to debug this Direct Access DNS problem under Server 2012? RRS feed

  • Question

  • We have a DA infrastructure running on Server 2012, using IP-HTTPS. Apart from one system, it works as it should. And we don´t know how to debug the problem of that single system properly.

    The Problem:

    On the Client side it always looks like the DA client is not able to connect at all. DNS queries for internal Networks are not working as well (resolving Internet resources works of course).

    Looking on the DA Console, we cannot see a IP-HTTPS connection from that system also.

    What we looked for so far on the Client:

    Using the Windows Firewall Monitoring, we cannot see any IPSec negotiations.

    "netsh int httpstunnel show interfaces" reveals the correct URL, a Last Error Code of 0x0 and a Interface Status of IPHTTPS interface active.

    Get-DAConnectionStatus reveals Status = Error and Substatus = NameResolutionFailure

    In the DA Diagnostics File we can see a "Error: Corporate connectivity is not working. Windows is unable to resolve DNS names for probes." message on top. The rest of the Diagnostic logs (the Configuration pushed via the GPOs for example) seem to be correct when compared to another, working client.

    The Client is not resolving any internal DNS names. But we can ping the IPv6 address of the DNS64 Proxy, despite having no IPSec negotiations and the DA Server claiming that nobody is connected. If we run nslookup and point it to the IPv6 address of the DNS64 proxy, we also cannot resolve internal DNS names.

    We cannot spot any errors in the Eventlogs.

    GPResult shows no errors on the Client, so the Policies should be applied correctly.

    The Client had a Teredo Interface in status Up. We did not know why, but we disabled it with netsh just to make sure it is not causing any problems. No change in behaviour on the DA side.

    The Client with the Problem is a Windows 8 x64 system.

    What we looked for so far on the DA Server:

    Looking on the DA Console, we cannot see a IP-HTTPS connection from that system also.

    But using Netstat, we can see a connection on Port 443 from that system. Using the Direct Access Tracing and feeding it to the MS Network Monitor, we can see a "State = EstablishedState" from that IP as well.

    We cannot spot any errors in the Eventlogs.

    We run out of Ideas now how to debug that connection and why the DNS resolution is not working. The Client seems to be partly connected somehow, so we don´t know if the DNS queries are failing because of the incomplete connection of if the connection cannot be established completely because of the DNS problem.

    We removed that PC from the DA Client Security group (and so from the GPO) for a day and added it again to make sure there was not a problem applying the policy to the PC the first time.

    The Diagnostics chapter of this Article already mentiones the limited logging capabilities, but also talks about Log correlation. Which logs are meant here? Should there be tools like we have them to create and analyze Logs for Lync Servers? These are pretty powerful and would help a lot if we had something similar for DA.

    Wednesday, May 29, 2013 11:11 AM

All replies

  • We had the same problem (DNS resolution, no proper DA connection) on a Windows 7 machine too. But there we were able to solve the problem by changing the registry Key

    HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\EnableDAForAllNetworks

    from 2 to 0.

    Unfortunately in Windows 8 DA seems to be implemented different. At least I am not able to find the same Registry Key at the same place, nor am I able to find a Key named EnableDAForAllNetworks in the Win8 registry at all.

    What´s the aequivalent to this Windows 7 Key for Windows 8? Since the Windows 7 machine behaved exactly the same as the Windows 8 machine, I´m sure this can solve our problem here.

    Thursday, June 13, 2013 6:34 AM
  • Hi, I have run into similar situation. Everything seems nice but the DNS resolution. Client establishes infrastructure tunnel over HTTPS and its able to reach all IPv6 addresses on DA server IPHTTPSinterface. Even can access address which is inside NRPT table to be used for internal name resolution. But when I try nslookup with this IPv6 address for i.e. internall domain controller, I got the A response with IPV4 address. That is wrong and it seems that DNS64 isnt doing its JOB. I have also sniffed communication on internal DNS server and there is clearly seen, that queries comming from DA client are AAAA requests, which is again wrong (should be translated by DNS64 to A requests).

    However, DA server is apearing everything green including DNS64. Watching out configuration of DNS64 and NAT64 using cmdlets Get-NetDnsTransitionConfiguration and Get-NetNetTransitionConfiguration doesnt reveal any apparent problems. In DNS64 config, there can be configured which interface it listens to, but changing that to whatever else doesnt make any difference.


    Thursday, June 20, 2013 12:44 PM
  • Hi, so I have found the root cause of the problem. At least in my case, but I think it’s quite easy to get to that situation. It’s all about where does DNS64 listens for incoming DA client requests and the way NRPT is filled thorough Remote Access wizard (+ how policies - firewall rules and connection security rules are constructed).

    First, DNS64 listens on DA server, on IPv6 address. To find on which interface, you can run Get-NetDnsTransitionConfiguration and under AcceptInterface, the name of the interface can be seen and DNS64 listens on IPv6 address this interface holds. It doesn’t make any sense to change configuration thorough cmdlets, because it will not reflect the GPOs and instantly lead to client malfunction. DA configures DNS64 to listen on intranet interface (if you have more than one).

    NRPT rules are configured in the GUI (Step 3, Infrastructure servers). And here comes the confusion. In the DNS section, you can add DNS suffixes you have in the infra and you have to put IPv4 address of DNS servers which will resolve queries. But if you want to use DNS64, you have to put IPv4 address of adapter where DNS64 listens to. DA server then finds the correct IPv6 address to put inside NRPT rules (it’s unbelievable, that you can’t type directly IPv6 address!!). If you put there IPv4 address of you intranet DNS server, and you don’t have IPv6 deployed on the intranet, you have a problem. DA then use NAT64 to translate this address and DNS queries will go directly to intranet DNS. This will work only if you have IPv6 deployed in the intranet and all servers has IPv6 addresses registered in DNS.

    So I think the root cause is that configuration GUI on W2K12 server (RTM at least updated to June 2013) doesn’t reflect the reality of DNS64 is available on DA server itself, the respective dialog should be updated, so it will be clear which scenario is going to be used (dns64/intranet IPv6 DNS).


    Friday, June 21, 2013 7:55 AM
  • Hi David,

    thank you for the thorough explanation. But in your situation it sounds like DA was not working at all for you.

    For me it works great, I only have a problem with a single Windows 8 machine right now. The machine is being phased out soon, but I still like to find out what´s causing the problems on this particular machine, just in case the problem comes up later on another machine.

    We´re using DA with success for quite a while now, so I don´t think that I have a configuration problem on the Server. It must be something similar to the Windows 7 machine, where I posted the solution above of how I was able to fix it. But for that single Windows 8 machine, I still have no Idea what the problem is (and I´m sure it´s something on the Windows 8 machine).

    Kind regards!

    Friday, June 21, 2013 8:46 AM
  • Did you end up finding a solution for this.

    We just started using DA and I'm getting this same issue in Windows 8.  Clients can use DA but it's just saying 'connecting'...  and PS commands shows the same 'NameResolutionFailure' error.



    Wednesday, July 31, 2013 8:31 PM
  • Unfortunately I did not find a solution for my particular problem. But in the end it was only one Windows 7 machine (where the Registry Tweak mentioned above helped) and only a single Windows 8 machine so far (which was phased out in the meantime). All other machines have always been working flawless. So I can be sure that the problem I had was not related to my DA installation and probably caused by something being broken on the W8 installation for that particular machine.

    • Proposed as answer by mlteknik Wednesday, November 6, 2013 9:11 PM
    Monday, August 5, 2013 9:32 AM
  • If DA is working but the NCA just shows "connecting", then you probably want to re-visit Step 1 in the DirectAccess wizards to make sure your probe that you set in there is good. The querying tools are reporting whether or not they work on a fairly "dumb" probe of the items you define there. If it can see them, it reports good, basically.

    As to the registry key I have seen that numerous times and it shows up in the log files or in a "netsh dns show state" - if you run this command and see "Never use DirectAccess settings", then likely your registry key is there and set to "2", which is causing the problem.

    For the original question in this post, having IP-HTTPS with no IPsec tunnels, the most common cause I have seen of this particular behavior is a bad client-side machine certificate. I would try removing that and issuing a new cert and see if that helps.

    Tuesday, August 6, 2013 1:20 PM
  • Hi there.

    I believe I have the same problem with DA configuration - however with Windows Server 2016 and Win10 as client.

    The DA connection shows "Connecting..." and IP-HTTS is active. But I can't ping internal servers.

    I believe the problem is in either NRPT or internal domain controller DNS - but I can't identify the problem - if you could help me, I'd appreciate it.

    This is what I was able to identify:

    • the IPv6 connection is established, the result for "netsh int httpstunnel show interfaces" is "IPHTTPS interface active", the URL is corrent: https://<mycompany>:443/IPHTTPS, it is translatable to public IPv4 address from the internet.
    • I have IPv6 address assigned to my notebook
    • I can find my internal Domain Controller IPv6 address - and I can ping it, and also connect via remote desktop to it
    • I can also send a nslookup request to the domain controller, however only with -q=aaaa option and directly to the IPv6 address of the server - but I can only ask for IPv6 addresses, if I ask for IPv4, I'm not getting answer in IPv6 format - this might indicate problem with DNS64 - but how to check it?
    • but when I try to ping the FDQN of the domain controller, the address is not translated, it says that the name was not found - it definetely is not contacting the internal domain controller, this might indicate the NRPT problem - but how to check it?
    • the "netsh namespace show effectivepolicy" command shows correct values (at least I think so), means there is no DNS server for FDQN of my internal domain controller, and DNS server is set with the IPv6 address of domain controller for the .company.intra domain
    • with this it is logical, that the probe cannot be contacted, as it cannot resolve the name of it correctly (even though the is resolvable using the Resolve-DnsName cmdlet, but not with nslookup)

    Do you have an idea, where I might have done my configuration wrong?

    I can see here some ideas about the certificates, but I thought that this is connected only to Win7 machines... I'm not using any PKI.

    Thanks in advance.

    • Proposed as answer by Peter Smekal Saturday, March 4, 2017 12:09 PM
    • Unproposed as answer by Peter Smekal Saturday, March 4, 2017 12:10 PM
    Tuesday, February 28, 2017 4:00 PM
  • Hi, all.

    If you run into similar problem as I did, I was able to fix it!

    Here is the article I found. Basically it says, that the DNS server is using the same port as the DNS64, even the DNS64 service in Remote Access shows as running without an error. Once the DNS server is bound to only IPv4 addreseses' ports (as DNS64 is bind to IPv6 only ports) it starts working properly.

    • Proposed as answer by Peter Smekal Saturday, March 4, 2017 12:14 PM
    Saturday, March 4, 2017 12:14 PM
  • Glad you got it figured out! Keep in mind that running DirectAccess without PKI is less secure than running it with PKI. It's really not that difficult to implement the certs needed for DirectAccess if you ever want to change your implementation to be running in a best practices install. Running without PKI also limits you on growth for the future - if you want to do load balancing or Multi-Site or any advanced DA features, you'll have to roll out certificates anyway before you can do those things.
    Friday, March 17, 2017 1:38 PM