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

Upcoming DirectAccess Training Events in 2015

Did you attend the DirectAccess session at this year’s Microsoft Ignite conference? Of course not. There wasn’t one! Not to worry though, as I will be presenting DirectAccess sessions at several different events around the country later this year.

Techmentor ConferenceIf you’re looking for deep-dive DirectAccess training, I’ll be delivering a three-hour training session at the TechMentor Conference in Redmond, WA. The event takes place August 3-7, 2015. Don’t forget to use registration code TMRSK05 to save $500.00! If you are on the east coast of the U.S. you’ll be happy to hear that I will also be presenting a DirectAccess session at the TechMentor Conference to be held at the Royal Pacific Resort at Universal in Orlando, FL, from November 16-20. I’ll provide more details on this event soon.

IT Dev ConnectionsIn addition I will be delivering a few DirectAccess sessions at IT/Dev Connections in Las Vegas, NV. I’ll be covering topics such as DirectAccess design and configuration, as well as implementation tips, tricks, and best practices. This event will be held at the Aria Hotel and Resort from September 14-17, 2015.

Hope to see you at one of these great events this year!

Microsoft Most Valuable Professional (MVP) 2013

I’m excited to announce that I have been awarded the Microsoft Most Valuable Professional (MVP) award for 2013! This marks my fifth consecutive year receiving this valuable distinction from Microsoft. It really is a privilege to be associated with so many great professionals that are a part of the program. I’m looking forward to seeing all of my fellow MVP’s at the summit in November!

Windows Server 2012 DirectAccess Simplified Deployment Limitations

A lot has been written about the new capabilities of DirectAccess in Windows Server 2012. One of the most talked about features is the new Simplified Deployment model for DirectAccess. In this deployment scenario, once an administrator installs the Remote Access role and supporting features it can be configured with just three mouse clicks. That’s it! Does that sound too good to be true? In some instances, perhaps it is. Although this simplified deployment model is, well, very simple, it does have some limitations. Before we discuss those limitations, let’s examine specifically what the simplified DirectAccess deployment model entails.

After installing the Remote Access role using the Windows Server 2012 server manager or PowerShell, the administrator is prompted to complete post-deployment configuration. After launching the Configure Remote Access Getting Started Wizard you can choose to deploy DirectAccess, VPN, or both. Selecting Deploy DirectAccess only (first click) allows you to choose your network topology configuration (edge, perimeter, single or multiple network adapters) and enter the name or IP address that clients will use to connect to the remote access server (second click). After that, click Finish to save and apply the configuration settings (third click). That’s it! You’ve configured DirectAccess!

So, what does the configuration wizard do? First, it creates the Group Policy Objects (GPOs) to apply all of the DirectAccess-related settings to the DirectAccess server and clients. This includes information for configuring the DirectAccess client’s Windows Firewall with Advanced Security (WFAS) used to establish DirectAccess IPsec tunnels, such as the external IP address or hostname used to reach the DirectAccess gateway, and internal namespace information for use by the Name Resolution Policy Table (NRPT). By default it will configure settings to apply all mobile computers in the Domain Computers security group. The DirectAccess deployment wizard will also configure the DirectAccess server to host the Network Location Server (NLS) to be used by DirectAccess clients to determine corporate network connectivity. It will also generate a self-signed certificate for use by the IP-HTTPS listener, which is used by DirectAccess clients using the IP-HTTPS transition protocol. In addition, DNS64 and NAT64, the protocol translators that are used to enable DirectAccess clients (which communicate using IPv6 exclusively) to communicate with IPv4-only hosts, are configured and enabled on the DirectAccess server.

One of the main advantages to using this simplified deployment model for DirectAccess in Windows Server 2012 are the reduced infrastructure requirements. The simplified deployment model for Windows Server 2012 DirectAccess does not require a Public Key Infrastructure (PKI) and eliminates the need for IPv6 to be deployed on your Intranet. The simplified DirectAccess deployment model also removes the requirement for two consecutive public IPv4 addresses, now allowing the DirectAccess server to be deployed in a perimeter network behind an existing border router or edge firewall performing Network Address Translation (NAT). Deploying the DirectAccess server with a single network interface is also supported in the simplified deployment model.

As I mentioned earlier there are some limitations imposed when implementing Windows Server 2012 DirectAccess using the simplified deployment model. For example, simplified deployment supports only Windows 8 clients. If you need to support Windows 7 clients for DirectAccess on Windows Server 2012, the simplified deployment model won’t work. In addition the simplified deployment model does not provide support for multi-site configurations, forced tunneling, or strong authentication via smartcard, certificate, or One-Time Password (OTP). NAP integration is also not supported in the simplified deployment model. If any of these are requirements for your organization, the simplified deployment model isn’t for you.

By default the DirectAccess Getting Started Wizard will configure DirectAccess using the simplified deployment model. If you need to deploy DirectAccess to support any of the scenarios for which the simplified deployment model doesn’t support, then DO NOT click the Open the Getting Started Wizard link in the Post-deployment Configuration window.

Instead, in the Server Manager select Tools and then Remote Access Management and click the Run the Remote Access Setup Wizard link.

The Remote Access Setup Wizard can then be used to configure DirectAccess with custom settings to meet your specific requirements, such as enabling forced tunneling, configuring strong authentication, defining the use of an internal PKI, extending support to Windows 7 clients, leveraging a dedicated internal web server for the Network Location Server (NLS), or configuring NAP integration.

%d bloggers like this: