DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

DirectAccess Network Connectivity Assistant (NCA) Configuration GuidanceThe DirectAccess Network Connectivity Assistant (NCA), first introduced in Windows 8, provides DirectAccess connectivity status information as well as diagnostic support on the client. The NCA validates that DirectAccess is working end-to-end by attempting to reach internal resources defined by the administrator during the configuration of DirectAccess. NCA configuration and operation is a source of much confusion. This article serves to provide best practice configuration guidance for the NCA to ensure optimum and reliable operation.

NCA Operation

When a DirectAccess client is outside the corporate network, it will attempt to establish a DirectAccess connection any time it has an active Internet connection. After a DirectAccess connection is made, the NCA will attempt to validate DirectAccess connectivity by verifying availability of corporate resources as defined in the DirectAccess configuration (Remote Access Management console, Step 1, Edit, Network Connectivity Assistant).

If the NCA can reach the defined internal corporate resource(s), the DirectAccess connection is verified end-to-end and it will report the connection status as “Connected”. If it fails to connect to any internal corporate resource, it displays “Connecting”.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Figure 1. NCA successfully validated internal corporate resource connectivity.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Figure 2. NCA failed to connect to one or more corporate resources.

NCA Configuration

When first installing DirectAccess, the Remote Access Setup wizard will collect information to be used by the NCA, including corporate resources, helpdesk email address, and DirectAccess connection name. It will also provide the option to allow DirectAccess clients to use local name resolution.

Note: The NCA settings configured in the Remote Access Management console pertain only to Windows 8.x and Windows 10 clients. They are not used by Windows 7 clients at all.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Intuitively it would appear that information needs to be entered in the Resource and Type fields. However, it is recommended to leave this blank when first configuring DirectAccess. This is because the Remote Access Setup Wizard will automatically populate this field later. Specifying a resource during initial configuration will result in two entries being included, as shown here.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

As you can see, the Remote Access Setup wizard automatically added the resource directaccess-WebProbeHost.<internal domain.>. A corresponding DNS record is created that resolves this hostname to the internal IPv4 address of the DirectAccess server. In this configuration, the DirectAccess server itself serves as the corporate resource used by the NCA.

Multiple Corporate Resources

Having more than one resource to validate connectivity to the internal network is problematic though. If there are multiple entries specified, they must ALL pass a validation check from the client to report the connection status as “Connected”. Some administrators configure multiple entries with the mistaken belief that it will provide redundancy for the NCA, but it actually has the opposite effect. Having more than one entry only increases the chance of a false positive.

NCA Configuration Best Practices

It is recommended that only a single corporate resource URL be defined for the NCA. The default directaccess-WebProbeHost running on the DirectAccess server can be used, or, alternatively, another internal web server can be specified if desired. Any web server will work, including Microsoft Internet Information Services (IIS), Apache, NGINX, and most Application Delivery Controllers (ADCs) or load balancers. HTTPS is not required for the web probe host, only HTTP. If using an internal web server, ensure that it is highly available.

Do NOT use the Network Location Server (NLS) as a corporate resource! The NLS is exempted from the Name Resolution Policy Table (NRPT) on the client and is not reachable over DirectAccess. This will result in the NCA failing and reporting a “Connecting” status perpetually. In addition, avoid the use of PING for validating internal corporate resources. Ping uses ICMP which is inherently unreliable and commonly blocked by host and intermediary firewalls, making it an unreliable indicator of corporate network connectivity over DirectAccess.

Summary

The NCA is a crucial and often misunderstood component in the DirectAccess architecture. Follow the guidance outlined here to ensure that the NCA works reliably and effectively in your environment.

Additional Resources

DirectAccess Clients in Connecting State when using External Load Balancer
Planning and Implementing DirectAccess on Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 book

Leave a comment

23 Comments

  1. Steve F

     /  October 9, 2017

    THANK YOU! As always, a valuable resource for all things DirectAccess.

    Reply
  2. Nice Post about a network connectivity direct access guide.I learn much new stuff right here about network connectivity.it’s very helpful for me.

    Reply
  3. andozane

     /  February 6, 2020

    When we had support assist us with our DirectAccess Implementation (I would have called you first if I’d known of you then), they had us include a ping to our local domain. We have also the http://directaccess-WebProbeHost.domain and another IIS servers http address in our NCA as well.
    Your post alludes that the ping in there is NOT a good idea…
    I ask as I’ve seen some of our DA logs on clients not functioning and they show success on the two http addresses, but failing on the ping.

    Removing the ping should improve connectivity then, correct?

    Thanks again, your posts are so insightful.

    Reply
    • Correct. Using ICMP for the NCA probes should be avoided. Using HTTP is more reliable and effective.

      Reply
      • Nabokov

         /  March 30, 2020

        Hello
        After the connection is up, how often is the probe checking the nca? And whats the behavior if it cant reach it?

      • This check is only performed after a network interface status change. If there are no changes, then it doesn’t check again until there is.

  4. Nabokov

     /  March 30, 2020

    Ok, i thought i had a theory of why users are sometimes randomly disconnected and then connection are stuck in connecting (under high load of the DA server) and that was that the nca did not get answer fast enough.

    Reply
  5. Guillaume

     /  June 13, 2020

    Hello,
    We have a problem since the implementation of directaccess. client tries to log in but can’t get there. You will find more information in French the screenshots on the Microsoft forum that I opened. I don’t know if I forgot something? The client was reached by djoin is not on the corporate network.

    https://social.technet.microsoft.com/Forums/fr-FR/14595c53-9efe-469d-8468-147235bec632/directaccess-problme-de-connexion?forum=ws19fr

    On the server the email address of the helpdesk and the box Allow DirectAccess clients to use local name resolution is not registered and tick.

    Thank you for your help

    Reply
    • I’d have to assume you are missing some prerequisite. Certificates perhaps? Not sure. You can try running the DirectAccess diagnostic tool and see if that yields any clues.

      Reply
      • Guillaume

         /  June 14, 2020

        Hello,

        Thank you for your answer, thank you for pointing me to the check tool. This one stops here with its indications:

        [14.06.2020 11:06:29]: Running Inside/Outside location tests.
        [14.06.2020 11:06:29]: NLS is https://DirectAccess-NLS.admin.church:62000/insideoutside.
        [14.06.2020 11:06:29]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
        [14.06.2020 11:06:29]: NRPT contains 3 rules.
        [14.06.2020 11:06:29]: Found (unique) DNS server: fd90:ec2:b5e3:7777::ab1:10a
        [14.06.2020 11:06:29]: Send an ICMP message to check if the server is reachable.
        [14.06.2020 11:06:29]: DNS server fd90:ec2:b5e3:7777::ab1:10a is online, RTT is 106 msec.
        [14.06.2020 11:06:29]: Running IP connectivity tests.
        [14.06.2020 11:06:30]: Check not run yet.
        [14.06.2020 11:06:30]: Check not run yet.

        Here is the full message :

        [14.06.2020 11:18:59]: In worker thread, going to start the tests.
        [14.06.2020 11:18:59]: Running Network Interfaces tests.
        [14.06.2020 11:18:59]: Ethernet (Intel(R) Ethernet Connection (2) I219-LM): 2a02:120b:2c13:95c0:95c0:b5b8:7ff0:364e;: 2a02:120b:2c13:95c0:81f7:a245:bfda:fe38;: fe80::95c0:b5b8:7ff0:364e%6;: 192.168.1.113/255.255.255.0;
        [14.06.2020 11:18:59]: Multiple default gateways found for Ethernet!
        [14.06.2020 11:18:59]: Microsoft IP-HTTPS Platform Interface (Microsoft IP-HTTPS Platform Adapter): fd90:ec2:b5e3:1000:25ae:43f9:3321:4490;: fd90:ec2:b5e3:1000:edaf:6cf4:c71d:ed48;: fe80::25ae:43f9:3321:4490%4;
        [14.06.2020 11:18:59]: No default gateway found for Microsoft IP-HTTPS Platform Interface.
        [14.06.2020 11:18:59]: Warning – this client computer has multiple default gateways defined!
        [14.06.2020 11:18:59]: Ethernet has configured the default gateway fe80::1eb0:44ff:fe69:8830%6.
        [14.06.2020 11:18:59]: Default gateway fe80::1eb0:44ff:fe69:8830%6 for Ethernet replies on ICMP Echo requests, RTT is 1 msec.
        [14.06.2020 11:18:59]: Ethernet has configured the default gateway 192.168.1.1.
        [14.06.2020 11:18:59]: Default gateway 192.168.1.1 for Ethernet replies on ICMP Echo requests, RTT is 0 msec.
        [14.06.2020 11:18:59]: Received a response from the public DNS server (8.8.8.8), RTT is 6 msec.
        [14.06.2020 11:18:59]: Received a reply from the public DNS server (2001:4860:4860::8888), RTT is 9 msec.
        [14.06.2020 11:18:59]: Running Inside/Outside location tests.
        [14.06.2020 11:18:59]: NLS is https://DirectAccess-NLS.admin.church:62000/insideoutside.
        [14.06.2020 11:18:59]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
        [14.06.2020 11:18:59]: NRPT contains 3 rules.
        [14.06.2020 11:18:59]: Found (unique) DNS server: fd90:ec2:b5e3:7777::ab1:10a
        [14.06.2020 11:18:59]: Send an ICMP message to check if the server is reachable.
        [14.06.2020 11:18:59]: DNS server fd90:ec2:b5e3:7777::ab1:10a is online, RTT is 108 msec.
        [14.06.2020 11:18:59]: Running IP connectivity tests.
        [14.06.2020 11:18:59]: Check not run yet.
        [14.06.2020 11:18:59]: Check not run yet.

      • It would appear that the IPv6 transition technology is up as you can ping the DirectAccess server’s IPv6 address. Do you still not have access to on-premises resources?

  6. Guillaume

     /  June 18, 2020

    No, we still don’t have access to internal resources.When I ping the DC it gives me a public IPv4 address, not a local one.

    Reply
    • Ok, then it sounds like IPsec tunnels have not been established, which could mean any number of things. I’d have a close look at prerequisites (certificates, firewall on on servers and clients, etc.). Suspect something related to those.

      Reply
  7. Guillaume

     /  June 18, 2020

    The domain controller is not on the same server as direct access. Both servers are on Windows server 2019.

    Reply
  8. Do you know what the effect on the Remote Clients if the values for the nca resources are changed after da deployment? I need to tweak it but since everyone is remote I’m scared to death. I see these values are in the client gpo. Ugh.

    Reply
    • You can update NCA settings any time without affecting clients at all. NCA settings have no impact on DirectAccess connectivity. They are simply used by the client to validate the DirectAccess connection once it has been established.

      Reply
  9. Hi Richard,

    Direct VPN is connected when i am in internal network, but when i tried to connect from external(internet) it is not connecting… any reason?

    Reply
    • Not sure. Can you resolve the public FQDN to an IP address? Is it the correct one? Can you establish a TCP connection to that IP address?

      Reply
  10. Gagan Taneja

     /  May 21, 2021

    Hi Richard,

    I am using Direct Access from last Four years. Now we are facing issue in environment . We have two servers . One Site is SDC where i have 20 direct access servers and same on another site UDC where i have 20 servers . We are under one Load Balancer which is sending request to server. Now we are facing issues on client machines where machine shows in connecting state and after 10 min connection connected to another server and it shows DA connected . Kindly help.

    Reply
    • When the DirectAccess client shows “Connecting” can you access any internal resources at all?

      Reply
      • Gagan Taneja

         /  May 24, 2021

        No .We can not access anything on machine .

      • Ok. Does the client have a unicast IPv6 address assigned to the IP-HTTPS interface? If so, can you ping the DNS64 address? It’s the address ending in 3333::1.

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