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

Always On VPN Certificate Requirements for IKEv2

Always On VPN Certificate Requirements for IKEv2Internet Key Exchange version 2 (IKEv2) is one of the VPN protocols supported for Windows 10 Always On VPN deployments. When the VPN server is Windows Server 2016 with the Routing and Remote Access Service (RRAS) role configured, a computer certificate must first be installed on the server to support IKEv2. There are some unique requirements for this certificate, specifically regarding the subject name and Enhanced Key Usage (EKU) configuration. In addition, some deployment scenarios may require a certificate to be provisioned to the client to support IKEv2 VPN connections.

Server Certificate

The IKEv2 certificate on the VPN server must be issued by the organization’s internal private certification authority (CA). It must be installed in the Local Computer/Personal certificate store on the VPN server. The subject name on the certificate must match the public hostname used by VPN clients to connect to the server, not the server’s hostname. For example, if the VPN server’s hostname is VPN1 and the public FQDN is vpn.example.net, the subject field of the certificate must include vpn.example.net, as shown here.

Always On VPN Certificate Requirements for IKEv2

In addition, the certificate must include the Server Authentication EKU (1.3.6.1.5.5.7.3.1). Optionally, but recommended, the certificate should also include the IP security IKE intermediate EKU (1.3.6.1.5.5.8.2.2).

Always On VPN Certificate Requirements for IKEv2

Client Certificate

Client certificate requirements vary depending on the type of VPN tunnel and authentication method being used.

User Tunnel

No certificates are required on the client to support IKEv2 when using MSCHAPv2, EAP-MSCHAPv2, or Protected EAP (PEAP) with MSCHAPv2. However, if the option to verify the server’s identity by validating the certificate is selected when using PEAP, the client must have the certificates for the root CA and any subordinate CAs installed in its Trusted Root Certification and Intermediate Certificate Authorities certificate stores, respectively.

User Tunnel with Certificate Authentication

Using certificate authentication for the user tunnel is the recommended best practice for Always On VPN deployments. A client certificate must be installed in the Current User/Personal store to support PEAP authentication with smart card or certificate authentication. The certificate must include the Client Authentication EKU (1.3.6.1.5.5.7.3.2).

Always On VPN Certificate Requirements for IKEv2

Device Tunnel

A computer certificate must be installed in the Local Computer/Personal certificate store to support IKEv2 machine certificate authentication and the Always On VPN device tunnel. The certificate must include the Client Authentication EKU (1.3.6.1.5.5.7.3.2).

Always On VPN Certificate Requirements for IKEv2

More information about configuring the Always On VPN device tunnel can be found here.

Additional Information

Always On VPN with Trusted Platform Module (TPM) Certificates

Always On VPN Protocol Recommendations for Windows Server 2016 RRAS

Always On VPN and Windows Server RRAS

Always On VPN Training

Always On VPN and the Name Resolution Policy Table (NRPT)

Always On VPN and the Name Resolution Policy Table (NRPT)The Name Resolution Policy Table (NRPT) is a function of the Windows client and server operating systems that allows administrators to enable policy-based name resolution request routing. Instead of sending all name resolution requests to the DNS server configured on the computer’s network adapter, the NRPT can be used to define unique DNS servers for specific namespaces.

DirectAccess administrators will be intimately familiar with the NRPT, as it is explicitly required for DirectAccess operation. Use of the NRPT for Windows 10 Always On VPN is optional, however. It is commonly used for deployments where split DNS is enabled. Here the NRPT can define DNS servers for the internal namespace, and exclusions can be configured for FQDNs that should not be routed over the VPN tunnel.

To enable the NRPT for Windows 10 Always On VPN, edit the ProfileXML to include the DomainNameInformation element.

<DomainNameInformation>
   <DomainName>.example.net</DomainName>
   <DnsServers>10.21.12.100,10.21.12.101</DnsServers>
</DomainNameInformation>

Note: Be sure to include the leading “.” in the domain name to ensure that all hosts and subdomains are included.

To create an NRPT exclusion simply omit the DnsServers element. Define additional entries for each hostname to be excluded, as shown here.

<DomainNameInformation>
   <DomainName>www.example.net</DomainName>
</DomainNameInformation>
<DomainNameInformation>
   <DomainName>mail.example.net</DomainName>
</DomainNameInformation>
<DomainNameInformation>
   <DomainName>autodiscover.example.net</DomainName>
</DomainNameInformation>

Additional Information

Windows 10 VPNv2 Configuration Service Provider (CSP) Reference

Windows 10 Always On VPN Protocol Recommendations for Windows Server Routing and Remote Access Services (RRAS)

Windows 10 Always On VPN Hands-On Training

Always On VPN RasMan Device Tunnel Failure

Always On VPN RasMan Device Tunnel FailureAn Always On VPN device tunnel is an optional configuration for Windows 10 Enterprise edition clients designed to provide machine-level remote network connectivity. This capability provides feature parity with DirectAccess for domain-joined clients to support scenarios such as logging on without cached credentials and unattended remote support, among others.

Device Tunnel Failure

When configuring a Windows 10 client to use an Always On VPN device tunnel, you may find that the device tunnel works without issue after initial deployment but fails to connect after the computer restarts. In addition, the Windows event log will include an Event ID: 1000 application error with the following error message:

Faulting application name: svchost.exe_RasMan

Always On VPN RasMan Device Tunnel Failure

Known Issue

This can occur when a Windows 10 machine is configured with a device tunnel only (no user tunnel). This is a known issue with Windows 10 v1709 and it is currently being addressed by Microsoft. The fix should be included in Windows 10 v1803 (RS4).

Additional Information

Windows 10 Always On VPN Device Tunnel Step-by-Step Configuration using Powershell

Deleting an Always On VPN Device Tunnel

Unable to Generate DirectAccess Diagnostic Log in Windows 10 v1709

There are numerous reports that generating the DirectAccess troubleshooting log fails on Windows 10 v1709. DirectAccess administrators have been reporting that the process seems to fail during the creation of the log file, leaving it truncated and incomplete. To resolve this issue, open an elevated PowerShell window and enter the following command.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\NcaSvc\” -Name SvcHostSplitDisable -PropertyType DWORD -Value 1 -Force

The computer must be restarted for this change to take effect. If initial testing of this workaround is successful, the registry setting can be pushed out to all DirectAccess clients using Active Directory Group Policy Preferences.

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

DirectAccess Troubleshooting and the Windows 10 Network Connectivity AssistantOne of the first places administrators look for information about the DirectAccess client connection is the Network Connectivity Assistant (NCA). The NCA is used to view current connection status and to gather detailed information that is helpful for troubleshooting failed DirectAccess connections. The NCA was first integrated with the client operating system beginning with Windows 8. Similar functionality can be extended to Windows 7 clients by installing and configuring the Windows 7 DirectAccess Connectivity Assistant (DCA).

NCA

The DirectAccess NCA can be accessed by pressing the Windows Key + I and then clicking on Network & Internet and DirectAccess. Here you’ll find a helpful visual indicator of current connectivity status, and for multisite deployments you’ll also find details about the current entry point.

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

DirectAccess Missing?

If DirectAccess does not appear in the list, open an elevated PowerShell window and restart the Network Connectivity Assistant service (NcaSvc) using the following command.

Restart-Service NcaSvc

If you receive the error “Failed to start service ‘Network Connectivity Assistant (NcaSvc)‘”, ensure that the client operating system is Enterprise or Education edition. The NCA service will always fail to start on Professional edition as it is not a supported DirectAccess client.

Log Collection

The DirectAccess NCA also provides access to crucial troubleshooting information. Clicking on the Collect button creates a detailed diagnostic log file that is often helpful for troubleshooting DirectAccess connectivity issues.

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

Troubleshooting Info Missing?

The option to collect a log, and email it to your IT admin will only be displayed if a support email address is defined in the DirectAccess configuration. To define a support email address, open the Remote Access Management console and perform the following steps.

1. Click Edit on Step 1.
2. Click Network Connectivity Assistant.
3. Enter an email address in the Helpdesk email address field.
4. Click Finish to complete Step 1.
5. Click Finish to apply the changes.

Email Program

Microsoft assumes that an end user will be generating the DirectAccess client troubleshooting log and will be emailing them to their administrator. If an email program is not installed on the client, the following information is displayed.

There is no email program associated to perform the requested action. Please install an email program or, if one is already installed, create an associate in the Default Programs control panel.

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

If you wish to simply view the log file on the client and not email them, you can find the generated DirectAccess troubleshooting log file in HTML format in the following location.

%SystemDrive%\Users\%Username%\AppData\Local\Temp

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

Unable to Generate Log Files

There are numerous reports that generating the DirectAccess troubleshooting log fails on Windows 10 v1709. DirectAccess administrators have been reporting that the process seems to fail during the creation of the log file, leaving it truncated and incomplete. To resolve this issue, open an elevated PowerShell window and enter the following command.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\NcaSvc\” -Name SvcHostSplitDisable -PropertyType DWORD -Value 1 -Force

The computer must be restarted for this change to take effect. If initial testing of this workaround is successful, the registry setting can be pushed out to all DirectAccess clients using Active Directory Group Policy Preferences.

Additional Information

Installing and Configuring DirectAccess Connectivity Assistant 2.0 on Windows 7 Clients

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

Deleting an Always On VPN Device Tunnel

