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

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShellWindows 10 Always On VPN and DirectAccess both provide seamless, transparent, always on remote network access for Windows clients. However, Always On VPN is provisioned to the user, not the machine as it is with DirectAccess. This presents a challenge for deployment scenarios that require the VPN connection to be established before the user logs on. To address this issue, Microsoft introduced support for a device tunnel configuration option beginning with Windows 10 version 1709 (Fall creators update).

Prerequisites

To support an Always On VPN device tunnel, the client computer must be running Windows 10 Enterprise or Education version 1709 (Fall creators update). It must also be domain-joined and have a computer certificate with the Client Authentication Enhanced Key Usage (EKU) issued by the organization’s Public Key Infrastructure (PKI).

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

In addition, only the built-in Windows VPN client is supported for Always On VPN device tunnel. Although Windows 10 Always On VPN user connections can be configured using various third-party VPN clients, they are not supported for use with the device tunnel.

VPN ProfileXML

The Always On VPN device tunnel is provisioned using an XML file. You can download a sample VPN ProfileXML file here. Make any changes required for your environment such as VPN server hostnames, routes, traffic filters, and remote address ranges. Optionally include the trusted network detection code, if required. Do not change the protocol type or authentication methods, as these are required.

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

Reference: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config#configure-the-vpn-device-tunnel

Once the ProfileXML file is created, it can be deployed using Intune, System Center Configuration Manager (SCCM), or PowerShell. In this post I’ll cover how to configure Windows 10 Always On VPN device tunnel using PowerShell.

Client Configuration

Download the PowerShell script located here and then copy it to the target client computer. The Always On VPN device tunnel must be configured in the context of the local system account. To accomplish this, it will be necessary to use PsExec, one of the PsTools included in the Sysinternals suite of utilities. Download PsExec here, copy it to the target machine, and then run the following command in an elevated PowerShell command window.

PsExec.exe -i -s C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe

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

Another elevated PowerShell window will open, this one now running in the context of the local system account. In this window, navigate to the folder where you copied the PowerShell script and XML file to. Run the PowerShell script and specify the name of the ProfileXML file, as shown below.

VPN_Profile_Device.ps1 -xmlFilePath .\profileXML_device.XML -ProfileName DeviceTunnel

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

To verify creation of the VPN device tunnel, run the following PowerShell command.

Get-VpnConnection -AllUserConnection

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

Note: Be advised that the ConnectionStatus is always Disconnected. Hopefully this will be addressed by Microsoft in the near future.

Server Configuration

If you are using Windows Server 2012 R2 or Windows Server 2016 Routing and Remote Access Service (RRAS) as your VPN server, you must enable machine certificate authentication for VPN connections and define a root certification authority for which incoming VPN connections will be authenticated with. To do this, open an elevated PowerShell command and run the following commands.

$VPNRootCertAuthority = “Common Name of trusted root certification authority”
$RootCACert = (Get-ChildItem -Path cert:LocalMachine\root | Where-Object {$_.Subject -Like “*$VPNRootCertAuthority*” })
Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -PassThru

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

Summary

Once the Always On VPN device tunnel is configured, the client computer will automatically establish the connection as soon as an active Internet connection is detected. This will enable remote logins for users without cached credentials, and allow administrators to remotely manage Always On VPN clients without requiring a user to be logged on at the time.

Additional Information

Configure Windows 10 VPN Device Tunnel on Microsoft.com

3 Important Advantages of Always On VPN over DirectAccess

5 Things DirectAccess Administrators Should Know About Always On VPN 

Windows 10 Always On VPN and the Future of DirectAccess

Windows 10 Always On VPN Training and Consulting Services

DirectAccess and FIPS Compliant Algorithms for Encryption

DirectAccess administrators may be required to enable Federal Information Processing Standards (FIPS) compliant algorithms for encryption, hashing, and signing on DirectAccess servers to meet certain regulatory and compliance requirements.

DirectAccess and FIPS Compliant Algorithms for Encryption

Performance Impact

Be advised that enabling this setting will disable support for null cipher suites for the IP-HTTPS IPv6 transition technology. This will result in the double encryption of all DirectAccess client communication, which will increase resource consumption on DirectAccess servers. This leads to reduced scalability and degraded performance for all DirectAccess clients, including Windows 8.x and Windows 10.

If enabling FIPS compliant cannot be avoided, additional compute capacity (CPU and memory) should be provisioned. For best results, add additional servers to distribute the workload and improve performance for DirectAccess clients.

Always On VPN

If you’re looking for better security and performance, consider migrating to Windows 10 Always On VPN. Always On VPN fully supports FIPS compliant algorithms without the negative performance impact associated with DirectAccess. If you’d like to learn more about security and Always On VPN, fill out the form below and I’ll get in touch with you.

Additional Resources

Always On VPN and the Future of DirectAccess 

5 Things DirectAccess Administrators Should Know About Always On VPN 

3 Important Advantages of Always On VPN over DirectAccess 

3 Important Advantages of Always On VPN over DirectAccess

3 Important Advantages of Always On VPN over DirectAccess Windows 10 Always On VPN provides seamless and transparent, always on remote network access similar to DirectAccess. The mechanics of how it is delivered and managed are fundamentally different, as I discussed here. Some of these changes will no doubt present challenges to our way of thinking, especially in the terms of client provisioning. However, Always On VPN brings along with it some important and significant advantages too.

No More NLS

A Network Location Server (NLS) is used for inside/outside detection by DirectAccess clients. By design, the NLS is reachable by DirectAccess machines only when they are on the internal network. NLS availability is crucial. If the NLS is offline or unreachable for any reason at all, DirectAccess clients on the internal network will mistakenly believe they are outside the network. In this scenario, the client will attempt to establish a DirectAccess connection even though it is inside. This often fails, leaving the DirectAccess client in a state where it cannot connect to any internal resources by name until the NLS is brought back online.

Always On VPN eliminates the frailty of NLS by using the DNS connection suffix for trusted network detection. When a network connection is established, an Always On VPN connection will not be established if the DNS connection suffix matches what the administrator has defined as the internal trusted network.

Full Support for IPv4

DirectAccess uses IPv6 exclusively for communication between remote DirectAccess clients and the DirectAccess server. IPv6 translation technologies allow for communication to internal IPv4 hosts. While this works for the vast majority of scenarios, there are still many challenges with applications that do not support IPv6.

Always On VPN supports both IPv4 and IPv6, so application incompatibility issues will be a thing of the past! With full support for IPv4, the need for IPv6 transition and translation technologies is eliminated. This reduces protocol overhead and improves network performance.

Infrastructure Independent

3 Important Advantages of Always On VPN over DirectAccess Windows servers are required to implement DirectAccess. Always On VPN can be implemented using Windows servers as well, but it isn’t a hard requirement. Always On VPN is implemented entirely on the Windows 10 client, which means any third-party VPN device can be used on the back end, including Cisco, Checkpoint, Juniper, Palo Alto, Fortinet, SonicWALL, F5, strongSwan, OpenVPN, and others! This provides tremendous deployment flexibility, making it possible to mix and match backend infrastructure if required. For example, a Windows RRAS VPN server with Palo Alto and SonicWALL firewalls could all be implemented at the same time (using the Windows built-in VPN client). Importantly, making changes to VPN infrastructure is much less impactful and disruptive to clients in the field. VPN devices can be upgraded, replaced, and moved internally without requiring corresponding policy changes on the client.

Additional Information

Always On VPN and the Future of Microsoft DirectAccess 

5 Things DirectAccess Administrators Should Know about Always On VPN 

Contact Me

Have questions about Windows 10 Always On VPN? Interested in learning more about this new solution? Fill out the form below and I’ll get in touch with you.

Always On VPN Device Tunnel Configuration Guidance Now Available

Always On VPN Device Tunnel Configuration Guidance Now AvailableWhen Always On VPN is configured for Windows 10, the VPN connection is established automatically when the user logs on to their device. This differs fundamentally from DirectAccess, where the connection is established by the machine, before the user logs on. This subtle but important difference has some important ramifications. For example, it means that a user cannot use Always On VPN until they’ve logged on to their device at least once while connected to the corporate network. DirectAccess doesn’t have this limitation, as a connection to an on-premises domain controller is available to authenticate a new user upon first logon.

Device Tunnel Support

To address this shortcoming with Always On VPN, and to provide better feature parity with DirectAccess, Microsoft introduced an update to Windows 10 in the recent Fall Creators update (v1709) that allows for the configuration of a device tunnel for Windows 10 Always On VPN. Once enabled, the device itself can automatically establish a secure remote connection before the user logs on. This enables scenarios such as device provisioning for new remote users without cached credentials. It also enables support for password reset using CTRL+ALT+DEL.

Manage Out

Device tunnel for Windows 10 Always On VPN also enables important manage out scenarios that DirectAccess administrators have come to rely upon. With a device tunnel configured, administrators can initiate connections to remote connected Always On VPN clients to provide remote management and support, without requiring a user to be logged on at the time.

Requirements

To support an Always On VPN device tunnel, the client must be running Windows 10 Enterprise or Education v1709 or later. The computer must be domain-joined and have a machine certificate installed. Device tunnel can only be configured using the built-in Windows 10 VPN client (no support for third-party clients) and the IKEv2 protocol must be used.

Caveat

When configuring a device tunnel, traffic filters can be implemented to restrict communication to only those internal resources required, such as domain controllers, Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM) servers. However, when traffic filters are used, no inbound traffic to the client is allowed. If manage out is required over the device tunnel, traffic filters cannot be configured. Microsoft expects to remove this limitation in a future update.

Provisioning and Documentation

Configuring and provisioning a Windows 10 Always On VPN device tunnel is similar to the process for the Always On VPN connection itself. A VPN profileXML file is created and then deployed via a Mobile Device Management (MDM) solution such as Microsoft Intune. Optionally, the VPN profileXML can be deployed using SCCM or PowerShell. Additional information about Windows 10 Always On VPN device tunnel configuration, including a sample profileXML and PowerShell script, can be found here.

Additional Resources

Configure a VPN Device Tunnel in Windows 10

Always On VPN and the Future of DirectAccess

5 Things DirectAccess Administrators Should Know about Always On VPN

5 Things DirectAccess Administrators Should Know About Always On VPN

5 Things DirectAccess Administrators Should Know About Always On VPNAs 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

SSL Certificate Considerations for DirectAccess IP-HTTPS

SSL Certificate Considerations for DirectAccess IP-HTTPSDirectAccess uses IPv6 exclusively for communication between the client and server. IPv6 transition technologies are used to support DirectAccess communication over the IPv4 public Internet. One of those IPv6 transition technologies, IP-HTTPS, uses HTTP for encapsulation and SSL/TLS for authentication of the DirectAccess server.

SSL Certificates

When configuring DirectAccess, an SSL certificate must be provided for IP-HTTPS. There are three different types of SSL certificates that can be used.

Public SSL Certificate – Using an SSL certificate signed by a public certification authority (CA) is the recommended best practice for configuring DirectAccess IP-HTTPS. This provides the highest level of assurance for DirectAccess clients connecting via IP-HTTPS.

Private SSL Certificate – Using an SSL certificate issued by the organization’s internal CA is an acceptable alternative to using a public SSL certificate in most cases. This can reduce the cost associated with obtaining the certificate, especially for multisite deployments.

Self-Signed Certificate – Using a self-signed certificate is not recommended and should be avoided in most deployment scenarios. A self-signed certificate provides no real assurance for DirectAccess clients. Crucially, using a self-signed certificate will disable support for null SSL and TLS cipher suites. This reduces the overall scalability and performance of the remote access solution.

SSL Certificate Considerations for DirectAccess IP-HTTPS

Figure 1. Null cipher suites not supported when using a self-signed SSL certificate for IP-HTTPS.

Certificate Requirements

The SSL certificate must include the Server Authentication (1.3.6.1.5.5.7.3.1) Enhanced Key Usage (EKU) Object Identifier (OID). It should use an RSA key of 2048 bits and be signed with SHA256. Using stronger keys provides no additional protection and should not be used. In addition, SSL certificates using ECDSA keys is not recommended, as they do not support null cipher suites.

Summary

In most cases, using a public SSL certificate is ideal. However, issuing a certificate from a private CA is also acceptable. Using self-signed certificates can be used for non-production testing and in very small production deployments, but should generally be avoided.

Additional Resources

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

Microsoft Ignite Conference 2017

Will you be attending the Microsoft Ignite conference in Orlando, FL next week? Let’s connect! I’m not giving any talks this year, so I will be spending most of my time with the folks at Pointsharp in their booth in the expo hall. Want to talk security, remote access, multifactor authentication, load balancing/application delivery, PKI, or anything else? Stop by and say hi! Follow me on Twitter @richardhicks for live updates. In addition, I’ll be hosting a happy hour event with NetMotion on Tuesday, September 26 at 6PM at the Rocks lounge in the Hyatt Regency hotel just across the street from the conference center. Be sure to drop in and say hello! Hope to see you there!

Microsoft Ignite 2017

DirectAccess and NetMotion Mobility Webinar

Update: You can view the on-demand recording of this webinar here.

DirectAccess on Windows Server 2016 CoreFor many years, DirectAccess has been the gold standard for enterprise remote access. Its seamless and transparent operation improves productivity for mobile workers, and since it is always on, administrators enjoy improved visibility and management for their field-based assets.

As incredible as DirectAccess is, it is not without its limitations. For example, DirectAccess works only with Windows Enterprise edition clients that are joined to the domain. Professional Edition and non-domain joined machines are not supported. It also lacks many of the security features enterprise organizations require, such as device health checks and granular network access. In addition, DirectAccess communication is complex, with many different layers of encapsulation, authentication, and encryption. High protocol overhead can lead to poor performance over high latency or low bandwidth connections.

NetMotion Mobility as an Alternative to DirectAccessNetMotion Mobility is a secure remote access solution that is an excellent alternative to DirectAccess. It provides the same seamless, transparent, always on remote connectivity that DirectAccess provides, while at the same time offering much more in terms of features and capabilities. It supports a much broader range of clients, includes native Network Access Control (NAC) and application filtering, and offers enhanced performance.

To learn more about NetMotion Mobility, join me on Wednesday, September 20 at 10:00AM PDT for a free live webinar with NetMotion. I’ll provide an overview of NetMotion Mobility and how it compares with DirectAccess. I’ll also demonstrate how it can help overcome some of the inherent limitations of DirectAccess too. Register today!

DirectAccess and NetMotion Mobility Webinar

DirectAccess on Windows Server 2016 Core

DirectAccess on Windows Server 2016 CoreDeploying DirectAccess on Windows Server 2016 core is recommended to ensure the highest level of security and availability for the remote access solution. Server core is a stripped-down, command-line only version of Windows that removes many features unnecessary to support common server workloads. It’s reduced attack surface improves security, and this leaner version of the Windows OS requires less maintenance (patching), resulting in fewer reboots which increases overall availability. It has a smaller disk and memory footprint too which results in quicker system restarts, when required.

Removing the GUI

Historically I’ve recommended that DirectAccess administrators deploy Windows server with the full GUI first, then remove it later after validation testing is complete. Prior to placing it in production, the GUI can be removed by running the following PowerShell command.

Uninstall-WindowsFeature Server-Gui-Mgmt-Infra -Restart

This works flawlessly in Windows Server 2012 and Windows Server 2012 R2. However, when running this command on a Windows Server 2016 server you will receive the following error message.

Uninstall-WindowsFeature : ArgumentNotValid: The role, role service, or feature name is not valid:
‘Server-Gui-Mgmt-Infra’. The name was not found.

DirectAccess on Windows Server 2016 Core

Changes in Windows Server 2016

This happens because Microsoft quietly removed the option to switch back and forth between the full GUI version and the core version of Windows beginning with Windows Server 2016.

DirectAccess on Windows Server 2016 Core

Source: https://docs.microsoft.com/en-us/windows-server/get-started/getting-started-with-server-core

It is still recommended that DirectAccess be deployed on server core to provide the most secure and reliable experience. However, since it is no longer possible to switch from GUI to core, it must be deployed in serve core configuration upon initial installation.

Additional Information

DirectAccess and Windows Server 2012 R2 Core

Configure Windows Server Core to use PowerShell by Default

Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course

Managing and Supporting DirectAccess with Windows Server 2016 Video Training Course

Implementing DirectAccess with Windows Server 2016 Book

NetMotion Mobility as an Alternative to DirectAccess

Learn more about NetMotion Mobility by registering for my free live webinar here!

NetMotion Mobility as an Alternative to DirectAccessAs I outlined in a recent blog post, there has been much speculation surrounding the end of life for Microsoft DirectAccess. This is not surprising, as Microsoft has not made any investments in DirectAccess since the introduction of Windows Server 2012. Recently, Microsoft began promoting its Always On VPN solution as an alternative for DirectAccess. While DirectAccess has not been formally deprecated, Microsoft is actively encouraging organizations considering DirectAccess to deploy Always On VPN instead, as indicated here.

NetMotion Mobility as an Alternative to Microsoft DirectAccess

Source: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-top#advanced-vpn-connectivity

DirectAccess Alternatives

It’s important to state that, at the time of this writing, DirectAccess is still fully supported in Windows 10 and Windows Server 2016 and will be for quite some time. However, the future for DirectAccess is definitely limited, and customers should start considering alternative remote access solutions.

Always On VPN

Microsoft is positioning Always On VPN as the replacement for DirectAccess. Always On VPN offers some important new capabilities missing from DirectAccess. For example, Always On VPN supports all Windows 10 client SKUs, not just Enterprise and Education as DirectAccess does. Always On VPN includes important security enhancements such as conditional access with system health checks, access control list (ACL) enforcement per device and per application, and more.

Always On VPN Limitations

But Always On VPN has some serious limitations too. For example, Always On VPN works only with Windows 10. Windows 7 is not supported at all. Managing and supporting Always On VPN has its own challenges. It cannot be managed using Active Directory and group policy in the traditional way. You must use System Center Configuration Manager (SCCM), Intune, or PowerShell to configure and manage VPN clients.

NetMotion Mobility

I’m excited to announce I’ve recently partnered with NetMotion to provide their secure remote access solutions to organizations looking for alternatives to DirectAccess and Always On VPN. NetMotion Mobility provides the same seamless and transparent, always on remote access with some additional important features not included in DirectAccess and Always On VPN.

Broad Client Support – NetMotion Mobility can provide DirectAccess-like remote access for all versions and SKUs of Windows as well as Mac, iOS (iPhone and iPad), and Android.

Enhanced Security – NetMotion Mobility includes fine-grained policy enforcement to restrict network access based on a wide range of parameters including IP address, protocol, port, application, time of day, location, and type of network (e.g. wired, Wi-Fi, wireless, etc.). NetMotion Mobility also includes integrated Network Access Control (NAC) to validate device configuration prior to connecting, ensuring the highest level of security for remote endpoints. More details here and here.

Improved Performance – NetMotion Mobility client to server communication is optimized to improve reliability and performance. Network traffic is compressed and prioritized to ensure optimum performance for critical applications. Session persistence allows mobile workers to remain connected during times of poor connectivity or when roaming between different networks. More details here.

Greater Visibility – NetMotion Mobility provides a wealth of detailed information to perform analysis and troubleshooting for remote connections. Performance and diagnostic information is logged in real-time and provides administrators with crucial data and insight to quickly identify and resolve connectivity issues. More details here.

Better Supportability – NetMotion Mobility is supported by dedicated, highly trained support engineers with deep product experience. NetMotion support is not tiered. The support engineer who answers the phone will handle the case until resolution.

Learn More about NetMotion

NetMotion Mobility is a truly comprehensive remote access solution and an excellent alternative to DirectAccess. To learn more about NetMotion Mobility and to see it in action, fill out the form below and I’ll get in touch with you. You can also register for my upcoming free live webinar here.

Additional Information

Webinar: Comparing DirectAccess and NetMotion Mobility

Always On VPN and the Future of DirectAccess

NetMotion and DirectAccess Comparison Whitepaper

NetMotion and Skype for Business demonstration video

NetMotion Website

%d bloggers like this: