none
DirectAccess client settings problem

    Question

  • Hi,

    I did a simple DirectAccess lab I already made work couple of times ago. For reasons, this time it did not work. I did some troubleshooting and the commands below show weird settings :

    - netsh dns show state

    - netsh namespace show effectivepolicy

    I did some googling and found that the link below tries to troubleshoot similar problem :

    http://support.risualblogs.com/blog/2010/12/23/direct-access-issues-on-a-specific-windows-7-client-network-location-behavior-never-use-direct-access-settings/.

    That link suggests to do some setting in the registry :

    Key: Software\Policies\Microsoft\Windows NT\DNSClient or System\CurrentControlSet\services\Dnscache\Parameters<1>

    Value: "EnableDAForAllNetworks"

    I tried and it and it did not solve my problem. Anyway ; my aim is not this kind of fine troubleshooting. I just need to know why I fall in this trouble and how to avoid it next time I do the lab. I want to make the lab work (of course) !

    Thanks in adavance for any help !

    Sunday, November 18, 2012 11:06 PM

All replies

  • Without knowing more about what weird things you are seeing in those command outputs, if you are experiencing the "Never use DirectAccess settings" message in the netsh dns show state, then I believe you are looking in the wrong place in the registry to correct that behavior. Check this post for the right information on adjusting that setting: http://www.ivonetworks.com/news/2011/08/network-location-behavior-never-use-direct-access-settings/

    If that doesn't solve the issue, we'll need some more information to figure out what is going on. Do you have a log file from the DirectAccess Connectivity Assistant that you could post?

    Tuesday, November 27, 2012 7:22 PM
  • Hi Jordan,

    Thank your for your precious answer.

    As far as I remember, the article http://support.risualblogs.com also suggested me to modify the key Software\Policies\Microsoft\Windows NT\DNSClient. I, unfortunately did not be able to localize that key ; that's why I presumed that I had to modify the other one suggested : System\CurrentControlSet\services\Dnscache\Parameters<1>. May be the machine I was using as a client (Windows 2008R2) does not have the registry key Software\Policies\Microsoft\Windows NT\DNSClient ? Any way, I'll double-check.

    I will do the lab again ! May be I will not have the problem again, since I will do it with newly installed virtual machines ?

    I'll let you know !
    Monday, December 03, 2012 8:26 PM
  • I'm, unfortunately, still having trouble with my small DirectAccess Lab. I did apply the "EnableDAForAllNetworks" registry fix. Configuration seems to be correct. Now, I can ping th IPv6 address of the DNS server from the internet client. But ; name resolution does not work when the client is out of corporation.

    My configuration is composed of 3 Windows Server 2008 R2 machines : DCSRV1 (10.0.0.1 - domain controller, DNS server, AD CS), BOSTON (10.0.0.2 - Direct Access Server), BINGHAMPTON (10.0.0.10 internal - 131.107.0.10 external - client machine).

    I paste the results of troubleshooting commands below :

    ipconfig /all

    netsh dnsclient show state

    netsh namespace show policy

    netsh namespace show effectivepolicy

    I know I'm not very far from making that lab work. But, I still need help. Thanks in advance for any help !

    ==========================================================================================

    ipconfig /all


    Windows IP Configuration

       Host Name . . . . . . . . . . . . : BINGHAMPTON
       Primary Dns Suffix  . . . . . . . : nwtraders.msft
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : nwtraders.msft

    Ethernet adapter Local Area Connection:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
       Physical Address. . . . . . . . . : 00-0C-29-F0-49-77
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::8df1:fcde:25fa:4bf7%11(Preferred)
       IPv4 Address. . . . . . . . . . . : 131.107.0.10(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . :
       DHCPv6 IAID . . . . . . . . . . . : 234884137
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-8D-12-45-00-0C-29-F0-49-77
       DNS Servers . . . . . . . . . . . : 131.107.0.2
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Tunnel adapter isatap.{E0E40948-5257-4877-B8FA-345BAE840620}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter Local Area Connection* 9:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv6 Address. . . . . . . . . . . : 2001:0:836b:2:2891:9e1:7c94:fff5(Preferred)
       Link-local IPv6 Address . . . . . : fe80::2891:9e1:7c94:fff5%13(Preferred)
       Default Gateway . . . . . . . . . :
       NetBIOS over Tcpip. . . . . . . . : Disabled

    Tunnel adapter iphttpsinterface:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : iphttpsinterface
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter 6TO4 Adapter:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft 6to4 Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv6 Address. . . . . . . . . . . : 2002:836b:a::836b:a(Preferred)
       Default Gateway . . . . . . . . . : 2002:836b:2::836b:2
       DNS Servers . . . . . . . . . . . : 131.107.0.2
       NetBIOS over Tcpip. . . . . . . . : Disabled

    netsh dnsclient show state

    Name Resolution Policy Table Options
    --------------------------------------------------------------------

    Query Failure Behavior                : Always fall back to LLMNR and NetBIOS
                                            if the name does not exist in DNS or
                                            if the DNS servers are unreachable
                                            when on a private network

    Query Resolution Behavior             : Resolve only IPv6 addresses for names

    Network Location Behavior             : Let Network ID determine when Direct
                                            Access settings are to be used

    Machine Location                      : Outside corporate network

    Direct Access Settings                : Configured and Enabled

    DNSSEC Settings                       : Not Configured

    netsh namespace show policy


    DNS Name Resolution Policy Table Settings

    Settings for nls.nwtraders.msft
    ----------------------------------------------------------------------
    Certification authority                 : DC=msft, DC=nwtraders, CN=nwtraders-DCSRV1-CA
    DNSSEC (Validation)                     : disabled
    DNSSEC (IPsec)                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (IPsec)                    : disabled
    DirectAccess (Proxy Settings)           : Bypass proxy



    Settings for .NWTRADERS.MSFT
    ----------------------------------------------------------------------
    Certification authority                 : DC=msft, DC=nwtraders, CN=nwtraders-DCSRV1-CA
    DNSSEC (Validation)                     : disabled
    DNSSEC (IPsec)                          : disabled
    DirectAccess (DNS Servers)              : 2002:836b:2:1:0:5efe:10.0.0.1
    DirectAccess (IPsec)                    : disabled
    DirectAccess (Proxy Settings)           : Bypass proxy

    netsh namespace show effectivepolicy


    DNS Effective Name Resolution Policy Table Settings


    Settings for nls.nwtraders.msft
    ----------------------------------------------------------------------
    Certification authority                 : DC=msft, DC=nwtraders, CN=nwtraders-DCSRV1-CA
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (Proxy Settings)           : Bypass proxy



    Settings for .NWTRADERS.MSFT
    ----------------------------------------------------------------------
    Certification authority                 : DC=msft, DC=nwtraders, CN=nwtraders-DCSRV1-CA
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              : 2002:836b:2:1:0:5efe:10.0.0.1
    DirectAccess (Proxy Settings)           : Bypass proxy



    Saturday, January 26, 2013 8:10 PM
  • Hummm !!! It seems also that my problem is that ISATAP interfaces did not stay configured on internal servers (DCSRV1 and BOSTON). For reasons I do not understand, those interfaces did have their IPv6 address ou did loose them.

    ???

    Sunday, January 27, 2013 4:47 AM
  • Sorry for the delay in my response. I wouldn't worry too much about the ISATAP adapters, at least not yet. I recommend getting DirectAccess up and running without ISATAP at all first, then once it's working you can add ISATAP back, if you actually need it.

    So I would remove the ISATAP record from your DNS, and then restart all of your servers so that the addresses are dropped. Make sure the ISATAP IPv6 records are cleared out from DNS as well so you know they are not interfering with your tests.

    Monday, February 04, 2013 2:56 PM
  • Thanks for your answer Jordan,

    Let me ask you a question : If

    ISATAP is not configured on the internal DNS Server, how the directaccess server could tell to Outside corporate clients how they can resole names ? I did understand that the IP adress of the internal DNS server that is communicated to Outside corporate clients must be IPv6 and is configured on an ISATAP interface ?


    • Edited by kayoumt Monday, February 04, 2013 4:03 PM
    Monday, February 04, 2013 4:03 PM
  • Nope, as long as you are using either UAG DirectAccess or Server 2012 DirectAccess you don't need ISATAP at all. The client computers ask the DirectAccess server how to get to "Server1", and it is the DirectAccess server's job to either go find an IPv6 address in DNS, or if one doesn't exist, to spin up a fake one on the fly that the client can use. This is the DNS64 service, and it works natively on either of those versions of DirectAccess.

    If you are using the native DirectAccess in Server 2008 R2 then that is a different story, and I recommend you stop now because you probably aren't going to get very far with it.

    ISATAP is only needed when you have an IPv4 internal network and you need to initiate traffic from inside your network outbound toward the DA client computers. For example, if a helpdesk computer needs to RDP into a DirectAccess computer, you might need ISATAP to make that happen. You certainly do not need ISATAP to make DirectAccess work though, so I consider this an advanced scenario that you should only try out after you have base DA connectivity established in the first place.

    Monday, February 04, 2013 7:24 PM
  • If you are using the native DirectAccess in Server 2008 R2 then that is a different story, and I recommend you stop now because you probably aren't going to get very far with it.

    Unfortunately ; I'm using native DirectAccess on 2008R2. I'm working on MCITP labs. As far as I know, nothing in the certification book tells that I can learn UAG DirectAccess or 2012 DirectAccess instead of 2008R2 DirectAccess.

    Monday, February 04, 2013 7:49 PM
  • No, I doubt the MCITP tests would have anything specific to UAG or 2012. It's unfortunate that the tests don't keep up with what is actually happening in the field, because I have never met anyone that is using native DirectAccess provided in 2008 R2 for production :) UAG, however, is very popular.

    I have never been through the guides to build this particular lab, but it looks like you are correctly getting a 6to4 tunnel, and if you are able to ping the DNS server then your ICMP traffic seems to be going through it. So the problem is likely that you don't have any IPsec tunnels being established. Very often this problem deals with certificates. Have you issued the "Machine" certificates from the CA server to the DirectAccess server and the client machine?

    Monday, February 04, 2013 8:26 PM
  • So the problem is likely that you don't have any IPsec tunnels being established. Very often this problem deals with certificates. Have you issued the "Machine" certificates from the CA server to the DirectAccess server and the client machine?

    Nothing in the lab talk about IPSEC. Maybe the lab supposes that IPSEC default settings will be used ? However, two WebServer certificates are issued (and, I did it) : one for IIS on the NLS server, and one for IP-HTTPS on the DirectAccess server.

    The lab also asks to run the commands the on the  stop iphlpsvc and start iphlpsvc on the DirectAccess and other internal servers. The lab does, unfortunately, tell nothing about what iphlpsvc is supposed to do ?

    Monday, February 04, 2013 9:01 PM
  • Restarting the IP Helper service just re-initializes NICs and network settings so that you don't have to restart the servers.

    It sounds like your guide is not complete. DirectAccess connects using IPsec tunnels between the client and the DA server, and those tunnels are authenticated using machine certificates that must exist on the DA server and on each client computer. These certificates must be issued by your internal CA server. They are typically based off of the "Computer" template in Windows CA. If you have not issued such certificates, your DA is not going to work.

    Monday, February 04, 2013 9:39 PM
  • Here is an article I wrote that describes the certificates that DirectAccess uses: http://www.ivonetworks.com/news/2012/05/directaccess-help-im-drowning-in-certificates/

    Monday, February 04, 2013 9:40 PM
  • Thanks for the article, Jordan.

    I'm very familiar with AD CS certificates. I'll do the lab again. I'll make sure "Computer" certificates are issued and IPSEC is working.

    One thing I forgot to tell is : The lab did ask to remove ISATAP from block list, by running the command dnscmd /config /globalqueryblocklist wpad. I suppose I do not need to run that command if I do not need to configure ISATAP ?

    Tuesday, February 05, 2013 3:29 AM
  • That is correct. If in the future you do intend to utilize ISATAP, do it selectively instead of wholesale. Here is an excellent article on that process: http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html

    Tuesday, February 05, 2013 1:45 PM
  • Thanks for the nice article, Jason.

    I ask two more questions, to be sure I understand what you are suggesting me :

    1) If I add a record in DNS for the name [something]ISATAP.mydomain and I do the required GPO configuration, does it mean the ISATAP.mydomain global name will not have any effect (be the name blocked or not) ?

    2) The article is showing how manage out clients are configured. How about the intranet servers (including DNS Server) ? Do I have to let those servers stay IPv4 ?

    Note : I do not want to deploy NAT64/DNS64. It does not belong to MCITP exam scope.

    Tuesday, February 05, 2013 2:36 PM
  • I'm sorry, I think I forgot once again that you are trying to do native DirectAccess and not UAG. For native DirectAccess, especially since this is just a lab, go ahead and configure ISATAP just like it says. You might as well. You either need to have ISATAP or you need to have native IPv6 as your internal network. If you have IPv6, then you don't need ISATAP, but if you are running an IPv4 internal network, you will need ISATAP for native DirectAccess to work, and since you won't have NAT64/DNS64 available, this limits you greatly.

    So all in all, sorry I didn't mean to steer you down the wrong path. Follow the guide and hopefully it works with ISATAP in there globally, but it's such a bummer that you have to do this when any real-world work you do with DirectAccess is almost certainly not going to be this way.

    Tuesday, February 05, 2013 3:28 PM
  • Thanks for your generous help, Jordan.

    I know that Thomas Shinder wrote a good lab on UAG DirectAccess.

    http://blogs.technet.com/b/tomshinder/archive/2010/10/29/test-lab-guide-demonstrate-uag-sp1-rc-directaccess-remote-management-blog-version.aspx

    His lab is detailed and probably very helpful but too long : the proof of concept in this blog requires to complete another lab, that lab also requires to complete another base lab. I did that lab almost blindly, couple of month ago, because I did not have a very good understanding of GPO, AD CS and DNS concepts. Maybe in next weeks I'll have time to wrap-up Shinder's UAG DirectAccess lab and do it again.

    It's curious to not have a good, simple and wording DirectAccess lab in Microsoft's official MCITP book ; even if that issue is not the most important in the MCITP exam.

    http://www.microsoft.com/learning/en/us/book.aspx?id=14877

    Thanks again ! I'm sure I'll have fun doing Shinder's lab. Hope Iwill have time.

    Tuesday, February 05, 2013 4:13 PM
  • Unbelievable ! The lab works with native DirectAccess.

    I did the lab again (from beginning to end). I added the two steps below :

    - Configured GPO to make all computers automatically enroll for Computer certificates

    - Configured GPO to allow ICMPv4 and ICMPv6 inbound requests on all computers. I did it because DirectAccess setup showed a warning complaining that ICMP requests were not allowed.

    I did have a look on IPSEC Monitoring. And, it makes me ask some questions :

    1) Do DirectAccess remote Clients automatically request (or require) IPSEC communication ?

    2) It seems that authentication by Certificate is the default behavior of IPSEC in the Main mode of the Security Association ?

    3) I tried to change the default behavior of IPSEC with WFAS console (properties) with GPO, but I did not be able ?

    4) It seems that the IPSEC tunnel stops at the DirectAccessServer, it does not reach internal servers ?

    5) It seems that IPSEC communication could happen without explicit rules be defined ?

    Answers to these questions on IPSEC will really help me better understand IPSEC. Thanks in advance !

    Saturday, February 16, 2013 6:12 AM
  • Forget about my questions on IPSEC ! I got the answer. I just saw that DirectAccess created two GPOs and attaches them to the domain. I saw that, at least, three IPSEC rules are defined in the GPOs.

    So far ; DirectAccess works very well except for one case : when I connect the DirectAccess client to a Win7 VM playing the role of ICS NAT. The configuration of the DirectAcces client and Teredo seem to be correct (see below the result of the command netsh interface teredo show state). With true RRAS NAT installed on the Win7 VM, it already worked.

    Teredo Parameters
    ---------------------------------------------
    Type                    : enterpriseclient
    Server Name             : 131.107.0.2 (Group Policy)
    Client Refresh Interval : 30 seconds
    Client Port             : unspecified
    State                   : qualified
    Client Type             : teredo client
    Network                 : unmanaged
    NAT                     : restricted
    NAT Special Behaviour   : UPNP: No, PortPreserving: No
    Local Mapping           : 192.168.137.100:53736
    External NAT Mapping    : 131.107.0.5:62898

    It will be nice for me to know what is going on with last little ICS/Teredo issue.

    Sunday, February 17, 2013 3:25 AM
  • Hey kayoumt, sorry I was never notified of your email with the IPsec questions or I would have answered them :) You are correct that the DirectAccess Clients GPO is the thing that places the IPsec rules into WFAS on the client computers, and no you should not try to change them. DirectAccess traffic is always IPsec over the internet, but you are correct, once the traffic gets inside the network, the DirectAccess server decrypts the packets and sends them on inside the network as regular network traffic. In UAG and Server 2012 DirectAccess there are options to do end-to-end IPsec where you keep it encrypted all the way through, but it's an option that I have never seen anybody actually use in the wild.

    To look further into your Teredo issue we'll need some more information. What you posted shows that Teredo is successfully connected, but what really happens is that one of the transition tunnels (6to4, Teredo, IP-HTTPS) connects a tunnel, and then your IPsec tunnels need to build inside that transition tunnel. So if Teredo is connected but DirectAccess is not working, then there are a few things that could potentially be wrong, but it could be that the IPsec tunnels aren't building inside the Teredo tunnel for some reason.

    If you are still having this problem, try downloading a tool called the DirectAccess Connectivity Assistant onto your test machine and generate some log files from it. This log file will contain many different netsh command outputs that will give a lot of information to troubleshoot the connection.

    Tuesday, February 19, 2013 5:45 PM
  • Thanks for your very detailed answer Jordan.

    Before I try the DirectAccess Connectivity Assistant tool, I wanted to compare IPSEC and Teredo behaviors of the DirectAccess client, depending on the type of NAT (ICS ou RRAS) the client is connected to. The reason why I want to do that test is ; it already worked with RRAS NAT.

    Tuesday, February 19, 2013 7:07 PM