DirectAccess IP-HTTPS Performance Issues

DirectAccess IP-HTTPS Performance IssuesPerformance issues with DirectAccess are not uncommon. In fact, there are numerous threads on Microsoft and third-party forums where administrators frequently complain about slow download speeds, especially when using the IP-HTTPS IPv6 transition technology. Based on my experience the problem does not appear to be widespread but occurs with enough regularity that it is worthy of further investigation.

DirectAccess Design

The inherent design of DirectAccess is a major limiting factor for performance. DirectAccess uses a complex and heavy communication channel, with multiple layers of encapsulation, encryption, and translation. Fundamentally it is IPsec encrypted IPv6 traffic, encapsulated in HTTP, and then encrypted with Transport Layer Security (TLS) and routed over IPv4. It is then decrypted, decapsulated, decrypted again, then converted back to IPv4. The high protocol overhead incurred with multiple layers of encapsulation, encryption, and translation result in increased packet fragmentation, which further reduces performance.

DirectAccess Performance

Even under the best circumstances, DirectAccess performance is limited by many other factors, most notably the quality of the network connection between the client and the server. DirectAccess performs reasonably well over high bandwidth, low latency connections. However, network performance drops precipitously as latency increases and packet loss is encountered. This is to be expected given the design of the solution.

Intermediary Devices

It is not uncommon to find intermediary devices like firewalls, intrusion detection systems, malware scanners, and other security inspection devices limit the performance of DirectAccess clients. In addition, many security appliances have bandwidth caps enforced in software for licensing restrictions. Further, incorrect configuration of inline edge devices can contribute to increased fragmentation, which leads to poor performance as well.

Slow Downloads over IP-HTTPS

Many people report that download speeds seem to be artificially capped at 355Kbps. While this seems to be a display bug in the UI, there is plenty of evidence to indicate that, in some scenarios, DirectAccess is incapable of high throughput even over high-quality connections. Some who have deployed DirectAccess and VPN on the same server have reported that download speeds are only limited when using DirectAccess over IP-HTTPS and not with VPN using Secure Socket Tunneling Protocol (SSTP), which also uses TLS. This has led many to speculate that the issue is either a bug or a design flaw in the IP-HTTPS tunnel interface itself.

TCP Window Scaling Issues

In some of the network traces I’ve analyzed I’ve seen evidence that seems to support this theory. For example, a network trace taken when downloading a file over DirectAccess with IP-HTTPS showed the TCP window never scaled beyond 64K, which would seriously impede performance. Interestingly this doesn’t seem to happy when the client uploads files over IP-HTTPS. Clearly something unusual is happening.

Microsoft KB Article

Microsoft recently released a vaguely-worded KB article that appears to lend credence to some of these findings. The article seems to acknowledge the fact there are known issues with DirectAccess performance, but it lacks any specific details as to what the root cause is. Instead, it simply advises migrating to Windows 10 Always On VPN.

Summary

DirectAccess IP-HTTPS performance issues don’t appear to affect everyone, and the problem only seems to apply to file downloads and not to other types of traffic. However, there is mounting evidence of a systemic issue with DirectAccess performance especially over IP-HTTPS. Customers are advised to closely evaluate their uses cases for DirectAccess and if remote clients are frequently required to download large files over a DirectAccess connection, an alternative method of file transfer might be required. Optionally customers can consider evaluating alternative remote access solutions that offer better performance such as Windows 10 Always On VPN or third-party solutions such as NetMotion Mobility.

Additional Resources

Always On VPN and the Future of DirectAccess

What’s the Difference Between DirectAccess and Always On VPN?

NetMotion Mobility as an Alternative to Microsoft DirectAccess

DirectAccess IP-HTTPS Null Cipher Suites Not Available

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableMicrosoft first introduced support for null cipher suites for the IP-HTTPS IPv6 transition technology in Windows Server 2012, and it is supported for DirectAccess in Windows 8.x and Windows 10 clients. Using null cipher suites for IP-HTTPS eliminates the needless double encryption that occurs when using encrypted cipher suites. DirectAccess is a unique workload where SSL/TLS encryption isn’t really required because the payload being transported in HTTPS is already encrypted.

No Encryption by Design

When supporting Windows 8.x and Windows 10 clients, ensuring null cipher suites (TLS_RSA_WITH_NULL_SHA and TLS_RSA_WITH_NULL_SHA256) are enabled and operational is crucial to providing the highest levels of performance and scalability for the remote access solution. When following implementation best practices, this isn’t really an issue. However, in some cases null cipher suites may be disabled. This will result in reduced scalability and degraded performance for Windows 8.x and Windows 10 clients.

Validating SSL/TLS Configuration

The easiest way to verify that null cipher suites are being offered by the DirectAccess server is to use the Qualys SSL Labs server test site. Ideally you should see a result similar to this.

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableFigure 1. Qualys SSL Labs server test site results for properly configured DirectAccess server.

Don’t be alarmed by the overall rating “F”. That happens because the Qualys test site is designed to test web servers where using null cipher suites would be a serious security issue. As I stated previously, the DirectAccess workload is unique in that its HTTPS payload is already encrypted, so using null cipher suites is acceptable in this scenario.

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableFigure 2. Qualys SSL Labs server test site results for properly configured DirectAccess server showing support for null SSL/TLS cipher suites.

Null Cipher Suites Missing

When performing the Qualys SSL labs server test on a DirectAccess server, an overall rating of “A” is not desirable and indicates the DirectAccess server is misconfigured. This is caused by the lack of support for null cipher suites.

DirectAccess IP-HTTPS Null Cipher Suites Not AvailableFigure 3. Qualys SSL Labs server test site results for misconfigured DirectAccess server.

Common Causes

Null cipher suites for SSL and TLS can be disabled for a variety of reasons. Below are some of the most common causes for the lack of support for null cipher suites for DirectAccess.

Self-Signed Certificates – Using the Getting Started Wizard (simplified deployment) will configure DirectAccess using a self-signed certificate for IP-HTTPS. Using a self-signed certificate is discouraged for numerous reasons, most importantly because it disables support for null cipher suites.

Security Hardening – Security administrators may proactively disable support for null cipher suites in a misguided effort to “improve security” for DirectAccess. While this is acceptable and recommended on a web server, it is not advisable to disable null cipher suites on a DirectAccess server.

SSL Certificate Signing Algorithm – Using an SSL certificate signed with an Elliptical Curve (EC) key as opposed to an RSA key will result in the loss of support for null cipher suites for IP-HTTPS. High security/assurance certificates signed with EC keys are not recommended for use on DirectAccess servers and should be avoided if possible.

DirectAccess Configuration Options – Enabling One-Time Password (OTP) authentication on the DirectAccess server will also result in a loss of support for null cipher suites. Also, adding additional roles to the DirectAccess server such as client-based VPN or the Web Application Proxy (WAP) can also result in null cipher suites being disabled.

Summary

Null cipher suites are implemented by design on DirectAccess servers to enhance performance for Windows 8.x and Windows 10 clients and improve overall scalability for the implementation. They eliminate the pointless double encryption of DirectAccess communication, which itself is already encrypted. For optimal performance and scalability, be sure to follow implementation best practices and use a PKI-managed (public or private) SSL certificate signed with an RSA key (SHA-256 recommended). Resist the urge to “harden” the DirectAccess server by disabling support for null cipher suites, and avoid the use of SSL certificates signed with EC keys. In addition, carefully consider DirectAccess deployment options such as OTP authentication and consider deploying roles such as VPN and WAP on a separate server.

Additional Information

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

DirectAccess IP-HTTPS Null Encryption and SSTP VPN

DirectAccess and FIPS Compliant Algorithms for Encryption

SSL Certificate Considerations for DirectAccess IP-HTTPS 

 

 

DirectAccess and FIPS Compliant Algorithms for Encryption

DirectAccess administrators may be required to enable Federal Information Processing Standards (FIPS) compliant algorithms for encryption, hashing, and signing on DirectAccess servers to meet certain regulatory and compliance requirements.

DirectAccess and FIPS Compliant Algorithms for Encryption

Performance Impact

Be advised that enabling this setting will disable support for null cipher suites for the IP-HTTPS IPv6 transition technology. This will result in the double encryption of all DirectAccess client communication, which will increase resource consumption on DirectAccess servers. This leads to reduced scalability and degraded performance for all DirectAccess clients, including Windows 8.x and Windows 10.

If enabling FIPS compliant cannot be avoided, additional compute capacity (CPU and memory) should be provisioned. For best results, add additional servers to distribute the workload and improve performance for DirectAccess clients.

Always On VPN

If you’re looking for better security and performance, consider migrating to Windows 10 Always On VPN. Always On VPN fully supports FIPS compliant algorithms without the negative performance impact associated with DirectAccess. If you’d like to learn more about security and Always On VPN, fill out the form below and I’ll get in touch with you.

Additional Resources

Always On VPN and the Future of DirectAccess 

5 Things DirectAccess Administrators Should Know About Always On VPN 

3 Important Advantages of Always On VPN over DirectAccess 

SSL Certificate Considerations for DirectAccess IP-HTTPS

SSL Certificate Considerations for DirectAccess IP-HTTPSDirectAccess uses IPv6 exclusively for communication between the client and server. IPv6 transition technologies are used to support DirectAccess communication over the IPv4 public Internet. One of those IPv6 transition technologies, IP-HTTPS, uses HTTP for encapsulation and SSL/TLS for authentication of the DirectAccess server.

SSL Certificates

When configuring DirectAccess, an SSL certificate must be provided for IP-HTTPS. There are three different types of SSL certificates that can be used.

Public SSL Certificate – Using an SSL certificate signed by a public certification authority (CA) is the recommended best practice for configuring DirectAccess IP-HTTPS. This provides the highest level of assurance for DirectAccess clients connecting via IP-HTTPS.

Private SSL Certificate – Using an SSL certificate issued by the organization’s internal CA is an acceptable alternative to using a public SSL certificate in most cases. This can reduce the cost associated with obtaining the certificate, especially for multisite deployments.

Self-Signed Certificate – Using a self-signed certificate is not recommended and should be avoided in most deployment scenarios. A self-signed certificate provides no real assurance for DirectAccess clients. Crucially, using a self-signed certificate will disable support for null SSL and TLS cipher suites. This reduces the overall scalability and performance of the remote access solution.

SSL Certificate Considerations for DirectAccess IP-HTTPS

Figure 1. Null cipher suites not supported when using a self-signed SSL certificate for IP-HTTPS.

Certificate Requirements

The SSL certificate must include the Server Authentication (1.3.6.1.5.5.7.3.1) Enhanced Key Usage (EKU) Object Identifier (OID). It should use an RSA key of 2048 bits and be signed with SHA256. Using stronger keys provides no additional protection and should not be used. In addition, SSL certificates using ECDSA keys is not recommended, as they do not support null cipher suites.

Summary

In most cases, using a public SSL certificate is ideal. However, issuing a certificate from a private CA is also acceptable. Using self-signed certificates can be used for non-production testing and in very small production deployments, but should generally be avoided.

Additional Resources

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

DirectAccess and NetMotion Mobility Webinar

Update: You can view the on-demand recording of this webinar here.

DirectAccess on Windows Server 2016 CoreFor many years, DirectAccess has been the gold standard for enterprise remote access. Its seamless and transparent operation improves productivity for mobile workers, and since it is always on, administrators enjoy improved visibility and management for their field-based assets.

As incredible as DirectAccess is, it is not without its limitations. For example, DirectAccess works only with Windows Enterprise edition clients that are joined to the domain. Professional Edition and non-domain joined machines are not supported. It also lacks many of the security features enterprise organizations require, such as device health checks and granular network access. In addition, DirectAccess communication is complex, with many different layers of encapsulation, authentication, and encryption. High protocol overhead can lead to poor performance over high latency or low bandwidth connections.

NetMotion Mobility as an Alternative to DirectAccessNetMotion Mobility is a secure remote access solution that is an excellent alternative to DirectAccess. It provides the same seamless, transparent, always on remote connectivity that DirectAccess provides, while at the same time offering much more in terms of features and capabilities. It supports a much broader range of clients, includes native Network Access Control (NAC) and application filtering, and offers enhanced performance.

To learn more about NetMotion Mobility, join me on Wednesday, September 20 at 10:00AM PDT for a free live webinar with NetMotion. I’ll provide an overview of NetMotion Mobility and how it compares with DirectAccess. I’ll also demonstrate how it can help overcome some of the inherent limitations of DirectAccess too. Register today!

DirectAccess and NetMotion Mobility Webinar

DirectAccess Force Tunneling and Proxy Server Configuration

By default, DirectAccess is configured to use split tunneling. In this scenario, a remote DirectAccess client is connected to the internal corporate network and the public Internet at the same time. Some security administrators perceive split tunneling as a security risk, and the use of split tunneling may be prohibited by corporate security policy. In addition, enforcing web browsing policies on remote DirectAccess clients might be desired to reduce the risk of exposure from browsing unapproved web sites. In either case, force tunneling can be configured to meet these requirements.

When force tunneling is enabled, DirectAccess administrators can also define an on-premises proxy server for DirectAccess clients to use. The following is guidance for enabling force tunneling and configuring DirectAccess clients to use a proxy server to access the Internet.

Enabling Force Tunneling

To enable force tunneling, open the Remote Access Management console and perform the following steps.

  1. Expand Configuration and select DirectAccess and VPN.
  2. Click Edit on Step 1 Remote Clients.
  3. Click Select Groups in the navigation tree.
  4. Select the option to Use force tunneling.

DirectAccess Force Tunneling and Proxy Server ConfigurationFigure 1. Enable DirectAccess force tunneling in the Remote Access Management console.

Alternatively, force tunneling can quickly be enabled by opening an elevated PowerShell command window and running the following command.

Set-DAClient -ForceTunnel Enabled -PassThru

DirectAccess Force Tunneling and Proxy Server ConfigurationFigure 2. Enable DirectAccess force tunneling using PowerShell.

Configure a Proxy Server

Once force tunneling has been enabled, run the following PowerShell script to configure an on-premises proxy server for DirectAccess clients to use. Be sure to substitute the fully-qualified domain name (FQDN) and port for your proxy server in the $proxy variable below.

$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]

$proxy = “proxy.corp.example.net:8080”

$rule = (Get-DnsClientNrptRule -GpoName $gpo | Where-Object Namespace -eq “.” | Select-Object -ExpandProperty “Name”)

Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $rule -GpoName $gpo

If multisite is enabled and Windows 7 clients are supported, run the following PowerShell script on one DirectAccess server in each entry point.

$downlevelgpo = (Get-RemoteAccess).DownlevelGpoName
$downlevelgpo = $downlevelgpo.Split(‘\’)[1]

$proxy = “proxy.corp.example.net:8080”

$downlevelrule = (Get-DnsClientNrptRule -GpoName $downlevelgpo | Where-Object Namespace -eq “.” | Select-Object -ExpandProperty “Name”)

Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $downlevelrule -GpoName $downlevelgpo

Remove Proxy Server

Run the following PowerShell script to remove the proxy server, if necessary.

$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]

Set-DnsClientNrptRule -DAEnable $true -DAProxyType “UseDefault” -Name $rule -GpoName $gpo

$downlevelgpo = (Get-RemoteAccess).DownlevelGpoName
$downlevelgpo = $downlevelgpo.Split(‘\’)[1]

Set-DnsClientNrptRule -DAEnable $true -DAProxyType “UseDefault” -Name $downlevelrule -GpoName $downlevelgpo

Disable Force Tunneling

To disable force tunneling completely, run the following PowerShell command.

Set-DAClient -ForceTunnel Disabled -PassThru

Force Tunneling Caveats

When force tunneling is enabled, the user experience is typically poor when accessing the Internet. Web browsing performance is significantly reduced because of the added protocol overhead imposed by DirectAccess IPv6 transition technologies and IPsec encryption. This problem is further compounded when users access resources that are already encrypted, such as secure web sites. Increased packet fragmentation, along with the additional network latency caused by suboptimal network paths and increased network load on the server and Internet connection all contribute to degraded network performance for DirectAccess clients.

Force Tunneling Alternatives

Instead of enabling force tunneling, consider alternative solutions to address the security concerns associated with split tunneling. For example, implement technologies that enforce web browsing policies on the client. Many secure web gateways and next-generation firewalls (NGFW) have remote filtering capabilities that allow administrators to enforce web browsing policies on remote client machines. In addition, there are some excellent cloud-based solutions such as Zscaler and OpenDNS that can protect DirectAccess clients without the drawbacks associated with force tunneling.

Additional Information

Planning and Implementing DirectAccess with Windows Server 2016 video training course on Pluralsight
Managing and Supporting DirectAccess with Windows Server 2016 video training course on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book

Always On VPN and the Future of Microsoft DirectAccess

Windows 10 Always On VPN hands-on training classes now forming. Details here.

Since the introduction of Windows Server 2012 in September of 2012, no new features or functionality have been added to DirectAccess. In Windows Server 2016, the only real change aside from bug fixes for DirectAccess is the removal of Network Access Protection (NAP) integration support.

Always On VPN and the Future of Microsoft DirectAccessFigure 1. Remote Access Setup wizard with NAP integration option in Windows Server 2012/R2.

Always On VPN and the Future of Microsoft DirectAccess

Figure 2. Remote Access Setup wizard without NAP integration option in Windows Server 2016.

DirectAccess Roadmap

It’s clear to see that Microsoft is no longer investing in DirectAccess, and in fact their field sales teams have been communicating this to customers for quite some time now. Microsoft has been actively encouraging organizations who are considering a DirectAccess solution to instead implement client-based VPN with Windows 10.

Always On VPN

New features introduced in the Windows 10 Anniversary Update allow IT administrators to configure automatic VPN connection profiles. This Always On VPN connection provides a DirectAccess-like experience using traditional remote access VPN protocols such as IKEv2, SSTP, and L2TP/IPsec. It comes with some additional benefits as well.

  • Conditional access and device compliance with system health checks
  • Windows Hello for Business and Azure multifactor authentication
  • Windows Information Protection (WIP) integration
  • Traffic filters to restrict VPN network access
  • Application-trigger VPN connections

DirectAccess Deprecated?

There has been rampant speculation that Microsoft plans to deprecate and retire DirectAccess. While that may in fact be true, Microsoft has yet to make a formal end-of-life announcement. There’s no reason DirectAccess and VPN couldn’t co-exist, so it’s not a certainty Microsoft will do this. However, there’s also no need to have multiple remote access solutions, and it is abundantly clear that the future for Microsoft remote access is Always On VPN and not DirectAccess.

Always On VPN and the Future of Microsoft DirectAccess

Source: https://social.technet.microsoft.com/wiki/contents/articles/38546.new-features-for-vpn-in-windows-10-and-windows-server-2016.aspx#Advanced_VPN_Connectivity

Always On VPN Advantages and Disadvantages

Windows 10 Always On VPN has some important advantages over DirectAccess. It has some crucial limitations as well.

Advantages

  • Always On VPN supports non-Enterprise Windows 10 client SKUs (Windows 10 Home and Professional)
  • Always On VPN includes support for granular network access control
  • Always On VPN can use both IPv4 and IPv6
  • Always On VPN is infrastructure independent. In addition to supporting Windows RRAS, any third-party network device can be used such as Cisco, Checkpoint, Juniper, Palo Alto, SonicWALL, Fortinet, Sophos, and many more

Disadvantages

  • Always On VPN works only with Windows 10. It is not supported for Windows 7
  • Always On VPN cannot be managed natively using Active Directory and group policy. It must be configured and managed using Microsoft System Center Configuration Manager (SCCM), Microsoft Intune, or PowerShell

DirectAccess or Always On VPN?

Should you deploy DirectAccess today or implement Always On VPN with Windows 10 instead? That depends on a number of factors. It’s important to understand that DirectAccess is fully supported in Windows Server 2016 and will likely be for many years to come. If DirectAccess meets your needs today, you can deploy it with confidence that it will still have a long support life. If you have reservations about the future viability of DirectAccess, and if you meet all of the requirements to support Always On VPN with Windows 10, then perhaps that’s a better choice. If you’d like to discuss your remote access options in more detail, fill out the form below and I’ll get in touch with you.

Additional Resources

5 Things DirectAccess Administrators Should Know About Always On VPN

3 Important Advantages of Always On VPN over DirectAccess

NetMotion Mobility as an Alternative to DirectAccess

Windows 10 Always On VPN Hands-On Training Classes

DirectAccess Reporting Fails and Schannel Event ID 36871 after Disabling TLS 1.0

IMPORTANT NOTE: The guidance in this post will disable support for null SSL/TLS cipher suites on the DirectAccess server. This will result in reduced scalability and performance for all clients, including Windows 8.x and Windows 10. It is recommended that TLS 1.0 not be disabled on the DirectAccess server if at all possible.

When performing security hardening on the DirectAccess server it is not uncommon to disable weak cipher suites or insecure protocols such as SSL 3.0 and TLS 1.0. However, after disabling SSL 3.0 and TLS 1.0 you will find that it is no longer possible generate reports. Clicking the Generate Report link in the Remote Access Management console returns no data.

DirectAccess Reporting Fails after Disabling TLS 1.0

In addition, the System event log indicates Schannel errors with Event ID 36871. The error message states that “A fatal error occurred while creating a TLS client credential. The internal error state is 10013.”

DirectAccess Reporting Fails after Disabling TLS 1.0

To resolve this issue and restore DirectAccess reporting functionality you must enable the use of FIPS compliant encryption algorithms on the DirectAccess server. This change can be made locally or via Active Directory group policy. Open the Group Policy Management Console (gpmc.msc) for Active Directory GPO, or the Local Group Policy Editor (gpedit.msc) on the DirectAccess server and navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing and select Enabled.

DirectAccess Reporting Fails after Disabling TLS 1.0

If using Active Directory GPO, ensure that the GPO is applied all DirectAccess servers in the organization. A restart is not required for this setting to take effect. Once this change has been made, reporting should work as expected.

Additional Resources

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites
DirectAccess Video Training Courses on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book on Amazon.com

DirectAccess Manage Out and System Center Configuration Manager (SCCM)

The seamless and transparent nature of DirectAccess makes it wonderfully easy to use. In most cases, it requires no user interaction at all to access internal corporate resources while away from the office. This enables users to be more productive. At the same time, it offers important connectivity benefits for IT administrators and systems management engineers as well.

Always Managed

DirectAccess Manage Out and System Center Configuration Manager (SCCM)DirectAccess clients are automatically connected to the corporate network any time they have a working Internet connection. Having consistent corporate network connectivity means they receive Active Directory group policy updates on a regular basis, just as on-premises systems do. Importantly, they check in with internal management systems such as System Center Configuration Manager (SCCM) and Windows Server Update Services (WSUS) servers, enabling them to receive updates in a timely manner. Thus, DirectAccess clients are better managed, allowing administrators to more effectively maintain the configuration state and security posture for all their managed systems, including those that are predominantly field-based. This is especially crucial considering the prevalence WannaCry, Cryptolocker, and a variety of other types of ransomware.

DirectAccess Manage Out

DirectAccess Manage Out and System Center Configuration Manager (SCCM)When manage out is configured with DirectAccess, hosts on the internal network can initiate connections outbound to remote connected DirectAccess clients. SCCM Remote Control and Remote Desktop Connection (RDC) are commonly used to remotely connect to systems for troubleshooting and support. With DirectAccess manage out enabled, these and other popular administrative tools such as VNC, Windows Remote Assistance, and PowerShell remoting can also be used to manage remote DirectAccess clients in the field. In addition, enabling manage out allows for the proactive installation of agents and other software on remote clients, such as the SCCM and System Center Operation Manager (SCOM) agents, third-party management agents, antivirus and antimalware software, and more. A user does not have to be logged on to their machine for manage out to work.

IPv6

DirectAccess manage out requires that connections initiated by machines on the internal network to remote-connected DirectAccess clients must be made using IPv6. This is because DirectAccess clients use IPv6 exclusively to connect to the DirectAccess server. To enable connectivity over the public IPv4 Internet, clients use IPv6 transition technologies (6to4, Teredo, IP-HTTPS), and IPv6 translation components on the server (DNS64 and NAT64) enable clients to communicate with internal IPv4 resources. However, DNS64 and NAT64 only translate IPv6 to IPv4 inbound. They do not work in reverse.

Native or Transition?

It is recommended that IPv6 be deployed on the internal network to enable DirectAccess manage out. This is not a trivial task, and many organizations can’t justify the deployment for just this one specific use case. As an alternative, IPv6 can be configured with an IPv6 transition technology, specifically the Intrasite Automatic Tunnel Addressing Protocol (ISATAP). ISATAP functions as an IPv6 overlay network, allowing internal hosts to obtain IPv6 addresses and routing information from an ISATAP router to support manage out for DirectAccess clients.

ISATAP

When DirectAccess is installed, the server is automatically configured as an ISATAP router. Guidance for configuring ISATAP clients can be found here. Using ISATAP can be an effective approach to enabling DirectAccess manage out for SCCM when native IPv6 is not available, but it is not without its drawbacks.

• Using the DirectAccess server for ISATAP is only supported with single server DirectAccess deployments.
• Using the DirectAccess server for ISATAP does work when using Network Load Balancing (NLB) with some additional configuration, but it is not supported.
• Using the DirectAccess server for ISATAP does not work when an external load balancer is used, or if multisite is enabled.

ISATAP with Load Balancing and Multisite

It is technically possible to enable DirectAccess manage out for SCCM using ISATAP in load-balanced and multisite DirectAccess deployments, however. It involves deploying a separate ISATAP router and some custom configuration, but once in place it works perfectly. I offer this service to my customers as part of a consulting engagement. If you’re interested in restoring DirectAccess manage out functionality to support SCCM remote control, RDC, or VNC in load-balanced or multisite DirectAccess deployments, fill out the form below and I’ll provide you with more information.

Additional Resources

ISATAP Recommendations for DirectAccess Deployments
DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016
DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out
Video: Windows 10 DirectAccess in action (includes manage out demonstration)

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

DirectAccess Network Connectivity Assistant (NCA) Configuration GuidanceThe DirectAccess Network Connectivity Assistant (NCA), first introduced in Windows 8, provides DirectAccess connectivity status information as well as diagnostic support on the client. The NCA validates that DirectAccess is working end-to-end by attempting to reach internal resources defined by the administrator during the configuration of DirectAccess. NCA configuration and operation is a source of much confusion. This article serves to provide best practice configuration guidance for the NCA to ensure optimum and reliable operation.

NCA Operation

When a DirectAccess client is outside the corporate network, it will attempt to establish a DirectAccess connection any time it has an active Internet connection. After a DirectAccess connection is made, the NCA will attempt to validate DirectAccess connectivity by verifying availability of corporate resources as defined in the DirectAccess configuration (Remote Access Management console, Step 1, Edit, Network Connectivity Assistant).

If the NCA can reach the defined internal corporate resource(s), the DirectAccess connection is verified end-to-end and it will report the connection status as “Connected”. If it fails to connect to any internal corporate resource, it displays “Connecting”.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Figure 1. NCA successfully validated internal corporate resource connectivity.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Figure 2. NCA failed to connect to one or more corporate resources.

NCA Configuration

When first installing DirectAccess, the Remote Access Setup wizard will collect information to be used by the NCA, including corporate resources, helpdesk email address, and DirectAccess connection name. It will also provide the option to allow DirectAccess clients to use local name resolution.

Note: The NCA settings configured in the Remote Access Management console pertain only to Windows 8.x and Windows 10 clients. They are not used by Windows 7 clients at all.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Intuitively it would appear that information needs to be entered in the Resource and Type fields. However, it is recommended to leave this blank when first configuring DirectAccess. This is because the Remote Access Setup Wizard will automatically populate this field later. Specifying a resource during initial configuration will result in two entries being included, as shown here.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

As you can see, the Remote Access Setup wizard automatically added the resource directaccess-WebProbeHost.<internal domain.>. A corresponding DNS record is created that resolves this hostname to the internal IPv4 address of the DirectAccess server. In this configuration, the DirectAccess server itself serves as the corporate resource used by the NCA.

Multiple Corporate Resources

Having more than one resource to validate connectivity to the internal network is problematic though. If there are multiple entries specified, they must ALL pass a validation check from the client to report the connection status as “Connected”. Some administrators configure multiple entries with the mistaken belief that it will provide redundancy for the NCA, but it actually has the opposite effect. Having more than one entry only increases the chance of a false positive.

NCA Configuration Best Practices

It is recommended that only a single corporate resource URL be defined for the NCA. The default directaccess-WebProbeHost running on the DirectAccess server can be used, or, alternatively, another internal web server can be specified if desired. Any web server will work, including Microsoft Internet Information Services (IIS), Apache, NGINX, and most Application Delivery Controllers (ADCs) or load balancers. HTTPS is not required for the web probe host, only HTTP. If using an internal web server, ensure that it is highly available.

Do NOT use the Network Location Server (NLS) as a corporate resource! The NLS is exempted from the Name Resolution Policy Table (NRPT) on the client and is not reachable over DirectAccess. This will result in the NCA failing and reporting a “Connecting” status perpetually. In addition, avoid the use of PING for validating internal corporate resources. Ping uses ICMP which is inherently unreliable and commonly blocked by host and intermediary firewalls, making it an unreliable indicator of corporate network connectivity over DirectAccess.

Summary

The NCA is a crucial and often misunderstood component in the DirectAccess architecture. Follow the guidance outlined here to ensure that the NCA works reliably and effectively in your environment.

Additional Resources

DirectAccess Clients in Connecting State when using External Load Balancer
Planning and Implementing DirectAccess on Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 book

%d bloggers like this: