DirectAccess, Force Tunneling and a Corporate Proxy

Although perhaps not strictly a management topic, this issue arose on a recent enterprise mobility project involving Intune for Windows Mobile and DA for corporate laptops.  It’s been going on a long time and it’s still not fixed, suffice to say that this is not a happy combination of technologies.

Firstly some terminology…

NCSI - Network Connectivity Status Indicator

clip_image001

This is the thing that determines whether or not you have internet access. This is done using a combination of DNS and HTTP probes. These probes can not only work out if you are internet connected, but can determine if you have IPv4 or native IPv6 internet access. It can also detect whether you are behind a captive portal, e.g. a public WiFi hotspot requiring authentication. It comes to this outcome if the HTTP probe fails but the DNS probe succeeds.

NCSI is called by the Network Location Awareness service whenever an interface change is detected.

Probe Type Query Expected Result
HTTP IPv4 http://www.msftncsi.com/ncsi.txt Microsoft NCSI
HTTP IPv6 http://www.msftncsi.com/ncsi.txt Microsoft NCSI
DNS IPv4 dns.msftncsi.com (A) 131.107.255.255
DNS IPv6 dns.msftncsi.com (AAAA) fd3e:4f5a:5b81::1

And here is the configuration in the registry…

clip_image002

 
Here’s the thing…

For Windows 8 modern apps, this is a critical indicator. If this does not show as 'Connected/Internet Access' then modern apps will often enter an offline mode, even if there is actually internet connectivity!

For Win32 apps, the effect is less profound. However, if you have got internet access and Windows says that you don't then it's not a fantastic user experience and can lead to unnecessary helpdesk calls.

Scenario

Here is a simplified diagram of the solution:

clip_image003

Key elements are:

  • All internet traffic must pass through the web filtering proxy server
  • Force tunnel must be used (this was for a UK Central Government dept.)
  • IP-HTTPS only
  • Windows 8.1 touchscreen laptop/tablet hybrid devices using Windows Modern Apps

Issue 1

At first the connection was very unreliable. The DA connection would sometimes come up OK, and sometimes not. Very odd… So, a premier support call was in order.

It turns out that there are several undocumented changes that must be made to the DA server in this scenario. Thanks MSFT!

In order to hopefully help others, here they are:

  • Configure a proxy for the “.” rule in the DA client policy (instead of just in IE)
  • Create a host file entry for dns.msftncsi.com on the DA server pointing to fd3e:4f5a:5b81::1
  • Make sure that the DA server is set to resolve both IPv4 and IPv6 records for client requests:

Set-NetDnsTransitionConfiguration –OnlySendAQuery $False

  • Point the DA server to itself for IPV6 name resolution: In the IPv6 properties set the primary DNS server to ::1
  • Enable Advertise Default Route on the Iphttps interface:

netsh interface ipv6 set interface <Interface_id> advertisedefaultroute=en

Note: The interface id for IPhttps interface can be obtained from the command: netsh int ipv6 show int

This made the DA tunnel a lot better, but NCSI was still failing and stating that there was no internet access, even though we can browse the internet just fine.

Issue 2

NCSI is regularly reporting no internet access.

After lots more investigation, it was suggested to disable DNS negative caching on the DA clients.  This was due to a timing issue whereby the IpHttpsInterface would be brought up, but the DA security associations were not established.  So, NCSI would ask for www.msftncsi.com and get no response. It would then cache the negative response and break NCSI.

Here's the registry key to effect this change:

HLKM\CurrentControlSet\Services\DNSCache
MaxNegativeCacheTtl = (DWORD) 0

This helped a lot, but the issue still remained, this is when we discovered another nugget…

The IpHttpsInterface on the client is assigned an address in the fd00/8 IPv6 space, this is defined as a private address space and, as such, NCSI doesn't then check for internet access.  Because there is no NAT in IPv6, this assumption is technically correct and there shouldn't be any internet access; all IPv6 addresses should be internet routable.  However, clearly in this use case something should step in and initiate the NCSI probes.

Wrap up

At this juncture the issue still remains and has been on-going for nearly 6 months with MSFT support.  I recently met up with an ex-colleague of mine that now works for MCS in the UK and specialises in this sort of thing.  He said that MCS does not generally implement DA in force tunnel mode as there are a litany of problems with it. Instead they look to use split tunnel, with additional client hardening (firewall rules, etc.) to prevent direct internet connectivity.

Lastly, did you know that if the DA server is down, or unreachable, then the client will gain full IPv4 internet access?  Now, with a little knowledge of DNS this is very easy to defeat.

There are some good articles on how to challenge the perceived security benefits of force tunneling over split tunneling.  This one sums it up nicely: http://blogs.technet.com/b/tomshinder/archive/2010/03/30/more-on-directaccess-split-tunneling-and-force-tunneling.aspx *

* With Windows Server 2012, IP-HTTPS is no longer a terrible choice. It now uses NULL encryption instead of re-encrypting the DA security tunnels. It can also easily be load balanced and supports NAT, unlike Teredo. The rest of the article still stands.