Deleting an Always On VPN Device TunnelWindows 10 Always On VPN supports both a user tunnel for corporate network access, and a device tunnel typically used to provide pre-logon network connectivity and to support manage out scenarios. The process of testing Always On VPN is often an iterative one involving trial and error testing to fine tune the configuration parameters to achieve the best experience. As a part of this process it will often be necessary to delete a connection at some point. For the user tunnel the process is simple and straightforward. Simply disconnect the session and delete the connection in the UI.

Deleting an Always On VPN Device Tunnel

Deleting a device tunnel connection presents a unique challenge though. Specifically, there is no VPN connection in the UI to disconnect and remove. To delete an Always On VPN device tunnel, open an elevated PowerShell window and enter the following command.

Get-VpnConnection -AllUserConnection | Remove-VpnConnection -Force

If the device tunnel is connected when you try to remove it, you will receive the following error message.

The VPN connection [connection_name] cannot be removed from the global user connections. Cannot
delete a connection while it is connected.

Deleting an Always On VPN Device Tunnel

The device tunnel must first be disconnected to resolve this issue. Enter the following command to disconnect the device tunnel.

rasdial.exe [connection_name] /disconnect

Remove the device tunnel connection using PowerShell once complete.

Deleting an Always On VPN Device Tunnel
Additional Resources

Windows 10 Always On VPN Device Tunnel Step-by-Step Configuration using PowerShell

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

Windows 10 Always On VPN Recommendations for Windows Server 2016 Routing and Remote Access Service (RRAS)

Windows 10 Always On VPN Hands-On Training

Troubleshooting Always On VPN Errors 691 and 812

Troubleshooting Always On VPN Errors 691 and 812When configuring Windows 10 Always On VPN using the Routing and Remote Access Service (RRAS) on Windows Server 2012 R2 and Extensible Authentication Protocol (EAP) authentication using client certificates, clients attempting to establish a VPN connection using Internet Key Exchange version 2 (IKEv2) may receive the following error.

“The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile.”

Troubleshooting Always On VPN Errors 691 and 812

The event log on the client also records RasClient event ID 20227 stating “the error code returned on failure is 812”.

Troubleshooting Always On VPN Errors 691 and 812

Always On VPN clients using the Secure Socket Tunneling Protocol (SSTP) may receive the following error.

“The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.”

Troubleshooting Always On VPN Errors 691 and 812

The event log on the client also records RasClient event ID 20227 stating “the error code returned on failure is 691”.

Troubleshooting Always On VPN Errors 691 and 812

Resolution

These errors can occur when Transport Layer Security (TLS) 1.0 has been disabled on the RRAS server. To restore functionality, enable TLS 1.0 protocol support on the RRAS server. If disabling TLS 1.0 is required for compliance reasons, consider deploying RRAS on Windows Server 2016. TLS 1.0 can be safely disabled on Windows Server 2016 without breaking EAP client certificate authentication for Windows 10 Always On VPN clients.

Additional Information

Windows 10 Always On VPN Hands-On Training

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

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

3 Important Advantages of Windows 10 Always On VPN over DirectAccess 

Windows 10 Always On VPN and the Future of DirectAccess

DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

DirectAccess and Always On VPN with Trusted Platform Module (TPM) CertificatesTo enhance security when provisioning certificates for DirectAccess (computer) or Windows 10 Always On VPN (user) it is recommended that private keys be stored on a Trusted Platform Module (TPM) on the client device. A TPM is a dedicated security processor included in nearly all modern computers. It provides essential hardware protection to ensure the highest levels of integrity for digital certificates and is used to generate, store, and restrict the use of cryptographic keys. It also includes advanced security and protection features such as key isolation, non-exportability, and anti-hammering to prevent brute-force attacks.

To ensure that private keys are created and stored on a TPM, the certificate template must be configured to use the Microsoft Platform Crypto Provider. Follow the steps below to configure a certificate template required to use a TPM.

  1. Open the Certificate Templates management console (certtmpl.msc) and duplicate an existing certificate template. For example, if creating a certificate for DirectAccess, duplicate the Workstation Authentication certificate template. For Always On VPN, duplicate the User certificate template.
  2. On the Compatibility tab, ensure the Certification Authority and Certificate recipient compatibility settings are set to a minimum of Windows Server 2008 and Windows Vista/Server 2008, respectively.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates
  3. Select the Cryptography tab.
  4. Choose Key Storage Provider from the Provider Category drop down list.
  5. Choose the option Requests must use one of the following providers and select Microsoft Platform Crypto Provider.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

Note: If Microsoft Platform Crypto Provider does not appear in the list above, got to the Request Handling tab and uncheck the option Allow private key to be exported.

Complete the remaining certificate configuration tasks (template display name, subject name, security settings, etc.) and publish the certificate template. Client machines configured to use this template will now have a certificate with private key fully protected by the TPM.

Additional Resources

Trusted Platform Module (TPM) Fundamentals

DirectAccess and Always On VPN Certificate Auto Enrollment

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

%d bloggers like this: