Always On VPN at TechMentor Redmond 2018

Always On VPN at TechMentor Redmond 2018I’m pleased to announce I’ll be presenting at the upcoming TechMentor 2018 conference is Redmond, Washington. It will be held on the Microsoft campus August 6-10, 2018. I’ll be giving a talk on Windows 10 Always On VPN for DirectAccess administrators. During this session you’ll learn about the features and capabilities in Always On VPN, how to map existing DirectAccess functionality to Always On VPN, and how to provision clients using Microsoft Intune. I will also share implementation and security best practices, along with DirectAccess to Always On VPN migration guidance.

Always On VPN at TechMentor Redmond 2018

Register today with code RDSPK10 and save $500.00! I hope you’ll join me in Redmond this year for this exceptional learning opportunity. TechMentor provides in-depth, immediately useable education that will absolutely make your life easier!

Deploying Windows 10 Always On VPN with Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft IntuneWindows 10 Always On VPN is the replacement for Microsoft’s popular DirectAccess remote access solution. It provides the same seamless, transparent, always on remote connectivity as DirectAccess. Where DirectAccess relied heavily on classic on-premises infrastructure such as Active Directory and Group Policy, Always On VPN is infrastructure independent and is designed to be provisioned and managed using a Mobile Device Management (MDM) platform such as Microsoft Intune.

Intune and Always On VPN

Until recently, provisioning Windows 10 Always On VPN connections involved manually creating a ProfileXML and uploading to Intune using a custom profile. This has proven to be challenging for many, as the process is unintuitive and error prone.

A recent Intune update now allows administrators to create a basic Windows 10 Always On VPN deployment. Although it still has its limitations, it will go a long way to making the adoption of Always On VPN easier.

Prerequisites

Certificates must first be provisioned to all clients before deploying Windows 10 Always On VPN using Intune. In addition, if using a third-party VPN client, the VPN plug-in software must be installed prior to deploying the VPN profile.

Test VPN Connection

It is recommended that a test VPN connection be created on a client machine locally before deploying an Always On VPN profile using Intune. This allows the administrator to test connectivity and validate Extensible Authentication Protocol (EAP) settings. Once complete, run the following PowerShell commands to extract the EAP configuration settings to a file for later publishing with Intune.

$Vpn = Get-VpnConnection -Name [Test VPN connection name]
$Xml = $Vpn.EapConfigXmlStream.InnerXml | Out-File .\eapconfig.xml -Encoding ASCII

Deploying Always On VPN with Intune

Follow the steps below to deploy an Always On VPN connection using Intune.

Create a VPN Profile

  1. Open the Microsoft Intune management portal.
  2. Click Device configuration.
  3. Click Profiles.
  4. Click Create profile.

Deploying Windows 10 Always On VPN with Microsoft Intune

  1. Enter a name for the VPN profile.
  2. Enter a description (optional).
  3. From the Platform drop-down menu select Windows 10 and later.
  4. From the Profile type drop-down menu select VPN.
  5. In the Settings section click Configure.

Deploying Windows 10 Always On VPN with Microsoft Intune

Define VPN Profile Settings

  1. Click Base VPN.
  2. Enter a name for the connection.
  3. Enter a description and provide the Fully Qualified Domain Name (FQDN) of the VPN server. If it will be the default server select True and click Add.
  4. Enter a description and provide the FQDN for any additional VPN servers, as required.
  5. From the Connection type drop-down list choose the preferred connection type.
  6. In the Always On section click Enable.
  7. Select Enable to Remember credentials at each logon (optional).
  8. Click Select a certificate.
  9. Choose a client authentication certificate and click Ok.
  10. Paste the contents of eapconfig.xml (saved previously) in the EAP Xml field.
  11. Click Ok.

Deploying Windows 10 Always On VPN with Microsoft Intune

Define Additional Settings

You can also configure the following optional VPN settings using Intune.

  • Apps and Traffic Rules
  • Conditional Access
  • DNS Settings
  • Proxy
  • Split Tunneling

Deploying Windows 10 Always On VPN with Microsoft Intune

After configuring any required additional settings, click Create.

Assign VPN Profile

  1. Click Assignments.
  2. From the Assign to drop-down menu choose Selected Groups.
  3. Click Select groups to include.
  4. Choose an Azure Active Directory group to apply the VPN profile and click Select.
  5. Click Save.

Deploying Windows 10 Always On VPN with Microsoft Intune

Limitations

Although the ability to provision Always On VPN using Microsoft Intune without using a custom profile is welcome, it is not without its limitations. At the time of this writing, only Always On VPN user profiles can be configured. A device tunnel, which is optional, must be configured manually using a custom profile. In addition, the Intune user interface lacks the ability to define settings for the following parameters:

  • Exclusion routes
  • Name Resolution Policy Table (NRPT) exemptions
  • Lockdown mode
  • DNS registration
  • Trusted network detection
  • Custom IKEv2 cryptography policy

To make changes to the default settings for any of the above parameters, a ProfileXML must be created manually and provisioned with Intune using a custom policy.

Additional Information

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

Windows 10 Always On VPN Certificate Requirements for IKEv2

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

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 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. It has been resolved 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

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

 

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

%d bloggers like this: