All posts tagged PowerShell

Always On VPN Short Name Access Failure

Using Microsoft Endpoint Manager (Intune), administrators can provision Always On VPN to devices that are Azure AD joined only. Users accessing on-premises resources from these devices can still use seamless single sign-on, making this deployment option popular for organizations moving to the cloud.

Short Names

After deploying Always On VPN to Windows 10 devices that are Azure AD joined only and configured to use client certificate authentication, administrators may find that users cannot access on-premises resources by their short name, such as \\app1. The connection fails and returns the following error message.

“Windows can’t find <servername/sharename>. Check the spelling and try again.”

FQDN

Interestingly, on-premises resources are accessible using their fully qualified domain name (FQDN), such as \\app1.corp.example.net.

Troubleshooting

Testing name resolution using the short name works as expected, and the resource is reachable at the network layer, as shown here.

Workaround

This issue is related to how Windows performs authentication when connected via VPN. To resolve this issue, edit the rasphone.pbk file and change the value of UseRasCredentials to 0. Rasphone.pbk can be found in the $env:AppData\Microsoft\Network\Connections\Pbk folder.

After updating this setting, restart the VPN connection for the change to take effect.

Proactive Remediations

While helpful for testing, editing rasphone.pbk manually obviously does not scale well. To address this, consider using Intune Proactive Remediations. Intune Proactive Remediations allows administrators to deploy detection and remediation PowerShell scripts to monitor specific settings and update them if or when they change. Proactive Remediations will ensure the setting is applied consistently across all managed endpoints.

GitHub Repository

I have created a new GitHub repository dedicated to PowerShell scripts for Endpoint Manager Proactive Remediations for Always On VPN. There you will find detection and remediation scripts for the UseRasCredentials settings change described in this article.

Additional Information

Always On VPN Endpoint Manager Proactive Remediation Scripts on GitHub

Endpoint Manager Proactive Remediations Tutorial

6 Comments

by Richard M. Hicks on September 20, 2021 • Permalink

Posted by Richard M. Hicks on September 20, 2021

https://directaccess.richardhicks.com/2021/09/20/always-on-vpn-short-name-access-failure/

Always On VPN SSTP Security Configuration

When using Windows Server Routing and Remote Access Service (RRAS) to terminate Always On VPN client connections, administrators can leverage the Secure Socket Tunneling Protocol (SSTP) VPN protocol for client-based VPN connections. SSTP is a Microsoft proprietary VPN protocol that uses Transport Layer Security (TLS) to secure connections between the client and the VPN gateway. SSTP provides some crucial advantages over IKEv2 in terms of operational reliability. It uses the TCP port 443, the standard HTTPS port, which is universally available and ensures Always On VPN connectivity even behind highly restrictive firewalls.

TLS Certificate

When configuring SSTP, the first thing to consider is the certificate installed on the server. A certificate with an RSA key is most common, but for SSTP, provisioning a certificate with an ECDSA key is recommended for optimal security and performance. See the following two articles regarding SSTP certificate requirements and ECDSA Certificate Signing Request (CSR) creation.

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN ECDSA SSL Certificate Request for SSTP

TLS Configuration

Much like IKEv2, the default TLS security settings for SSTP are less than optimal. However, SSTP can provide excellent security with some additional configuration.

TLS Protocols

There are several deprecated TLS protocols enabled by default in Windows Server. These include SSLv3.0, TLS 1.0, and TLS 1.1. They should be disabled to improve security for TLS. To do this, open an elevated PowerShell window on the VPN server and run the following commands.

New-Item -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server\’ -Force

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server\’ -Name Enabled -PropertyType DWORD -Value ‘0’

New-Item -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server\’ -Force

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server\’ -Name Enabled -PropertyType DWORD -Value ‘0’

New-Item -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server\’ -Force

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server\’ -Name Enabled -PropertyType DWORD -Value ‘0’

Cipher Suites

Many weak TLS cipher suites and enabled by default in Windows Server. To further enhance security and performance, they can be optimized using a tool such as IIS Crypto. For example, consider prioritizing cipher suites that use ECDHE and GCM with ECDSA to improve security. Also, remove ciphers that use AES-256 to enhance scalability and performance.

Note: AES-256 does not provide any additional practical security over AES-128. Details here.

PowerShell Script

I have published a PowerShell script on GitHub that performs security hardening and TLS cipher suite optimization to streamline the configuration TLS on Windows Server RRAS servers. You can download the script here.

Validation Testing

After running the script and restarting the server, visit the SSL Labs Server Test site to validate the configuration. You should receive an “A” rating, as shown here.

Note: An “A” rating is not achievable on Windows Server 2012 or Windows Server 2012 R2 when using an RSA TLS certificate. A TLS certificate using ECDSA is required to receive an “A” rating on these platforms.

Additional Information

Always On VPN SSL/TLS Certificate Requirements for SSTP

Always On VPN ECDSA SSL Certificate Request for SSTP

Qualys SSL Labs Server Test Site

Always On VPN Protocol Recommendations for Windows Server RRAS

Microsoft SSTP Specification on MSDN

2 Comments

by Richard M. Hicks on June 21, 2021 • Permalink

Tagged Always On VPN, cryptography, ECDSA, Microsoft, Mobility, PowerShell, Remote Access, routing and remote access service, RRAS, RSA, Secure Socket Tunneling Protocol, security, SSL, SSTP, TLS, VPN, Windows, Windows 10, Windows Server

Posted by Richard M. Hicks on June 21, 2021

https://directaccess.richardhicks.com/2021/06/21/always-on-vpn-sstp-security-configuration/

Always On VPN and Autopilot Hybrid Azure AD Join

Windows Autopilot is a cloud-based technology that administrators can use to configure new devices wherever they may be, whether on-premises or in the field. Devices provisioned with Autopilot are Azure AD joined by default and managed using Microsoft Endpoint Manager. Optionally, an administrator can enable hybrid Azure AD join by also joining the device to an on-premises Active Directory domain using a domain join configuration profile in conjunction with the offline domain-join connector. Although enabling hybrid Azure AD join might sound appealing, there are specific deployment scenarios that present some rather unique and challenging problems when using this option.

Offline Hybrid Azure AD Join

For field-based devices, the device must have connectivity to a domain controller to support the initial login when the user has no local cached credentials. The Always On VPN device tunnel can be deployed in this scenario to provide connectivity and allow the user to log in to a new device the first time without being on-premises. The Always On VPN device tunnel is easily deployed using a Microsoft Endpoint Manager configuration profile. Certificates required to support the device tunnel can be deployed with Microsoft Endpoint Manager and one of the certificate connectors for Microsoft Endpoint Manager.

Windows 10 Professional

If a Windows 10 Professional device is configured using Autopilot, and hybrid Azure AD joined is enabled, the Always On VPN device tunnel can still be provisioned, but it won’t start automatically because it requires Enterprise Edition to be fully functional. This prevents the user from being able to logon the first time. The device must be upgraded to Enterprise Edition before the first user logon. There are multiple ways to accomplish this depending on the deployment scenario and activation requirements.

Multiple Activation Key

The easiest way to upgrade Windows 10 Professional to Enterprise Edition is to obtain a Multiple Activation Key (MAK) and deploy that to clients using a Microsoft Endpoint Manager configuration profile. Follow the steps below to create a configuration profile to perform this upgrade.

Open the Microsoft Endpoint Manager console and click on Devices > Configuration Profiles.
Click Create profile.
Select Windows 10 and later in the Platform drop-down list.
Select Templates in the Profile type drop-down list.
Select Edition upgrade and mode switch from the list of templates.
Click Create.

Use the following steps to configure the settings for the configuration profile.

Enter a descriptive name for the configuration profile in the Name field.
Enter a description for the profile in the Description field (optional).
Click Next.
Expand the Edition Upgrade section and select Windows 10 Enterprise from the Edition to upgrade to drop-down list.
Enter your multiple activation product key in the Product Key field.

Once complete, assign the configuration profile to the appropriate groups and click Create.

KMS Activation

If Key Management Service (KMS) activation is required, follow the steps listed previously for MAK. Enter the KMS client setup key for Windows 10 Enterprise which is NPPR9-FWDCX-D2C8J-H872K-2YT43. The device will complete KMS activation when it can connect to the on-premises KMS host.

Subscription Activation

Windows 10 Enterprise Edition licensing is included in some Microsoft 365 subscriptions. This poses a unique challenge for hybrid Azure AD join scenarios, however. Specifically, subscription activation is a “step-up” process that requires Windows 10 Professional to have been successfully activated previously. Also, this occurs after the user logs on, but the user cannot log on unless the device tunnel is active. Catch 22!

Workaround

A multi-step process is required to address the limitations imposed by subscription activation. To begin, the device must be upgraded to Enterprise Edition, so the device tunnel is available for the initial user logon. This is a temporary, one-time upgrade to Enterprise Edition solely for the purpose of getting the device tunnel to connect and allow the user to authenticate.

To begin, download this PowerShell script and follow the steps below to deploy it to Windows 10 devices using Microsoft Endpoint Manager.

Open the Microsoft Endpoint Manager console and click on Devices > Scripts.
Click Add and select Windows 10.
Enter a descriptive name for the configuration profile in the Name field.
Enter a description for the profile in the Description field (optional).
Click Next.
Enter the location of the PowerShell script in the Script location field.
Click Next, then assign the script to the appropriate device group(s) and click Add.

The PowerShell script will automatically install the KMS client setup key for Windows 10 Enterprise Edition, then restart the network interfaces to ensure the device tunnel starts. This will immediately upgrade the client device to Windows 10 Enterprise Edition and allow the user to authenticate.

Subscription activation with a step-up upgrade to Enterprise Edition still requires that Windows 10 Professional be activated first. To accomplish this, the embedded Windows 10 Professional key must be re-installed on the client. To do this, download this PowerShell script and follow the same steps listed previously to deploy a PowerShell script with Microsoft Endpoint Manager. However, this script should be assigned to users, not devices.

Once this script is run on the client it will be downgraded (temporarily) to Windows 10 Professional edition. After activation is successful, subscription activation will once again upgrade the client to Windows 10 Enterprise Edition.

Considerations

As you can see, the process of getting a Windows 10 Professional edition client onboarded in a hybrid Azure AD joined scenario is somewhat complex. My advice is to avoid this scenario whenever possible. Access to on-premises resources with the Always On VPN user tunnel with full single sign-on support is still available for users on Windows 10 devices that are Azure AD joined only. Unless there is a specific requirement to manage client devices using on-premises Active Directory and group policy, consider choosing native Azure AD join with Autopilot and manage devices using Microsoft Endpoint Manager exclusively.

Special Thanks

I would like to extend a special thank you to everyone in the Microsoft Endpoint Manager community who provided valuable input and feedback for me on this topic, especially John Marcum, Michael Niehaus, and Sandy Zeng. Follow the #MEMCM hashtag on Twitter to keep up on all things Microsoft Endpoint Manager.

Additional Information

Overview of Windows Autopilot

Windows 10 Subscription Activation

Windows 10 Always On VPN Class-Based Default Route and Microsoft Endpoint Manager

Windows 10 Always On VPN Device Tunnel and Custom Cryptography in Microsoft Endpoint Manager

8 Comments

by Richard M. Hicks on April 19, 2021 • Permalink

Posted by Richard M. Hicks on April 19, 2021

https://directaccess.richardhicks.com/2021/04/19/always-on-vpn-and-autopilot-hybrid-azure-ad-join/

Always On VPN Class-Based Default Route and Intune

In a recent post, I described how to configure routing for Windows 10 Always On VPN clients. In that article, I shared guidance for disabling the class-based default route in favor of defining specific routes for the VPN client. While this is easy enough to do when you use custom XML (deployed via PowerShell, SCCM, or Intune), there is a known limitation when using the native Intune UI that could present some challenges.

Intune VPN Profile Configuration

Defining specific routes is easy to do in Intune using the native VPN configuration profile. In the Configuration settings expand Split Tunneling and click Enable. The administrator can then add routes by entering their Destination prefix and Prefix size, as shown here.

Class-Based Default Route

The limitation with using Intune to configure routes is that there is currently no option to disable the class-based default route as there is with custom XML. This means the routes shown in the example above will be added to the client, but the class-based route will also be added automatically, as shown here (class-based default route highlighted with the arrow).

Considerations

In most cases, the inclusion of the class-based default route along with the administrator-defined routes will not be a problem. However, in some scenarios, it could yield unexpected results. Specifically, Always On VPN clients may have unintended access to some networks over the VPN tunnel. This is most significant for the Always On VPN device tunnel, where it is common to limit access to only specific resources using individual host routes.

Workaround

Today there is no option to disable the class-based default route using the native Intune UI. Your only option is to deploy the Always On VPN profile using custom XML, as described here.

Additional Information

Deploying Windows 10 Always On VPN with Intune and Custom XML

Deploying Windows 10 Always On VPN Device Tunnel with Intune and Custom XML

Windows 10 Always On VPN Routing Configuration

Windows 10 Always On VPN Device Tunnel Operation and Best Practices

4 Comments

by Richard M. Hicks on March 4, 2021 • Permalink

Posted in Always On VPN, AOVPN, device tunnel, Enterprise, enterprise mobility, InTune, MEMCM, Microsoft Endpoint Manager, Microsoft Intune, Mobility, Operational Support, PowerShell, public cloud, Remote Access, split tunnel, split tunneling, user tunnel, VPN, Windows 10

Posted by Richard M. Hicks on March 4, 2021

https://directaccess.richardhicks.com/2021/03/04/always-on-vpn-class-based-default-route-and-intune/

Always On VPN Windows Server RRAS Service Does Not Start

Administrators configuring a Windows Server Routing and Remote Access Service (RRAS) server to support Windows 10 Always On VPN connections may encounter an issue where the RemoteAccess service fails to start. Attempts to start the service might seem to work at first, but the service immediately stops again.

Troubleshooting

On the RRAS server, the Services management console (services.msc) or PowerShell Get-Service command shows the RemoteAccess service as being stopped. Attempts to start the service result in failure.

Event Log

Looking at the System event log on the RRAS server shows an error with event ID 7024 from the Service Control Manager source indicating “The Routing and Remote Access service terminated with the following service-specific error: A device attached to the system is not functioning.”

Resolution

This issue is commonly caused when IPv6 is disabled on the server via the registry. To verify, open the registry editor on the RRAS server and navigate to the following location.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters

If the DisabledComponents value is present and set to anything other than 0, set it to 0 or simply delete the DisabledComponents value completely and reboot the server.

The following PowerShell command can be used to remove the DisabledComponents value.

Remove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters -Name DisabledComponents

Additional Information

Guidance for Configuring IPv6 in Windows for Advanced Users (Microsoft)

4 Comments

by Richard M. Hicks on January 11, 2021 • Permalink

Posted in Always On VPN, AOVPN, Enterprise, enterprise mobility, IPv6, PowerShell, Remote Access, routing and remote access service, RRAS, VPN, Windows 10, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019

Tagged Always On VPN, AOVPN, enterprise mobility, event ID 7024, event log, IPv6, Microsoft, Mobility, PowerShell, Remote Access, routing and remote access service, RRAS, troubleshooting, VPN, Windows, Windows 10, Windows Server

Posted by Richard M. Hicks on January 11, 2021

https://directaccess.richardhicks.com/2021/01/11/always-on-vpn-windows-server-rras-service-does-not-start/

Always On VPN IPsec Root Certificate Configuration Issue

When configuring a Windows Routing and Remote Access Service (RRAS) server to support Internet Key Exchange version 2 (IKEv2) VPN connections, it is essential for the administrator to define the root certification authority for which to accept IPsec security associations (SAs). Without defining this setting, the VPN server will accept a device certificate issued by any root certification authority defined in the Trusted Root Certification Authorities store. Details about configuring IKEv2 security and defining the root certification authority can be found here.

Multiple Root Certificates

Administrators may find that when they try to define a specific root certification authority, the setting may not be implemented as expected. This commonly occurs when there is more than one root certificate in the Trusted Root Certification Authorities store for the same PKI.

Certificate Selection

When running the PowerShell command Set-VpnAuthProtocol to define the root certification authority, PowerShell may ignore the administrator-defined certificate and choose a different one, as shown here. This will result in failed IPsec VPN connections from Windows 10 Always On VPN clients using IKEv2.

Certificate Publishing

This issue can occur when root certification authority certificates are published using Active Directory group policy. It appears that Windows prefers Active Directory group policy published certificates over those published directly in the Certification Authorities Container in Active Directory. To resolve this issue, remove any group policy objects that are publishing root certification authority certificates and ensure those root certificates are published in the Certification Authorities container in Active Directory.

PowerShell Script

A PowerShell script to configure this setting that can be found in my Always On VPN GitHub repository here. I have updated this script to validate the defined root certification authority certificate and warn the user if it does not match.

Additional Information

Set-Ikev2VpnRootCertificate.ps1 PowerShell script on GitHub

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Certificate Requirements

Always On VPN Device Tunnel Status Indicator

I’ve written many articles about the Windows 10 Always On VPN device tunnel over the years. If you are not familiar with the device tunnel, it is an optional configuration that provides pre-logon connectivity for domain-joined, Enterprise edition Windows 10 clients. Although the device tunnel was designed to supplement the user tunnel connection, some administrators have deployed the device tunnel exclusively and use it for general on-premises network access. While I do not typically recommend this configuration for a variety of reasons, there are some use cases for which using the device tunnel might be acceptable.

Device Tunnel Status

For those administrators who have decided to deploy the device tunnel exclusively, a common complaint is that the device tunnel connection status does not appear in the Windows 10 notification area like other network or user tunnel connections.

However, the device tunnel does appear in the classic Network Connections control panel applet (ncpa.cpl).

Enable Device Tunnel Status Indicator

Fortunately, there is a simple workaround that allows for the device tunnel connection status to appear in the Windows 10 notification area. This can be done by setting the following registry value.

HKLM\SOFTWARE\Microsoft\Flyout\VPN\ShowDeviceTunnelInUI DWORD = 1

You can set this registry value using Active Directory group policy preferences or locally by running the following PowerShell command.

New-Item -Path ‘HKLM:\SOFTWARE\Microsoft\Flyout\VPN’ -Force
New-ItemProperty -Path ‘HKLM:\Software\Microsoft\Flyout\VPN\’ -Name ‘ShowDeviceTunnelInUI’ -PropertyType DWORD -Value 1 -Force

Once this registry value is set, the Always On VPN device tunnel will appear in the notification area long with other network connections.

Caveat

Although the UI will now display the connectivity status of the Always On VPN device tunnel, clicking Disconnect has no effect. This is expected and by design, as the device tunnel is deployed in the context of the system, not the user. Disconnecting the device tunnel must be performed by an administrator using the GUI tool rasphone.exe or the command line tool rasdial.exe.

Blog Post Comments

For the record, several readers of this blog had posted this workaround in the comments of this post. In the past. I declined to approve those comments because initially I did not want to encourage people to deploy the device tunnel standalone. However, recently I have had a change of heart, and decided to publish this information for those administrators who want to use the device tunnel exclusively, and would also benefit from a visual connectivity status indicator for the Windows 10 Always On VPN device tunnel. Although I still do not recommend using the device tunnel alone, I understand that it may be acceptable for others, so I have decided to release that information here.

Additional Information

Windows 10 Always On VPN Device Tunnel Only Deployment Considerations

Windows 10 Always On VPN Device Tunnel Operation and Best Practices

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN Device Tunnel and Certificate Revocation

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI

35 Comments

by Richard M. Hicks on August 27, 2020 • Permalink

Posted in Always On VPN, AOVPN, device tunnel, Enterprise, enterprise mobility, PowerShell, Remote Access, VPN, Windows 10

Tagged Always On VPN, AOVPN, device tunnel, Microsoft, Mobility, NCSI, network connectivity status indicator, PowerShell, registry, user tunnel, VPN, Windows, Windows 10, workaround

Posted by Richard M. Hicks on August 27, 2020

https://directaccess.richardhicks.com/2020/08/27/always-on-vpn-device-tunnel-status-indicator/

Removing Always On VPN Connections

Much has been written about provisioning Windows 10 Always On VPN client connections over the past few years. While the preferred method for deploying Always On VPN is Microsoft Intune, using PowerShell is often helpful for initial testing, and required for production deployment with System Center Configuration Manager (SCCM) or Microsoft Endpoint Manager (MEM). That said, there will invariably come a time when an administrator has to remove an Always On VPN connection. It is not as simple as you might think.

PowerShell

There are a variety of ways to remove an existing Always On VPN connection, with the quickest and simplest being PowerShell and the Remove-VpnConnection cmdlet.

Get-VpnConnection -Name ‘Always On VPN’ | Remove-VpnConnection -Force

There are several limitations to this method, however.

Active Connections

Administrators will quickly realize that PowerShell fails to remove a VPN connection that is currently connected. As shown here, attempting to remove an active VPN connection will return the following error message.

“The VPN connection [connection name] cannot be removed from the local user connections. Cannot delete a connection while it is connected.”

Registry Artifacts

Removing Always On VPN connections using PowerShell commonly leaves behind registry artifacts that can potentially cause problems. For example, there are several Always On VPN-related registry entries in several locations including the HKLM\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked hive that may not be deleted when removing an Always On VPN connection. When provisioning a new Always On VPN connection after deleting one with the same name previously, the administrator may encounter the following error message.

“Unable to create [connection name] profile: A general error occurred that is not covered by a more specific error code.”

Note: This error can also be caused by improperly formatted XML configuration files. More details here.

Remove-AovpnConnection Script

Veteran Always On VPN administrators are likely familiar with PowerShell scripts I’ve created called New-AovpnConneciton.ps1 and New-AovpnDeviceConnection.ps1, which are hosted on my GitHub. These scripts are adapted from code samples published by Microsoft to which I have included additional functionality. To address the limitations highlighted in this article I have published a new PowerShell script called Remove-AovpnConnection.ps1. It will remove any Always On VPN connection, even those that are currently active. It also includes logic to remove known registry artifacts common to Always On VPN. Download the script from GitHub and use the following syntax to remove an Always On VPN connection, established or not.

.\Remove-AovpnConnection.ps1 -ProfileName [connection name]

Running this PowerShell command will forcibly remove an Always On VPN connection. Use the -DeviceTunnel switch when removing a device tunnel connection (requires running in the system context). I have also included a -CleanUpOnly switch to remove registry artifacts when the VPN connection was previously removed using another method.

Updated Installation Scripts

I have also updated New-AovpnConnection.ps1 to include these registry clean up steps. This will prevent future errors when provisioning an Always On VPN client where a connection of the same name was removed previously.

Note: New-AovpnConnection.ps1 has also been updated to support device tunnel deployments. As such, I have deprecated New-AovpnDeviceConnection.ps1. Simply use New-AovpnConnection.ps1 with the -DeviceTunnel switch to deploy an Always On VPN device tunnel.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Troubleshooting Always On VPN Unable to Create Profile General Error

59 Comments

by Richard M. Hicks on August 24, 2020 • Permalink

Posted in Always On VPN, AOVPN, device tunnel, Enterprise, enterprise mobility, GitHub, Microsoft Intune, Mobility, PowerShell, ProfileXML, Remote Access, troubleshooting, user tunnel, VPN, Windows 10, XML

Posted by Richard M. Hicks on August 24, 2020

https://directaccess.richardhicks.com/2020/08/24/removing-always-on-vpn-connections/

Always On VPN Device Tunnel Operation and Best Practices

Unlike DirectAccess, Windows 10 Always On VPN settings are deployed to the individual user, not the device. As such, there is no support for logging on without cached credentials using the default configuration. To address this limitation, and to provide feature parity with DirectAccess, Microsoft later introduced the device tunnel option in Windows 10 1709.

Device Tunnel Use Cases

The device tunnel is designed to allow the client device to establish an Always On VPN connection before the user logs on. This enables important scenarios such as logging on without cached credentials. This feature is crucial for organizations who expect users to log on to devices the first time remotely. The device tunnel can also be helpful for remote support, allowing administrators to manage remotely connected Always On VPN clients without having a user logged on. In addition, the device tunnel can alleviate some of the pain caused by administrators resetting remote worker’s passwords, or by users initiating a Self-Service Password Reset (SSPR).

Device Tunnel Requirements

The device tunnel requires Windows 10 Enterprise edition 1709 or later, and the client device must be joined to the domain. The device tunnel must be provisioned in the context of the local system account. Guidance for configuring and deploying a Windows 10 Always On VPN device tunnel can be found here.

Device Tunnel Authentication

The device tunnel is authenticated using a certificate issued to the client device, much the same as DirectAccess does. Authentication takes place on the Routing and Remote Access Service (RRAS) VPN server. It does not require a Network Policy Server (NPS) to perform authentication for the device tunnel.

CRL Checking

Eventually an administrator may need to deny access to a device configured with an Always On VPN device tunnel connection. In theory, revoking the client device’s certificate and terminating their IPsec Security Associations (SAs) on the VPN server would accomplish this. However, Windows Server RRAS does not perform certificate revocation checking for Windows 10 Always On VPN device tunnel connections by default. Thankfully an update is available to enable this functionality. See Always On VPN Device Tunnel and Certificate Revocation for more details.

Configuration Best Practices

As the device tunnel is designed only to support domain authentication for remote clients, it should be configured with limited access to the on-premises infrastructure. Below is a list of required and optional infrastructure services that should be reachable over the device tunnel connection.

Required

All domain controllers
Enterprise DNS servers (if DNS is running on servers other than domain controllers)

Optional

All issuing certification authority (CA) servers
All certificate services online HTTP responders
All certificate services Online Certificate Status Protocol (OCSP) servers
System Center Configuration Manager (SCCM) distribution point servers
Windows Server Update Services (WSUS) servers
Management workstations

Limiting Access

Limiting access over the Always On VPN device tunnel can be accomplished in one of the following two ways.

Traffic Filters

The administrator can configure traffic filters on the device tunnel to restrict access only to those IP addresses required. However, be advised that when a traffic filter is enabled on the device tunnel, all inbound access will be blocked. This effectively prevents any remote management of the device from an on-premises system over the device tunnel.

Host Routes

An alternative to using traffic filters to limit access over the device tunnel is using host routes. Host routes are configured with a /32 prefix size and define a route to a specific individual host. The following is an example of host route configuration in ProfileXML.

Note: A PowerShell script that enumerates all enterprise domain controllers and outputs their IP addresses in XML format for use in ProfileXML can be found here.

Caveats

Some organizations may have hundreds or even thousands of domain controllers, so creating individual host route entries for all domain controllers in profileXML may not be practical. In this scenario it is recommended to add host routes only for the domain controllers that belong to the Active Directory site where the VPN server resides.

Supportability

Do not use the <DomainNameInformation> element in ProfileXML or enable force tunneling for the device tunnel. Neither of these configurations are supported.

Tunnel Coexistence

The device tunnel can be safely deployed in conjunction with the user tunnel whenever its functionality is required.

DNS Registration

If the device tunnel and user tunnel are both deployed, it is recommended that only one of the tunnels be configured to register in DNS. If the device tunnel is configured to register its IP address in DNS, be advised that only those devices with routes configured in the device tunnel VPN profile will be able to connect remotely to Always On VPN clients.

Additional Information

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN Device Tunnel and Certificate Revocation

Windows 10 Always On VPN Device Tunnel Configuration with Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

66 Comments

by Richard M. Hicks on March 30, 2020 • Permalink

Posted by Richard M. Hicks on March 30, 2020

https://directaccess.richardhicks.com/2020/03/30/always-on-vpn-device-tunnel-operation-and-best-practices/

Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN is infrastructure independent, which allows for many different deployment scenarios including on-premises and cloud-based. In Microsoft Azure, the Azure VPN gateway can be configured to support Windows 10 Always On VPN client connections in some scenarios. Recently I wrote about using the Azure VPN gateway for Always On VPN user tunnels. In this post I’ll describe how to configure the Azure VPN gateway to support an Always On VPN device tunnel.

Limitations

There are a few crucial limitations that come with using the Azure VPN gateway for Always On VPN. Importantly, the Azure VPN gateway can support either user tunnels or device tunnels, not both at the same time. In addition, Azure supports only a single VPN gateway per VNet, so deploying an additional VPN gateway in the same VNet to support Always On VPN user tunnels is not an option.

Root CA Certificate

The Always On VPN device tunnel is authenticated using a machine certificate issued to domain-joined Windows 10 Enterprise edition clients by the organization’s internal Certification Authority (CA). The CA’s root certificate must be uploaded to Azure for the VPN gateway to authorize device tunnel connections. The root CA certificate can be exported using the Certification Authority management console (certsrv.msc) or via the command line.

Export Certificate – GUI

Follow the steps below to export a root CA certificate using the Certification Authority management console.

1. On the root CA server, open the Certification Authority management console.
2. Right-click the CA and choose Properties.
3. Select the CA server’s certificate and choose View Certificate.
4. Select the Details tab and click Copy to File.
5. Click Next.
6. Choose Base-64 encoded X.509 (.CER).

7. Click Next.
8. Enter a location to save the file to.
9. Click Next, Finish, and Ok.

Export Certificate – Command Line

Follow the steps below to export a root CA certificate using the command line.

1. On the root CA server, open an elevated command window (not a PowerShell window).
2. Enter certutil.exe -ca.cert root_certificate.cer.
3. Enter certutil.exe -encode root.cer root_certificate_base64.cer.

Copy Public Key

1. Open the saved root certificate file using Notepad.
2. Copy the file contents between the BEGIN CERTIFICATE and END CERTIFICATE tags, as shown here. Use caution and don’t copy the carriage return at the end of the string.

Point-to-Site Configuration

The Azure VPN gateway must be deployed as a Route-Based gateway to support point-to-site VPN connections. Detailed requirements for the gateway can be found here. Once the VPN gateway has been provisioned, follow the steps below to enable point-to-site configuration for Always On VPN device tunnels.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click the Configure now link and specify an IPv4 address pool to be assigned to VPN clients. This IP address pool must be unique in the organization and must not overlap with an IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2.
4. In the Root certificates section enter a descriptive name for the certificate in the Name field.
5. Copy and paste the Base64 encoded public key copied previously into the Public certificate data field.
6. Click Save to save the configuration.

VPN Client Configuration

To support the Always On VPN device tunnel, the client must have a certificate issued by the internal CA with the Client Authentication Enhanced Key Usage (EKU). Detailed guidance for deploying a Windows 10 Always On VPN device tunnel can be found here.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Click Save.
4. Open the downloaded zip file and extract the VpnSettings.xml file from the Generic folder.
5. Copy the FQDN in the VpnServer element in VpnSettings.xml. This is the FQDN that will be used in the template VPN connection and later in ProfileXML.

Create a Test VPN Connection

It is recommended to create a test VPN connection to perform validation testing of the Azure VPN gateway before provisioning an Always On VPN device tunnel broadly. On a domain-joined Windows 10 enterprise client, create a new VPN connection using IKEv2 with machine certificate authentication. Use the VPN server FQDN copied from the VpnSettings.xml file previously.

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, an Always On VPN profile can be created and deployed using Intune, SCCM, or PowerShell. The following articles can be used for reference.

Deploy Always On VPN device tunnel using PowerShell

Deploy Always On VPN device tunnel using Intune

IKEv2 Security Configuration

The default IKEv2 security parameters used by the Azure VPN gateway are better than Windows Server, but the administrator will notice that a weak Diffie-Hellman (DH) key (Group 2 – 1024 bit) is used during IPsec phase 1 negotiation.

Use the following PowerShell commands to update the default IKEv2 security parameters to recommended baseline defaults, including 2048-bit keys (DH group 14) and AES-128 for improved performance.

Connect-AzAccount
Select-AzSubscription -SubscriptionName [Azure Subscription Name]

$Gateway = [Gateway Name]
$ResourceGroup = [Resource Group Name]

$IPsecPolicy = New-AzVpnClientIpsecParameter -IpsecEncryption AES128 -IpsecIntegrity SHA256 -SALifeTime 28800 -SADataSize 102400000 -IkeEncryption AES128 -IkeIntegrity SHA256 -DhGroup DHGroup14 -PfsGroup PFS14

Set-AzVpnClientIpsecParameter -VirtualNetworkGatewayName $Gateway -ResourceGroupName $ResourceGroup -VpnClientIPsecParameter $IPsecPolicy

Note: Be sure to update the cryptography settings on the test VPN connection and in ProfileXML for Always On VPN connections to match the new VPN gateway settings. Failing to do so will result in an IPsec policy mismatch error.

Additional Information

Windows 10 Always On VPN User Tunnel with Azure VPN Gateway

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN IKEv2 Features and Limitations

28 Comments

by Richard M. Hicks on January 6, 2020 • Permalink

Posted by Richard M. Hicks on January 6, 2020

https://directaccess.richardhicks.com/2020/01/06/always-on-vpn-device-tunnel-with-azure-vpn-gateway/

Search for:
Always On VPN Book

Pre-order Now!
DirectAccess Book
NetMotion Mobility

DirectAccess-like Remote Access for Windows, Mac, iPhone, iPad, and Android

Learn More!
Recent Posts
Always On VPN Resources
DirectAccess Resources

Awards

Consulting

Connect

Mailing List

RSS Feed

Archives

Categories

Tag Cloud

All posts tagged PowerShell

Short Names

FQDN

Troubleshooting

Workaround

Proactive Remediations

GitHub Repository

Additional Information

Share this:

Like this:

TLS Certificate

TLS Configuration

TLS Protocols

Cipher Suites

PowerShell Script

Validation Testing

Additional Information

Share this:

Like this:

Offline Hybrid Azure AD Join

Windows 10 Professional

Multiple Activation Key

KMS Activation

Subscription Activation

Workaround

Considerations

Special Thanks

Additional Information

Share this:

Like this:

Intune VPN Profile Configuration

Class-Based Default Route

Considerations

Workaround

Additional Information

Share this:

Like this:

Troubleshooting

Event Log

Resolution

Additional Information

Share this:

Like this:

Multiple Root Certificates

Certificate Selection

Certificate Publishing

PowerShell Script

Additional Information

Share this:

Like this:

Device Tunnel Status

Enable Device Tunnel Status Indicator

Caveat

Blog Post Comments

Additional Information

Share this:

Like this:

PowerShell

Active Connections

Registry Artifacts

Remove-AovpnConnection Script

Updated Installation Scripts

Additional Information

Share this:

Like this:

Device Tunnel Use Cases

Device Tunnel Requirements

Device Tunnel Authentication

CRL Checking

Configuration Best Practices

Required

Optional