Always On VPN IKEv2 Security Configuration

Always On VPN IKEv2 Security ConfigurationWhen deploying Windows 10 Always On VPN, many administrators choose the Internet Key Exchange version 2 (IKEv2) protocol to provide the highest level of security and protection for remote connections. However, many do not realize the default security parameters for IKEv2 negotiated between a Windows Server running the Routing and Remote Access Service (RRAS) and a Windows 10 VPN client are far less than ideal from a security perspective. Additional configuration on both the server and the client will be required to ensure adequate security and protection for IKEv2 VPN connections.

Windows 10 and RRAS IKEv2 Defaults

In their default configuration, a Windows 10 client connecting to a Windows Server running RRAS will negotiate an IKEv2 VPN connection using the following IPsec security parameters.

  • Encryption: 3DES
  • Authentication/Integrity: SHA-1
  • Key Size: DH Group 2 (1024 bit)

This information can be obtained by opening an elevated PowerShell command window and running the following command.

Get-NetIPsecMainModeSA | Select-Object -First 1

Always On VPN IKEv2 Security Configuration

This can also be confirmed by viewing a network trace as shown here.

Always On VPN IKEv2 Security Configuration

These IPsec security parameters might have been acceptable in the 90’s, but they certainly are not today. 🙂

Improving IKEv2 Security

To provide a baseline level of protection to meet today’s requirements for security and privacy for IKEv2 VPN connections, the following are the minimum recommended IPsec security parameters.

  • Encryption: AES128
  • Authentication/Integrity: SHA-256
  • Key Size: DH Group 14 (2048 bit)

RRAS Custom IPsec Policy

To implement these recommended security baselines for IKEv2 on a Windows Server running RRAS it will be necessary to define a custom IPsec security policy. To do this, open an elevated PowerShell command window and run the following commands on each RRAS server.

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SADataSizeForRenegotiationKilobytes 102400

Restart the Remote Access Management service for the changes to take effect.

Restart-Service RaMgmtSvc -PassThru

Always On VPN IKEv2 Security Configuration

Windows 10 Client Settings

The IPsec policy must match on both the server and the client for an IKEv2 VPN connection to be successful. Unfortunately, none of the IKEv2 IPsec security association parameters proposed by default on Windows 10 clients use 2048-bit keys (DH Group 14), so it will be necessary to define a custom IPsec security policy on the client to match the settings configured on the server.

To configure a matching IPsec security policy on an individual Windows 10 VPN client, open an elevated PowerShell command window and run the following command.

$connection = “[connection name]”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

Always On VPN IKEv2 Security Configuration

Restore Defaults

In the process of testing it may be necessary to restore the default IKEv2 configuration on both the client and the server. This can be accomplished by running the following PowerShell commands.

Server – Set-VpnServerConfiguration -RevertToDefault

Client – Set-VpnConnectionIPsecConfiguration -ConnectionName [connection_name] -RevertToDefault -Force

Always On VPN XML Settings

To implement a custom IPsec policy using the minimum recommended security settings for an Always On VPN connection using IKEv2, add the following settings to your ProfileXML.

<VPNProfile>
 <NativeProfile>
  <CryptographySuite>
   <AuthenticationTransformConstants>SHA256128</AuthenticationTransformConstants>
   <CipherTransformConstants>AES128</CipherTransformConstants>
   <EncryptionMethod>AES128</EncryptionMethod>
   <IntegrityCheckMethod>SHA256</IntegrityCheckMethod>
   <DHGroup>Group14</DHGroup>
   <PfsGroup>PFS2048</PfsGroup>
  </CryptographySuite>
 </NativeProfile>
</VPNProfile>

Why Not AES 256?

In the examples above you’ll notice that I’ve chosen to use AES128 and not AES256. This is by design, as AES256 does not provide any practical additional security in most use cases. Details here.

Enhanced Security and Performance

To further improve security and performance for IKEv2, consider implementing Elliptic Curve Cryptography (EC) certificates and using Galois Counter Mode (GCM) cipher suites such as GCMAES128 for authentication and encryption.

Additional Information

Always On VPN Certificate Requirements for IKEv2

Always On VPN IKEv2 Load Balancing with the KEMP LoadMaster Load Balancer

Troubleshooting Always On VPN Error Code 0x80092013

Troubleshooting Always On VPN Error Code 0x80092013Windows Server Routing and Remote Access Service (RRAS) is commonly used for Windows 10 Always On VPN deployments because it is easy to configure and manage and it includes Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP). SSTP is a Transport Layer Security (TLS) VPN protocol that is firewall-friendly and ubiquitously available. However, a common configuration mistake can lead to failed connections.

Error 0x80092013

A Windows 10 Always On VPN client may fail to establish a VPN connection to an RRAS VPN server when using SSTP. The VPN client will return the following error message.

“Can’t connect to Always On VPN. The revocation function was unable to check revocation because the revocation server was offline.”

Troubleshooting Always On VPN Error Code 0x80092013

The event log will also include RasClient event ID 20227 with the following error.

“The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is -2146885613.”

Troubleshooting Always On VPN Error Code 0x80092013

The Win32 error code –2146885613 converts to hexadecimal 0x80092013, which translates to CRYPT_E_REVOCATION_OFFLINE, indicating that the client was unable to successfully perform a check of the VPN server’s SSL certificate.

Revocation Checking

When the VPN client attempts to establish an SSTP connection to the Windows RRAS VPN, it will check the Certification Revocation List (CRL) using the information provided in the SSL certificate. If the CRL is unreachable for any reason, the client will not complete the connection

Common Cause of Error 0x80092013

Certificate revocation failures for Windows 10 Always On VPN SSTP connections commonly occur when the RRAS VPN server is configured with an SSL certificate issued by an internal certification authority (CA) and the CRL is not publicly available.

Resolving Error 0x80092013

Making the internal CA’s CRL available publicly will of course resolve this error. However, best practice recommendations for the SSTP SSL certificate call for the use of a certificate issued by a public CA. For detailed information about SSL certificate requirements and recommendations, please see Always On VPN SSL Certificate Requirements for SSTP.

Additional Information

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN ECDSA SSL Certificate Request for SSTP

Always On VPN Protocol Recommendations for Windows RRAS

Always On VPN ECDSA SSL Certificate Request for SSTP

As I’ve discussed previously, it is strongly recommended that the TLS certificate used for SSTP be signed using the Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA provides better security and performance compared to RSA certificates for Windows 10 Always On VPN connections using SSTP. See my previous post Always On VPN SSL Certificate Requirements for SSTP for more information.

Certificate Signing Request

To generate a Certificate Signing Request (CSR) using ECDSA to send to a public Certification Authority (CA), open the local computer certificate store (certlm.msc) on any Windows server or client and follow the steps below.

  1. Expand Certificates – Local Computer.
  2. Right-click the Personal folder and choose All Tasks > Advanced Operations > Create Custom Request.
  3. Click Next.
  4. Click Next.
  5. From the Template drop-down list choose (No template) CNG key.
  6. Click Next.
  7. Click Details.

    Always On VPN ECDSA SSL Certificate Request for SSTP

  8. Click Properties.
  9. On the General tab enter a name in the Friendly name field.
  10. Click on the Subject tab.
    1. In the Subject name section, from the Type drop-down list choose Common name.
    2. In the Value field enter the VPN server’s public hostname and click Add.
    3. In the Alternative name section, from the Type drop-down list choose DNS.
    4. In the Value field enter the VPN server’s public hostname and click Add.

      Always On VPN ECDSA SSL Certificate Request for SSTP

  11. Click on the Private Key tab.
    1. Expand Cryptographic Service Provider.
    2. Uncheck RSA,Microsoft Software Key Storage Provider.
    3. Check ECDSA_P256,Microsoft Software Key Storage Provider.

      Always On VPN ECDSA SSL Certificate Request for SSTP

  12. Click Ok.
  13. Click Next.
  14. Enter a name for the file in the File Name field.
  15. Click Finish.

Submit the Request

Once complete, submit the CSR for signing to your favorite public CA. Based on my experience, some CAs are easier to obtain ECDSA-signed certificates than other. Today, Digicert seems to be one of the better public CAs for obtaining EC TLS certificates.

Complete the Request

Once the CA has issued the certificate, import the certificate in to the local computer certificate store on the same client or server where the original CSR was created. The certificate can then be exported and imported on additional VPN servers, if required.

Additional Information

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN Protocol Recommendations for RRAS

 

Always On VPN Multisite with Azure Traffic Manager

Always On VPN Multisite with Azure Traffic ManagerEliminating single points of failure is crucial to ensuring the highest levels of availability for any remote access solution. For Windows 10 Always On VPN deployments, the Windows Server 2016 Routing and Remote Access Service (RRAS) and Network Policy Server (NPS) servers can be load balanced to provide redundancy and high availability within a single datacenter. Additional RRAS and NPS servers can be deployed in another datacenter or in Azure to provide geographic redundancy if one datacenter is unavailable, or to provide access to VPN servers based on the location of the client.

Multisite Always On VPN

Unlike DirectAccess, Windows 10 Always On VPN does not natively include support for multisite. However, enabling multisite geographic redundancy can be implemented using Azure Traffic Manager.

Azure Traffic Manager

Traffic Manager is part of Microsoft’s Azure public cloud solution. It provides Global Server Load Balancing (GSLB) functionality by resolving DNS queries for the VPN public hostname to an IP address of the most optimal VPN server.

Advantages and Disadvantages

Using Azure Traffic manager has some benefits, but it is not with some drawbacks.

Advantages – Azure Traffic Manager is easy to configure and use. It requires no proprietary hardware to procure, manage, and support.

Disadvantages – Azure Traffic Manager offers only limited health check options. Azure Traffic Manager’s HTTPS health check only accepts HTTP 200 OK responses as valid. Most TLS-based VPNs will respond with an HTTP 401 Unauthorized, which Azure Traffic Manager considers “degraded”. The only option for endpoint monitoring is a simple TCP connection to port 443, which is a less accurate indicator of endpoint availability.

Note: This scenario assumes that RRAS with Secure Socket Tunneling Protocol (SSTP) or another third-party TLS-based VPN server is in use. If IKEv2 is to be supported exclusively, it will still be necessary to publish an HTTP or HTTPS-based service for Azure Traffic Manager to monitor site availability.

Traffic Routing Methods

Azure Traffic Manager provide four different methods for routing traffic.

Priority – Select this option to provide active/passive failover. A primary VPN server is defined to which all traffic is routed. If the primary server is unavailable, traffic will be routed to another backup server.

Weighted – Select this option to provide active/active failover. Traffic is routed to all VPN servers equally, or unequally if desired. The administrator defines the percentage of traffic routed to each server.

Performance – Select this option to route traffic to the VPN server with the lowest latency. This ensures VPN clients connect to the server that responds the quickest.

Geographic – Select this option to route traffic to a VPN server based on the VPN client’s physical location.

Configure Azure Traffic Manager

Open the Azure management portal and follow the steps below to configure Azure Traffic Manager for multisite Windows 10 Always On VPN.

Create a Traffic Manager Resource

  1. Click Create a resource.
  2. Click Networking.
  3. Click Traffic Manager profile.

Create a Traffic Manager Profile

  1. Enter a unique name for the Traffic Manager profile.
  2. Select an appropriate routing method (described above).
  3. Select a subscription.
  4. Create or select a resource group.
  5. Select a resource group location.
  6. Click Create.

Always On VPN Multisite with Azure Traffic Manager

Important Note: The name of the Traffic Manager profile cannot be used by VPN clients to connect to the VPN server, since a TLS certificate cannot be obtained for the trafficmanager.net domain. Instead, create a CNAME DNS record that points to the Traffic Manager FQDN and ensure that name matches the subject or a Subject Alternative Name (SAN) entry on the VPN server’s TLS and/or IKEv2 certificates.

Endpoint Monitoring

Open the newly created Traffic Manager profile and perform the following tasks to enable endpoint monitoring.

  1. Click Configuration.
  2. Select TCP from the Protocol drop-down list.
  3. Enter 443 in the Port field.
  4. Update any additional settings, such as DNS TTL, probing interval, tolerated number of failures, and probe timeout, as required.
  5. Click Save.

Always On VPN Multisite with Azure Traffic Manager

Endpoint Configuration

Follow the steps below to add VPN endpoints to the Traffic Manager profile.

  1. Click Endpoints.
  2. Click Add.
  3. Select External Endpoint from the Type drop-down list.
  4. Enter a descriptive name for the endpoint.
  5. Enter the Fully Qualified Domain Name (FQDN) or the IP address of the first VPN server.
  6. Select a geography from the Location drop-down list.
  7. Click OK.
  8. Repeat the steps above for any additional datacenters where VPN servers are deployed.

Always On VPN Multisite with Azure Traffic Manager

Summary

Implementing multisite by placing VPN servers is multiple physical locations will ensure that VPN connections can be established successfully even when an entire datacenter is offline. In addition, active/active scenarios can be implemented, where VPN client connections can be routed to the most optimal datacenter based on a variety of parameters, including current server load or the client’s current location.

Additional Information

Windows 10 Always On VPN Hands-On Training Classes

Always On VPN Routing Configuration

Windows 10 Always On VPN Routing ConfigurationWhen configuring Windows 10 Always On VPN, the administrator must choose between force tunneling and split tunneling. When force tunneling is used, all network traffic from the VPN client is routed over the VPN tunnel. When split tunneling is used, the VPN client must be configured with the necessary IP routes to establish remote network connectivity to on-premises resources. How those routes are established is a common source of confusion. This article provides guidance for properly configuring routing for Always On VPN clients.

Class Based Routing

IP addresses are assigned to Windows 10 Always On VPN clients from either a static pool of addresses configured by the administrator or by DHCP. If split tunneling is enabled, the client will also be assigned a class-based route that is derived from the IP address assigned to it by the VPN server, by default. If the client is assigned an IP address from the Class A network, a corresponding /8 prefix is used. For Class B networks a /16 prefix is defined, and for Class C networks a /24 prefix is used.

As an example, if the VPN server assigns the client an IP address of 10.21.12.103, a route to the 10.0.0.0/8 network is added to the client’s routing table, as shown here.

Windows 10 Always On VPN Routing Configuration

Complex Networks

This default class-based route is of limited use though, and is only applicable when the internal network is simple and VPN clients are assigned IP addresses from the same subnet class. In the example above, if the entire internal network resides in the 10.0.0.0/8 Class A address space, all resources will be reachable by the VPN client. Any resources in the Class B or Class C subnet ranges would be unreachable without additional configuration.

Route Configuration

To configure routing for Windows 10 Always On VPN clients, first disable the default class-based route by defining the following element in ProfileXML as shown here.

<VPNProfile>
   <NativeProfile>
      <DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
   </NativeProfile>
</VPNProfile>

Next, enable specific routes as needed by defining the following element(s) in ProfileXML. The example below defines routes for all private RFC 1918 networks.

<VPNProfile>
   <Route>
      <Address>10.0.0.0</Address>
      <PrefixSize>8</PrefixSize>
   </Route>
   <Route>
      <Address>172.16.0.0</Address>
      <PrefixSize>12</PrefixSize>
   </Route>
   <Route>
      <Address>192.168.0.0</Address>
      <PrefixSize>16</PrefixSize>
   </Route>
</VPNProfile>

Once implemented, the VPN client’s routing table will appear as shown here.

Windows 10 Always On VPN Routing Configuration

Summary

Proper routing is crucial for ensuring full network connectivity and access to internal resources for Windows 10 Always On VPN clients. When split tunneling is employed, avoid using the default class-based route and instead define specific routes using ProfileXML as required.

Additional Information

Always On VPN Client DNS Server Configuration

Deploying Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Certificate Requirements for SSTP

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN Certificate Requirements for SSTPThe Windows Server 2016 Routing and Remote Access Service (RRAS) is commonly deployed as a VPN server for Windows 10 Always On VPN deployments. Using RRAS, Always On VPN administrators can take advantage of Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP) VPN protocol. SSTP is a Transport Layer Security (TLS) based VPN protocol that uses HTTPS over the standard TCP port 443 to encapsulate and encrypt communication between the Always On VPN client and the RRAS VPN server. SSTP is a firewall-friendly protocol that ensures ubiquitous remote network connectivity. Although IKEv2 is the protocol of choice when the highest level of security is required for VPN connections, SSTP can still provide very good security when implementation best practices are followed.

SSTP Certificate

Since SSTP uses HTTPS for transport, a common SSL certificate must be installed in the Local Computer/Personal/Certificates store on the RRAS VPN server. The certificate must include the Server Authentication Enhanced Key Usage (EKU) at a minimum. Often SSL certificates include both the Server Authentication and Client Authentication EKUs, but the Client Authentication EKU is not strictly required. The subject name on the certificate, or at least one of the Subject Alternative Name entries, must match the public hostname used by VPN clients to connect to the VPN server. Multi-SAN (sometimes referred to as UC certificates) and wildcard certificates are supported.

Always On VPN Certificate Requirements for SSTP

Certification Authority

It is recommended that the SSL certificate used for SSTP be issued by a public Certification Authority (CA). Public CAs typically have their Certificate Revocation Lists (CRLs) hosted on robust, highly available infrastructure. This reduces the chance of failed VPN connection attempts caused by the CRL being offline or unreachable.

Using an SSL certificate issued by an internal, private CA is supported if the CRL for the internal PKI is publicly available.

Key Type

RSA is the most common key type used for SSL certificates. However, Elliptic Curve Cryptography (ECC) keys offer better security and performance, so it is recommended that the SSTP SSL certificate be created using an ECC key instead.

Always On VPN Certificate Requirements for SSTP

To use an ECC key, be sure to specify the use of a Cryptographic Next Generation (CNG) key and select the ECDSA_P256 Microsoft Software Key Storage Provider (CSP) (or greater) when creating the Certificate Signing Request (CSR) for the SSTP SSL certificate.

Always On VPN Certificate Requirements for SSTP

Most public CAs will support certificate signing using ECC and Elliptic Curve Digital Signature Algorithm (ECDSA). If yours does not, find a better CA. 😉

Forward Secrecy

Forward secrecy (sometimes referred to as perfect forward secrecy, or PFS) ensures that session keys can’t be compromised even if the server’s private key is compromised. Using forward secrecy for SSTP is crucial to ensuring the highest levels of security for VPN connections.

To enforce the use of forward secrecy, the TLS configuration on the VPN server should be prioritized to prefer cipher suites with Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

Authenticated Encryption

Authenticated encryption (AE) and authenticated encryption with associated data (AEAD) is a form of encryption that provides better data protection and integrity compared to older block or stream ciphers such as CBC or RC4.

To enforce the use of authenticated encryption, the TLS configuration on the VPN server should be prioritized to prefer cipher suites that support Galois/Counter Mode (GCM) block ciphers.

Important Note: In Windows Server 2016, GCM ciphers can be used with both RSA and ECC certificates. However, in Windows Server 2012 R2 GCM ciphers can only be used when an ECC certificate is used.

SSL Offload

Offloading SSL to a load balancer or application delivery controller (ADC) can be enabled to improve scalability and performance for SSTP VPN connections. I will cover SSL offload for SSTP in detail in a future post.

Summary

SSTP can provide good security for VPN connections when implementation and security best practices are followed. For optimum security, use an SSL certificate with an EC key and optimize the TLS configuration to use forward secrecy and authenticated cipher suites.

Additional Information

Always On VPN ECDSA SSL Certificate Request for SSTP

Always On VPN and Windows Server Routing and Remote Access Service (RRAS)

Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN Certificate Requirements for IKEv2

3 Important Advantages of Always On VPN over DirectAccess

Microsoft SSTP Specification on MSDN

Comparing DirectAccess and NetMotion Mobility

Comparing DirectAccess and NetMotion Mobility With DirectAccess approaching the end of its useful lifetime, many organizations are considering alternative solutions to provide seamless, transparent, always on remote connectivity for their field-based workers. Microsoft is positioning Windows 10 Always On VPN as the replacement for DirectAccess. While it provides many new features that were missing from DirectAccess, it has its own unique limitations and shortcomings.

NetMotion Mobility

Comparing DirectAccess and NetMotion Mobility NetMotion Mobility is an excellent alternative to DirectAccess and Always On VPN, and it has many advantages over both native Microsoft offerings. NetMotion Mobility offers better security and performance. It provides deep visibility with broad client support, and the solution is easier to support than DirectAccess.

Comparing DirectAccess and NetMotion Mobility

If you’d like to learn more about how NetMotion Mobility compares with DirectAccess, you will find detailed comparison information in my Comparing NetMotion Mobility and DirectAccess article series on the NetMotion blog.

Comparing NetMotion Mobility and DirectAccess – Security
Comparing NetMotion Mobility and DirectAccess – Performance
Comparing NetMotion Mobility and DirectAccess – Visibility
Comparing NetMotion Mobility and DirectAccess – Supported Clients
Comparing NetMotion Mobility and DirectAccess – Support

NetMotion Mobility in Action

Watch the following videos to see NetMotion Mobility in action.

NetMotion Mobility Demonstration Video
NetMotion Mobility and Skype for Business Demonstration Video

DirectAccess Alternative

NetMotion Mobility is a premium remote access solution with many of the same characteristics as DirectAccess; seamless, transparent, and always on. It is feature rich with numerous compelling benefits over native Microsoft remote access technologies. Organizations seeking a solution to replace Microsoft DirectAccess would benefit greatly from NetMotion Mobility.

Learn More

If you’d like to learn more about NetMotion Mobility, or if you’d like to evaluate their solution, fill out the form below and I’ll respond with more information.

Always On VPN Client DNS Server Configuration

Always On VPN Client DNS Server ConfigurationDNS server configuration for Windows 10 Always On VPN clients is crucial to ensuring full access to internal resources. For Always On VPN, there are a few different ways to assign a DNS server to VPN clients.

Default DNS Servers

By default, Windows 10 clients use the same DNS server the VPN server is configured to use. This is true even if the VPN client IP address assignment method is DHCP.

Always On VPN Client DNS Server Configuration

There may be some scenarios in which this is not appropriate. For example, if the DNS server is in a DMZ network and is not configured to use internal Active Directory domain DNS servers, clients will be unable to access internal resources.

DNS Server Assignment

To configure Windows 10 Always On VPN clients to use DNS servers other than those configured on the VPN server, configure the DomainNameInformation element in the ProfileXML, as shown here.

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

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

Always On VPN Client DNS Server Configuration

Reference: https://docs.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp

Additional Information

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

Deploying Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Hands-On Training

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 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

%d bloggers like this: