DirectAccess Clients in Connecting State when using External Load Balancer

After configuring a Windows Server 2012/R2 DirectAccess server to use an external load balancer, the network connectivity status indicator on the DirectAccess client may perpetually indicate a connecting state.

DirectAccess Clients in Connecting State when using External Load Balancer

In addition, the Get-DAConnectionStatus PowerShell cmdlet returns the following error:

Status : Error
Substatus : RemoteNetworkAuthenticationFailure

DirectAccess Clients in Connecting State when using External Load Balancer

In spite of what the network connectivity status indicator reports, DirectAccess clients are connected and can successfully connect to corporate network resources via DirectAccess.

DirectAccess Clients in Connecting State when using External Load Balancer

To verify that resources on the corporate network are reachable after the DirectAccess session is established, a DirectAccess client makes an HTTP request to the host directaccess-WebProbeHost. This hostname resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. However, when an external load balancer is configured, the original dedicated IP address (DIP) of the first DirectAccess server becomes the new virtual IP address (VIP) of the cluster, which now resides on the load balancer. After configuring an external load balancer, the DNS record for directaccess-WebProbeHost now resolves to the virtual IP address (VIP) of the cluster, and if this VIP isn’t configured to deliver HTTP requests to the DirectAccess servers, the client-side connectivity check fails.

DirectAccess Clients in Connecting State when using External Load Balancer

To resolve this issue it is necessary to also create a virtual server on the load balancer with the internal IPv4 address that directaccess-WebProbeHost resolves to. The service port should be configured for HTTP (TCP port 80) and can use the same pool used by the external virtual server.

DirectAccess Clients in Connecting State when using External Load Balancer

Once this virtual server is configured, the network connectivity status indicator for DirectAccess will now accurately reflect that it is connected via DirectAccess.

DirectAccess Clients in Connecting State when using External Load Balancer

Leave a comment


  1. Hi Richard,
    got the same problem, but another cause. In my case the DNS-Scavenging deleted the webprobehost-entry in DNS. I wrote a little blog-article for this (in german):
    Greets, Karsten…

  2. Ferhat Aysever

     /  November 25, 2014

    Hello ,

    I wanna ask a question about your article . I have set up 2 Direct Access Server with single network adaptor. And the first direct access server’s ip address has become the VIP and i used it on F5 pool and added the DIPs of the 2 Direct Access Server.

    VIP =
    DIP =
    DIP =

    When i run the diagnostic tool i recive the following error.

    [25.11.2014 16:45:49]: Failed to connect to endpoint

    My public ip address NAT to (VIP) but when i telnet on 443 port its failing.

    [telnet 443 …. fails ]

    but its not failing when i NAT it to any direct access server ,it happens only on f5

    My directaccess-WebProbeHost in my internal dns resolve , is this right?

    (I have tested in standalone and all clients are able to connect without anny issue.)

    So do you think if i add as Virtual server on f5 on 80 port , would my problem be solved?

    Or am i missing someting bigger about 443 ?

    I know this is a long question and a little out of topic but i would appericate if you give me an answer !

    Thank you so much

    • Creating the virtual server for and updating the directaccess-WebProbeHost URL is definitely required, but I don’t think it will solve your problem. The F5 should be able to connect via HTTPS to the DirectAccess server without issue. I’d look closely at your F5 configuration…I suspect something is wrong there.

  3. Mark

     /  May 12, 2015

    I don’t have any DNS records beginning with directaccess-*. I believe my records were also scavenged. Once I added the host record back for “directaccess-WebProbeHost” all was well again. Now I’m wondering if I need to replace any of the other directaccess-* records manually… and would this be considered a bug?

    • Bug? Or feature? 😉 I’ve encountered this a few times recently. I would say that it is a good idea to make sure that all DirectAccess-related DNS entries are static just to avoid any potential issues in the future.

  4. I also got this serveral times – make ’em static!

  5. …and don’t Forget: directaccess-corpConnectivityHost (2 DNS-Entrys, one v4 $ on v6 loopback) + directaccess-WebProbeHost (1 for every EntryPoint)

  6. uh – 2 many typos – sry…

  7. Darmien

     /  April 13, 2016

    Hi Richard,

    Does all client traffic flow through the loadbalencers? or once the tunnel is established does traffic flow out to the DA servers default gateway?

    • All traffic for DirectAccess connections inbound and outbound flow through the load balancer.

      • Darmien

         /  April 18, 2016

        Am i right in thinking that the default gateway is used for sending unencrypted traffic to the internal resources the DA clienys are accessing? So encrypted traffic comes through the loadbalencers where its is then forwarded to the resource via the DA servers but does not passthrough the loadbalancers until the resource responds to the clients request?

      • Depends on your network configuration. Fundamentally all communication between the DirectAccess server and clients is encrypted, and all traffic between the DirectAccess server is unencrypted (by default). The load balalncers only handle transition tunnel traffic (IP-HTTPS) for which the payload is the IPsec payload from clients.

  8. Alan Dooley

     /  May 19, 2016

    When my clients connect (all 8.1 or above) using IPHTTPS I always get a RemoteNetworkAuthenticationFailure error initially then it seems to retry and connects. Is this normal?

    • Definitely not normal. However, if you check the state of the IP-HTTPS tunnel adapter immediately after a network status change, it is possible that you can get this message. It can happen because it takes a period of time before the IP-HTTPS tunnel is fully established. It doesn’t happen instantly for sure.

  9. Max

     /  January 9, 2017

    Just came across this exact issue. Had it fixed in 10 mins because of this article. Many thanks!

  10. Vas

     /  October 24, 2018

    Hi Richard,

    I have currently setup a Direct Access 2016 environment in parallel with our prod environment with an F5 external load balancer for the load balance cluster (two servers).

    When testing it appears that i am getting successful connectivity on one of the servers (Server B) with out fail and i am not getting connectivity on the other server (Server A). This is always consistent between the two servers.

    The client machine is always stuck on “connecting” when making a connection through Server A however when connecting through Server B it connects with out any issues.

    Any advice on where to look?

    • I would first ensure that when you connect to the server that is failing that you do or do not have a DirectAccess connection. When connected, can you resolve internal hostnames? Can you connect to internal resources. If not, you’ll need to resolve that issue first. That will most likely resolve your “connecting” message too.

  1. DirectAccess DNS Records Explained | Richard Hicks' DirectAccess Blog
  2. DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance | 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