What is the Difference Between DirectAccess and Always On VPN?

Always On VPN Device Tunnel Configuration Guidance Now AvailableDirectAccess has been around for many years, and with Microsoft now moving in the direction of Always On VPN, I’m often asked “What’s the difference between DirectAccess and Always On VPN?” Fundamentally they both provide seamless and transparent, always on remote access. However, Always On VPN has a number of advantages over DirectAccess in terms of security, authentication and management, performance, and supportability.

Security

DirectAccess provides full network connectivity when a client is connected remotely. It lacks any native features to control access on a granular basis. It is possible to restrict access to internal resources by placing a firewall between the DirectAccess server and the LAN, but the policy would apply to all connected clients.

Windows 10 Always On VPN includes support for granular traffic filtering. Where DirectAccess provides access to all internal resources when connected, Always On VPN allows administrators to restrict client access to internal resources in a variety of ways. In addition, traffic filter policies can be applied on a per-user or group basis. For example, users in accounting can be granted access only to their department servers. The same could be done for HR, finance, IT, and others.

Authentication and Management

DirectAccess includes support for strong user authentication with smart cards and one-time password (OTP) solutions. However, there is no provision to grant access based on device configuration or health, as that feature was removed in Windows Server 2016 and Windows 10. In addition, DirectAccess requires that clients and servers be joined to a domain, as all configuration settings are managed using Active Directory group policy.

Windows 10 Always On VPN includes support for modern authentication and management, which results in better overall security. Always On VPN clients can be joined to an Azure Active Directory and conditional access can also be enabled. Modern authentication support using Azure MFA and Windows Hello for Business is also supported. Always On VPN is managed using Mobile Device Management (MDM) solutions such as Microsoft Intune.

Performance

DirectAccess uses IPsec with IPv6, which must be encapsulated in TLS to be routed over the public IPv4 Internet. IPv6 traffic is then translated to IPv4 on the DirectAccess server. DirectAccess performance is often acceptable when clients have reliable, high quality Internet connections. However, if connection quality is fair to poor, the high protocol overhead of DirectAccess with its multiple layers of encapsulation and translation often yields poor performance.

The protocol of choice for Windows 10 Always On VPN deployments is IKEv2. It offers the best security and performance when compared to TLS-based protocols. In addition, Always On VPN does not rely exclusively on IPv6 as DirectAccess does. This reduces the many layers of encapsulation and eliminates the need for complex IPv6 transition and translation technologies, further improving performance over DirectAccess.

Supportability

DirectAccess is a Microsoft-proprietary solution that must be deployed using Windows Server and Active Directory. It also requires a Network Location Server (NLS) for clients to determine if they are inside or outside the network. NLS availability is crucial and ensuring that it is always reachable by internal clients can pose challenges, especially in very large organizations.

Windows 10 Always On VPN supporting infrastructure is much less complex than DirectAccess. There’s no requirement for a NLS, which means fewer servers to provision, manage, and monitor. In addition, Always On VPN is completely infrastructure independent and can be deployed using third-party VPN servers such as Cisco, Checkpoint, SonicWALL, Palo Alto, and more.

Summary

Windows 10 Always On VPN is the way of the future. It provides better overall security than DirectAccess, it performs better, and it is easier to manage and support.

Here’s a quick summary of some important aspects of VPN, DirectAccess, and Windows 10 Always On VPN.

Traditional VPN DirectAccess Always On VPN
Seamless and Transparent No Yes Yes
Automatic Connection Options None Always on Always on, app triggered
Protocol Support IPv4 and IPv6 IPv6 Only IPv4 and IPv6
Traffic Filtering No No Yes
Azure AD Integration No No Yes
Modern Management Yes No (group policy only) Yes (MDM)
Clients must be domain-joined? No Yes No
Requires Microsoft Infrastructure No Yes No
Supports Windows 7 Yes Yes Windows 10 only

Always On VPN Hands-On Training

If you are interested in learning more about Windows 10 Always On VPN, consider registering for one of my hands-on training classes. More details here.

Additional Resources

Always On VPN and the Future of Microsoft DirectAccess

5 Important Things DirectAccess Administrators Should Know about Windows 10 Always On VPN

3 Important Advantages of Windows 10 Always On VPN over 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 Manage Out with ISATAP and NLB Clustering

DirectAccess Manage Out with ISATAP and NLB ClusteringDirectAccess connections are bidirectional, allowing administrators to remotely connect to clients and manage them when they are out of the office. DirectAccess clients use IPv6 exclusively, so any communication initiated from the internal network to remote DirectAccess clients must also use IPv6. If IPv6 is not deployed natively on the internal network, the Intrasite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 transition technology can be used to enable manage out.

ISATAP Supportability

According to Microsoft’s support guidelines for DirectAccess, using ISATAP for manage out is only supported for single server deployments. ISATAP is not supported when deployed in a multisite or load-balanced environment.

Not supported” is not the same as “doesn’t work” though. For example, ISATAP can easily be deployed in single site DirectAccess deployments where load balancing is provided using Network Load Balancing (NLB).

ISATAP Configuration

To do this, you must first create DNS A resource records for the internal IPv4 address for each DirectAccess server as well as the internal virtual IP address (VIP) assigned to the cluster.

DirectAccess Manage Out with ISATAP and NLB Clustering

Note: Do NOT use the name ISATAP. This name is included in the DNS query block list on most DNS servers and will not resolve unless it is removed. Removing it is not recommended either, as it will result in ALL IPv6-enabled hosts on the network configuring an ISATAP tunnel adapter.

Once the DNS records have been added, you can configure a single computer for manage out by opening an elevated PowerShell command window and running the following command:

Set-NetIsatapConfiguration -State Enabled -Router [ISATAP FQDN] -PassThru

DirectAccess Manage Out with ISATAP and NLB Clustering

Once complete, an ISATAP tunnel adapter network interface with a unicast IPv6 address will appear in the output of ipconfig.exe, as shown here.

DirectAccess Manage Out with ISATAP and NLB Clustering

Running the Get-NetRoute -AddressFamily IPv6 PowerShell command will show routes to the client IPv6 prefixes assigned to each DirectAccess server.

DirectAccess Manage Out with ISATAP and NLB Clustering

Finally, verify network connectivity from the manage out host to the remote DirectAccess client.

Note: There is a known issue with some versions of Windows 10 and Windows Server 2016 that may prevent manage out using ISATAP from working correctly. There’s a simple workaround, however. More details can be found here.

Group Policy Deployment

If you have more than a few systems on which to enable ISATAP manage out, using Active Directory Group Policy Objects (GPOs) to distribute these settings is a much better idea. You can find guidance for creating GPOs for ISATAP manage out here.

DirectAccess Client Firewall Configuration

Simply enabling ISATAP on a server or workstation isn’t all that’s required to perform remote management on DirectAccess clients. The Windows firewall running on the DirectAccess client computer must also be configured to securely allow remote administration traffic from the internal network. Guidance for configuring the Windows firewall on DirectAccess clients for ISATAP manage out can be found here.

ISATAP Manage Out for Multisite and ELB

The configuration guidance in this post will not work if DirectAccess multisite is enabled or external load balancers (ELB) are used. However, ISATAP can still be used. For more information about enabling ISATAP manage out with external load balancers and/or multisite deployments, fill out the form below and I’ll provide you with more details.

Summary

Once ISATAP is enabled for manage out, administrators on the internal network can remotely manage DirectAccess clients wherever they happen to be. Native Windows remote administration tools such as Remote Desktop, Windows Remote Assistance, and the Computer Management MMC can be used to manage remote DirectAccess clients. In addition, enterprise administration tools such as PowerShell remoting and System Center Configuration Manger (SCCM) Remote Control can also be used. Further, third-party remote administration tools such as VNC, TeamViewer, LogMeIn, GoToMyPC, Bomgar, and many others will also work with DirectAccess ISATAP manage out.

Additional Information

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

DirectAccess Manage Out and System Center Configuration Manager (SCCM)

Contact Me

Interested in learning more about ISATAP manage out for multisite and external load balancer deployments? Fill out the form below and I’ll get in touch with you.

← Back

Thank you for your response. ✨