none
Server 2012 Direct Access DNS problem

    Question

  • I searched a lot in the last few hours, found people with similar problems, but they ever had pretty simple solutions (had to turn on their Windows Firewall). It´s different in my case and I hope I´m asking at the right place.

    Setup:
    A Server 2012 with 2 NICs, one in the LAN and one in the Perimeter Network behind a NAT device. On the Edge Firewall we have 2 consecutive public IP addresses with a 1:1 NAT to the perimeter facing NIC of the DA Server allowing 3544/UDP, IP41 and 443/TCP.
    On the Client side for testing I have a Windows 8 Enterprise PC.
    We have a PKI in place with the CRL Servers available in the Internet. All certificates used are issued by our internal PKI and they validate on every system involved.

    So far in the Remote Access Management Console, everything is green, GPOs are distributed and everyone looks happy. The Client also creates the IP-HTTPS connection (Teredo is not an option as I´ve learned when behind a NAT device) fine and I can see that connection on the DA Server. The Client also receives an IPv6 address from the DA Server. I can ping the Client from the DA Server and I can ping the DA Server from the Client (all IPv6).

    In the NRPT, there´s an entry for our internal Domain Name pointing to the IPv6 address of the DA Server. I understood that Server 2012 now has DNS64 implemented and that the DA Server is playing a Proxy role for DNS for the DA clients, right? I can also ping this IPv6 address from the Client.

    But when I run a "get-daconnectionstatus" on the Client, it shows me an error with the Substatus "NameResolutionFailure". When I do a nslookup by using the DA Server as the "DNS Server", lookups fail.

    My assumption is, that the DNS64 service is not working, but I´m also not sure if you really can connect to it with nslookup and issue DNS queries.

    Recap: IP-HTTPS works, IPv6 communication between Client and DA Server works, but DNS resolution fails.

    After hours of searching, I always come up with the same articles, whitepapers and tutorials again. So I´m currently out of Ideas.

    mercredi 13 mars 2013 10:58

Réponses

  • Hi,

    thanks for your help. Netstat indeed shows me that the iphlpsvc is listening on Port 53.

    The DA Server can query the internal DNS fine. When I do a nslookup on the DA Server and try to resolve the Domain Name, I get a list of all DCs. Also I can resolve single internal Servers too.

    Question: When the iphlsvc is listening on Port 53, it should be queryable by nslookup too, right? When I do a nslookup directly on the DA Server and set the server to 127.0.0.1 it is also not able to resolve any names.

    Strange is also that netstat shows me the iphlpsvc listening on POrt 53, but when I do a "telnet 127.0.0.1 53" on the DA Server it gets no connection on Port 53. That´s odd. If it is listening it should work locally at least or not? Are there any security mechanisms maybe preventing the connection?

    Edit: I realize that the iphlpsvc is listening on 53 UDP and not TCP, so I am obviously not able to make a test connection with Telnet on Port 53. I´m aware that DNS queries are normally done via UDP, but isn´t it recommended to allow TCP connections just in case requests are too big for UDP?


    Edit#2: I think I got it sorted. I looked through the Firewall Rules to find one (or 2) for the DNS UDP/TCP Port 53. I indeed found 2 not editable rules which have probably been generated by DA itself. But they had the wrong IPv6 address in it. So I copied the 2 rules (which made them editable) and put in the correct IPv6 address for the DNS64 Service of the DA Server. I´m now able to resolve names when connected to the DA Server via IP-HTTPS. So far it looks good and I think I can go on with further in-deep testing.

    Thank you very much for your help. Sometimes you just need to explain your problem and need a small push in the right direction to find the solution. This helped me a lot!

    vendredi 15 mars 2013 14:54

Toutes les réponses

  • Hi,

    Yes you should be able to use nslookup and send queries to your DA server using the IPv6 address listed in the NRPT rules.

    Check if/that you have "iphlpsvc" listening on port 53 on your DA server.(For example, by running "netstat -anb | more" and looking for :53)

    Can your DA server query the internal systems correctly? (Do you get your internal DNS servers preselected when starting nslookup?)


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    mercredi 13 mars 2013 19:42
  • Hi,

    thanks for your help. Netstat indeed shows me that the iphlpsvc is listening on Port 53.

    The DA Server can query the internal DNS fine. When I do a nslookup on the DA Server and try to resolve the Domain Name, I get a list of all DCs. Also I can resolve single internal Servers too.

    Question: When the iphlsvc is listening on Port 53, it should be queryable by nslookup too, right? When I do a nslookup directly on the DA Server and set the server to 127.0.0.1 it is also not able to resolve any names.

    Strange is also that netstat shows me the iphlpsvc listening on POrt 53, but when I do a "telnet 127.0.0.1 53" on the DA Server it gets no connection on Port 53. That´s odd. If it is listening it should work locally at least or not? Are there any security mechanisms maybe preventing the connection?

    Edit: I realize that the iphlpsvc is listening on 53 UDP and not TCP, so I am obviously not able to make a test connection with Telnet on Port 53. I´m aware that DNS queries are normally done via UDP, but isn´t it recommended to allow TCP connections just in case requests are too big for UDP?


    Edit#2: I think I got it sorted. I looked through the Firewall Rules to find one (or 2) for the DNS UDP/TCP Port 53. I indeed found 2 not editable rules which have probably been generated by DA itself. But they had the wrong IPv6 address in it. So I copied the 2 rules (which made them editable) and put in the correct IPv6 address for the DNS64 Service of the DA Server. I´m now able to resolve names when connected to the DA Server via IP-HTTPS. So far it looks good and I think I can go on with further in-deep testing.

    Thank you very much for your help. Sometimes you just need to explain your problem and need a small push in the right direction to find the solution. This helped me a lot!

    vendredi 15 mars 2013 14:54
  • Glad to hear that you managed to get it working!

    There is actually a "known" issue listed in the migration steps where the IPv6 addresses of the firewall rules are not updated when you change the IPv6 range used for a DA deployment.

    More info here: (search for "firewall") http://technet.microsoft.com/en-us/library/hh831643


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    mardi 26 mars 2013 20:42