DirectAccess Selective Tunneling

DirectAccess Selective TunnelingDirectAccess administrators, and network administrators in general, are likely familiar with the terms “split tunneling” and “force tunneling”. They dictate how traffic is handled when a DirectAccess (or VPN) connection is established by a client. Split tunneling routes only traffic destined for the internal network over the DirectAccess connection; all other traffic is routed directly over the Internet. Force tunneling routes all traffic over the DirectAccess connection.

Force Tunneling

DirectAccess uses split tunneling by default. Optionally, it can be configured to use force tunneling if required. Force tunneling is commonly enabled when DirectAccess administrators want to inspect and monitor Internet traffic from field-based clients.

Note: One-time password user authentication is not supported when force tunneling is enabled. Details here.

Drawbacks

Force tunneling is not without its drawbacks. It requires that an on-premises proxy server be used by DirectAccess clients to access the Internet, in most cases. In addition, the user experience is often poor when force tunneling is enabled. This is caused by routing Internet traffic, which is commonly encrypted, over an already encrypted connection. The added protocol overhead caused by double encryption (triple encryption if you are using Windows 7!) along with using a sub-optimal network path increases latency and can degrade performance significantly. Also, location-based services typically fail to work correctly.

Selective Tunneling

“Selective Tunneling” is a term that I commonly use to describe a configuration where only one or a few specific public resources are tunneled over the DirectAccess connection. A common use case is where access to a cloud-based application is restricted to the IP address of a corporate proxy or firewall.

Using the Name Resolution Policy Table (NRPT) and taking advantage of DirectAccess and its requirement for IPv6, DirectAccess administrators can choose to selectively route requests for public hosts or domains over the DirectAccess connection. The process involves defining the public Fully Qualified Domain Name (FQDN) as “internal” in the DirectAccess configuration and then assigning an on-premises proxy server for DirectAccess clients to use to access that namespace.

Enable Selective Tunneling

While some of the selective tunneling configuration can be performed using the Remote Access Management console, some of it can only be done using PowerShell. For this reason, I prefer to do everything in PowerShell to streamline the process.

Run the following PowerShell commands on the DirectAccess server to enable selective tunneling for the “.example.com” domain.

$namespace = “.example.com” # include preceding dot for namespace, omit for individual host
$dnsserver = Get-ItemPropertyValue –Path HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters -Name DnsServers

Add-DAClientDnsConfiguration -DnsSuffix $namespace -DnsIpAddress $dnsserver -PassThru

$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]
$proxy = “proxy.corp.example.net:8080” # this is the FQDN and port for the internal proxy server
$rule = (Get-DnsClientNrptRule -GpoName $gpo | Where-Object Namespace -eq $namespace | Select-Object -ExpandProperty “Name”)

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

If Windows 7 client support has been enabled, run the following PowerShell commands on the DirectAccess server. If multisite is enabled, run these commands on one DirectAccess server in each entry point.

$downlevelgpo = (Get-RemoteAccess).DownlevelGpoName
$downlevelgpo = $downlevelgpo.Split(‘\’)[1]
$proxy = “proxy.corp.example.net:8080” # this is the FQDN and port for the internal proxy server
$downlevelrule = (Get-DnsClientNrptRule -GpoName $downlevelgpo | Where-Object Namespace -eq $namespace | Select-Object -ExpandProperty “Name”)

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

To remove a namespace from the NRPT, run the following PowerShell command.

Remove-DAClientDnsConfiguration -DnsSuffix $namespace

Caveats

While selective tunneling works well for the most part, the real drawback is that only Microsoft browsers (Internet Explorer and Edge) are supported. Web sites configured for selective tunneling will not be reachable when using Chrome, Firefox, or any other third-party web browser. In addition, many web sites deliver content using more than one FQDN, which may cause some web pages to load improperly.

Additional Resources

DirectAccess Force Tunneling and Proxy Server Configuration

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

NetMotion Mobility for DirectAccess Administrators – Split vs. Force TunnelingDirectAccess employs a split tunneling network model by default. In this configuration, only network traffic destined for the internal network (as defined by the administrator) is tunneled over the DirectAccess connection. All other network traffic is routed directly over the Internet.

Force Tunneling Use Cases

For a variety of reasons, administrators may want to configure DirectAccess to use force tunneling, requiring all client traffic be routed over the DirectAccess connection, including public Internet traffic. Commonly this is done to ensure that all traffic is logged and, importantly, screened and filtered to enforce acceptable use policy and to prevent malware infection and potential loss of data.

DirectAccess and Force Tunneling

Enabling force tunneling for DirectAccess is not trivial, as it requires an on-premises proxy server to ensure proper functionality when accessing resources on the public Internet. You can find detailed guidance for configuring DirectAccess to use force tunneling here.

NetMotion Mobility and Force Tunneling

With NetMotion Mobility, force tunneling is enabled by default. So, if split tunneling is desired, it must be explicitly configured. Follow the steps below to create a split tunneling policy.

Create a Rule Set

  1. Open the NetMotion Mobility management console and click Policy > Policy Management.
  2. Click New.
  3. Enter a descriptive name for the new rule set.
  4. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Create a Rule

  1. Click New.
  2. Enter a descriptive name for the new rule.
  3. Click Ok.

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Define an Action

  1. Click on the Actions tab.
  2. In the Addresses section check the box next to Allow network traffic for address(es)/port(s).NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  3. In the Base section select Pass through all network traffic.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Define the Internal Network

  1. In the Policy rule definition section click the address(es)/port(s) link.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  2. Click Add.
  3. In the Remote Address column select Network Address.
  4. Enter the network prefix and prefix length that corresponds to the internal network.
  5. Click Ok.
  6. Repeat the steps above to add any additional internal subnets, as required.
  7. Click Ok.
  8. Click Save.
  9. Click Save.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Assign the Policy

  1. Click on the Subscribers tab.
  2. Choose a group to assign the policy to. This can be users, groups, devices, etc.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling
  3. Click Subscribe.
  4. Select the Split Tunneling policy.
  5. Click Ok.NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

Validation Testing

With split tunneling enabled the NetMotion Mobility client will be able to securely access internal network resources over the Mobility connection, but all other traffic will be routed over the public Internet. To confirm this, first very that internal resources are reachable. Next, open your favor Internet search engine and enter “IP”. The IP address you see should be the IP address of the client, not the on-premises gateway.

Summary

I’ve never been a big fan of force tunneling with DirectAccess. Not only is it difficult to implement (and requires additional infrastructure!) the user experience is generally poor. There are usability issues especially with captive portals for Wi-Fi, and performance often suffers. In addition, enabling force tunneling precludes the use of strong user authentication with one-time passwords.

With NetMotion Mobility, force tunneling is on by default, so no configuration changes are required. The user experience is improved as NetMotion Mobility intelligently recognizes captive portals. Performance is much better too. In addition, NetMotion Mobility is more flexible, allowing for the use of OTP authentication with force tunneling. Also, with NetMotion Mobility force tunneling is not a global setting. You can selectively apply force tunneling to users and/or groups as necessary.

Additional Information

NetMotion Mobility as an Alternative for Microsoft DirectAccess

NetMotion Mobility for DirectAccess Administrators – Trusted Network Detection

Enabling Secure Remote Administration for the NetMotion Mobility Console

NetMotion Mobility Device Tunnel Configuration

 

Always On VPN Hands-On Training Classes Coming to Denver and New York

Windows 10 Always On VPN Hands-On Training Classes for 2018I’m pleased to announce that I will be bringing my popular three-day Windows 10 Always On VPN Hands-On Training classes to Denver and New York in May and June! Join me May 15-17, 2018 in Denver or June 5-7, 2018 in New York. These training classes will cover all aspects of designing, implement, and supporting an Always On VPN solution in the enterprise. These three-day courses will cover topics including…

  • Windows 10 Always On VPN overview
  • Introduction to CSP
  • Infrastructure requirements
  • Planning and design considerations
  • Installation, configuration, and client provisioning

Advanced topics will include…

  • Redundancy and high availability+
  • Cloud-based deployments
  • Third-party VPN infrastructure and client support
  • Multifactor authentication
  • Always On VPN migration strategies

Windows 10 Always On VPN Hands-On Training Classes for 2018

Register Today

Reservations are being accepted now! The cost for this 3-day hands-on training class is $4995.00 USD. Space is limited, so don’t wait to register! Fill out the form below to save your seat now.

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

Always On VPN Hands-On Training Classes for 2018

Windows 10 Always On VPN Hands-On Training Classes for 2018I’m pleased to announce I will be delivering Windows 10 Always On VPN hands-on training classes in various locations around the U.S. this year. As Microsoft continues to move away from DirectAccess in favor of Windows 10 Always On VPN, many organizations now must come up to speed on this new technology. Spoiler alert…it’s not trivial to implement! There’s lots of moving parts, critical infrastructure dependencies, and many configuration options to choose from. Additionally, Windows 10 Always On VPN is managed in a completely different way than DirectAccess, which is sure to present its own unique challenges.

Comprehensive Education

My Windows 10 Always On VPN hands-on training classes will cover all aspects of designing, implementing, and supporting an Always On VPN solution in the enterprise. This three-day course will cover topics such as…

  • Windows 10 Always On VPN overview
  • Introduction to CSP
  • Infrastructure requirements
  • Planning and design considerations
  • Installation, configuration, and client provisioning

Advanced topics will include…

  • Redundancy and high availability
  • Cloud-based deployments
  • Third-party VPN infrastructure and client support
  • Multifactor authentication
  • Always On VPN migration strategies

Upcoming Training Classes

Reservations are being accepted immediately for classes held on March 27-29, 2018 in Southern California and April 10-12 in Chicago. The cost for this 3 day hands-on, in-depth training class is $4995.00 USD. Later this year I’ll be delivering classes in other parts of the country as well. Those locations will be chosen based on demand, so if you can’t make this first class, please register anyway and let me know your location preference. If there’s enough interest in a specific locale I will schedule a class for that region soon. Although I currently have no plans to deliver my training classes outside the U.S., I’m more than happy to consider it if there is enough demand, so let me know!

Windows 10 Always On VPN Hands-On Training Classes for 2018

Reservations Available Now

Reservations are being accepted now! The cost for this 3-day hands-on training class is $4995.00 USD. Space is limited, so don’t wait to register! Fill out the form below to save your seat now.

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 

 

 

5 Things DirectAccess Administrators Should Know About Always On VPN

5 Things DirectAccess Administrators Should Know About Always On VPNWindows 10 Always On VPN hands-on training classes now forming. Details here.

As I’ve written about previously, Microsoft is no longer investing in DirectAccess going forward. There will be no new features or functionality added to the product in the future. Microsoft is now investing in Always On VPN in Windows 10, with new features being released with each semi-annual update of the operating system. But as Microsoft continues to make the push toward Always On VPN over DirectAccess, many administrators have asked about the ramifications of this shift in focus for enterprise remote access. Here are a few points to consider.

It’s the same thing, only different.

Always On VPN provides the same seamless, transparent, always on experience as DirectAccess. Under the covers, the mechanics of how that’s accomplished changes a bit, but fundamentally the user experience is exactly the same. Once a user logs on to their device, a VPN connection is established automatically and the user will have secure remote access to corporate resources.

The connection is still secure.

Where DirectAccess uses IPsec and Connection Security Rules (CSRs) to establish its secure tunnels, Always On VPN uses traditional client-based VPN protocols such as IKEv2, SSTP, L2TP, and PPTP. Both DirectAccess and Always On VPN use certificates for authentication. However, where DirectAccess uses machine certificates to authenticate the computer, Always On VPN leverages user certificates to authenticate the user.

(Note: Machine certificates will be required for Always On VPN when using the optional device tunnel configuration. I will publish more details about this configuration option in a future article.)

Provisioning and managing clients is different.

The administrative experience for Always On VPN is much different than it is with DirectAccess. Where DirectAccess made use of Active Directory and group policy for managing client and server settings, Always On VPN clients must be provisioned using a Mobile Device Management (MDM) solution such as Microsoft Intune, or any third-party MDM platform. Optionally, Always On VPN clients can be provisioned using Microsoft System Center Configuration Manager (SCCM), or manually using PowerShell.

Security is enhanced.

Always On VPN has the potential to provide much more security and protection than DirectAccess. Always On VPN supports traffic filtering, allowing administrators to restrict remote client communication by IP address, protocol, port, or application. By contrast, DirectAccess allows full access to the internal network after user logon with no native capability to restrict access. In addition, Always On VPN supports integration with Azure Active Directory, which enables conditional access and multifactor authentication scenarios.

It’s built for the future.

Always On VPN also provides support for modern authentication mechanisms like Windows Hello for Business. In addition, Windows Information Protection (WIP) integration is supported to provide essential protection for enterprise data.

Summary

Microsoft set the bar pretty high with DirectAccess. Users love the seamless and transparent access it provides, and administrators reap the benefit of improved systems management for field based devices. Always On VPN provides those same benefits, with additional improvements in security and protection. If you’d like more information about Always On VPN, fill out the form below and I’ll get in touch with you.

Additional Information

Always On VPN and the Future of DirectAccess

3 Important Advantages of Windows 10 Always On VPN over Microsoft DirectAccess

Windows 10 Always On VPN Hands-On Training

%d bloggers like this: