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.
In addition, the Get-DAConnectionStatus PowerShell cmdlet returns the following error:
Status : Error Substatus : RemoteNetworkAuthenticationFailure
In spite of what the network connectivity status indicator reports, DirectAccess clients are connected and can successfully connect to corporate network resources via DirectAccess.
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.
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.
Once this virtual server is configured, the network connectivity status indicator for DirectAccess will now accurately reflect that it is connected via DirectAccess.
Karsten Hentrup
/ August 20, 2014Hi 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…
Richard Hicks
/ August 21, 2014Thanks for the tip. That would definitely cause the problem too!
Ferhat Aysever
/ November 25, 2014Hello ,
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
Richard Hicks
/ December 3, 2014Creating 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.
Mark
/ May 12, 2015I 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?
Richard Hicks
/ May 12, 2015Bug? 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.
Karsten Hentrup
/ May 15, 2015I also got this serveral times – make ’em static!
😉
Karsten Hentrup
/ May 15, 2015…and don’t Forget: directaccess-corpConnectivityHost (2 DNS-Entrys, one v4 $ on v6 loopback) + directaccess-WebProbeHost (1 for every EntryPoint)
Karsten Hentrup
/ May 15, 2015uh – 2 many typos – sry…
Darmien
/ April 13, 2016Hi 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?
Richard M. Hicks
/ April 13, 2016All traffic for DirectAccess connections inbound and outbound flow through the load balancer.
Darmien
/ April 18, 2016Am 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?
Richard M. Hicks
/ April 23, 2016Depends 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.
Alan Dooley
/ May 19, 2016When 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?
Richard M. Hicks
/ May 19, 2016Definitely 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.
Max
/ January 9, 2017Just came across this exact issue. Had it fixed in 10 mins because of this article. Many thanks!
Vas
/ October 24, 2018Hi 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?
Richard M. Hicks
/ October 29, 2018I 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.