DirectAccess Status Refresh

Hi All

I have a customer who is using DirectAccess for their mobile workforce to connect back to the enterprise infrastructure.  They complain that it takes a long time to connect.  I've been doing some tests and after waking up a device, it can take 45-60 seconds for the mobile network to connect, then it can take anywhere from 20secs to 180secs for DirectAccess to show as connected.  However, if I have a ping running to a server on the internal enterprise network, that ping starts working 20-22secs after the mobile network is up.  Every single time. 

This has me wondering, is the sometimes long delay with the DirectAccess showing up as connected in the GUI just a GUI refresh or GUI event issue and the actual DA connection is coming up consistently at 20 seconds?  In the GUI I'm talking about the DirectAccess status when you go into Settings/Network.

DA is not my area of expertise, but it is part of a broader review of a W8.1 environment I'm doing for a customer.

Thanks in advance.

February 4th, 2015 9:01pm

Thanks for the information, I've seen both of these and neither goes to my question as far as I can tell.  Teredo and 6to4 are disabled, and the problem isn't logons, they are slow, but I don't think DA is the problem, I think its bad GPO design, we see it on the LAN also and I'm addressing that.  The problem I explain above can happen at any time, not just longon.  When waking from suspend we see this.  When the device jumps to a new cell tower we can see the issue, the network drops for a moment, then DA has to reconnect; a carrier issue we are also working on.  The carrier also seems to have ideal time timeouts that we are trying to understand, and we will see the issue when reconnecting after ideal time also.  We get it when a user walks out of WiFi range and the mobile network takes over; DA drops and reconnects, and we can get these long delays if watching the DA status in the GUI, but the ping is rock solid in coming back after 20 seconds of the network being up.

I'll try and rephrase my questions:

1.  Is the PING I explain above an accurate/reliable indicator that the DA tunnel is up?

2.  If it is, why does the DA status in the GUI sometimes take a long time to refresh? (It is inconsistent)

3.  Could the issue be a GUI refresh or GUI event issue and not a problem with DA?

4.  If the PING is not a good way to tell if the tunnels are up, what should I be doing to reliably tell if the DA tunnels are up

Thanks in advance.

February 6th, 2015 8:53am

Whether or not DirectAccess shows as "connected" in Windows is a simple probe query, and doesn't necessarily have anything to do with whether or not DA is actually connected. On your DirectAccess server, open up the configuration and go into the settings inside Step 1. The page about NCA - Network Connectivity Assistant - these are the settings that matter for that probe. Whatever you have defined here is what is being queried by that NCA tool (the one that shows you "connected" or "connecting"). NCA won't show connected until it can validate connectivity to all of the probes listed here, so it's usually a good idea to keep it as a relatively short list, most of my customers have just one entry in here.

So based on that, your NCA not showing up as connected for a while doesn't make any bit of difference to the actual connection, your DA tunnels might be online just fine well before it shows "connected". But, pings are not a good way to validate that the tunnels are fully online. DirectAccess is a combination of IPsec tunnels that are running inside an IPv6 transition tunnel, like Teredo or IP-HTTPS. When you RDP or file access or anything else to a server via DirectAccess, that traffic always flows inside the IPsec tunnels, and this is a valid test that the tunnels are online. So an HTTP probe in the NCA properties will be a good determination that yes, everything with the IPsec tunnels is fully online. But ICMP traffic (pings) move outside of IPsec. Inside the transition tunnel, but outside of the IPsec encrypted tunnel. Most of the time, as soon as you can ping internal servers, DA is fully functional. But there is a possible situation where you would be able to successfully ping, and yet the IPsec tunnels may not actually be built, which would cause application traffic to fail.

To sum it all up - having one HTTP probe inside the NCA properties is the best way to keep from false negatives, whlie at the same time maintaining a 100% accurate description of the fully "connected" status. Oh, and yes sometimes NCA can be a little slow to status update, it's not very often that users are sitting there on that purple screen waiting for it to say connected - most users don't even know that it exists in there. :)

  • Marked as answer by jsc.19 12 hours 49 minutes ago
Free Windows Admin Tool Kit Click here and download it now
February 27th, 2015 9:35am

Many many thanks!  That all makes good sense to me a few things have just fallen into place that I wasn't understanding.  Great answer!

February 27th, 2015 5:38pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics