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

18 Comments

  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): http://blog.forefront-tmg.de/?p=1044
    Greets, Karsten…

    Reply
  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 = 10.10.10.1
    DIP = 10.10.10.2
    DIP = 10.10.10.3

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

    [25.11.2014 16:45:49]: Failed to connect to endpoint https://testcompany.com:443.

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

    [telnet testcompany.com 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 10.10.10.1 , 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 10.10.10.1 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

    Reply
    • Creating the virtual server for 10.10.10.1 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.

      Reply
  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?

    Reply
    • 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.

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

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

    Reply
  6. uh – 2 many typos – sry…

    Reply
  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?

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

      Reply
      • 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?

    Reply
    • 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.

      Reply
  9. Max

     /  January 9, 2017

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

    Reply
  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

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: