Always On VPN DPC version 3.0 includes the following new functionality Always On VPN administrators are sure to find useful.
Traffic filters – Support for enabling traffic filters for both device tunnel and user tunnel are now supported in DPC, greatly simplifying the task of creating access control lists to enforce zero-trust network access (ZTNA) policies.
Enhanced security – The option to disconnect the VPN connection if the VPN server does not present a cryptobinding TLV is now enabled by default. This often-overlooked security setting ensures VPN client connections are not intercepted by detecting man-in-the-middle attacks.
Device tunnel enhancements – Administrators can now display the device tunnel connection and status in the Windows UI.
Backup connection – Always On VPN DPC now supports the configuration and deployment of a backup VPN connection, which is helpful when Always On VPN connectivity is disrupted.
Hostname routing – Administrators can now define hostnames in the routing table. Hostnames are resolved on the endpoint and converted to IP addresses for including in the routing table.
Smart card authentication – Always On VPN DPC now supports smart card authentication as an authentication option in addition to client authentication certificates.
Learn More
Interested in learning more about Always On VPN DPC? Fill out the form below and I’ll provide you with additional information or visit aovpndpc.com to sign up for a free trial.
When configuring the Windows Server Routing and Remote Access Service (RRAS) to support Secure Socket Tunneling Protocol (SSTP) for Always On VPN user tunnel connections, administrators must install a Transport Layer Security (TLS) certificate on the VPN server. The best practice is to use a certificate issued by a public Certification Authority (CA). In addition, administrators should use a TLS certificate using Elliptic Curve Digital Signature Algorithm (ECDSA) for optimal security and performance.
Let’s Encrypt
Obtaining a public TLS certificate is not inherently difficult, nor is it expensive. However, Let’s Encrypt is a nonprofit public CA issues TLS certificates entirely for free. Always On VPN supports Let’s Encrypt TLS certificates, and installing a Let’s Encrypt certificate on the Always On VPN RRAS server is quite simple.
Pros and Cons
Using Let’s Encrypt certificates for Always On VPN has several significant advantages over traditional public CAs.
Cost – Let’s Encrypt certificates are free! No cost whatsoever.
Speed – Enrolling for a Let’s Encrypt certificate takes just a few minutes.
Trusted – Let’s Encrypt certificates are trusted by default in Windows 10 and Windows 11.
Let’s Encrypt is not without some drawbacks, however.
Lifetime – Let’s Encrypt certificates are only valid for 90 days.
Administration – Certificates must be redeployed frequently (every 90 days).
Security – PFX files (which include private keys) are left on disk by default.
It is possible to mitigate some of these drawbacks, though. For example, deleting PFX files after import can improve security. Alternatively, using a Certificate Signing Request (CSR) eliminates PFX files completely.
Also, it is possible to fully automate the Let’s Encrypt certificate enrollment and RRAS configuration process, which eases the administrative burden. And rotating certificates every 90 days could be considered an advantage from a security perspective! Enrolling new certificates (and specifically certificates with unique keys) is advantageous in that respect.
Certificate Enrollment
There are several different ways to enroll for Let’s Encrypt certificates. The preferred method is using PowerShell, as it works on both Windows Server with Desktop Experience (GUI) and Windows Server Core. Using PowerShell, administrators can also fully automate the enrollment and assignment of the certificate in RRAS.
PowerShell Module
To enroll for Let’s Encrypt TLS certificates on the VPN server, install the Posh-ACME PowerShell module. On the RRAS server, open an elevated PowerShell window and run the following command.
Install-Module Posh-ACME
Certificate Request
After installing the Posh-ACME PowerShell module, select a Let’s Encrypt environment by running the following command. Use LE_PROD for the production Let’s Encrypt server or LE_STAGE for the staging environment (used for testing).
Set-PAServer LE_PROD
Next, request a new certificate using the following command.
The administrator is prompted to create a TXT record in public DNS to prove ownership of the domain. Using the example above, create a DNS record called _acme-challenge.vpn in the example.net DNS zone.
Once complete, the TLS certificate is automatically installed in the local computer certificate store on the VPN server and can be assigned in the RRAS management console, as shown here.
Note: R3 is a Let’s Encrypt issuing certification authority.
DNS Plugin
The Posh-ACME PowerShell module supports DNS plugins that allow administrators to automate the creation of the DNS TXT record used to authorize certificate enrollment. DNS plugins for many public DNS providers are available. Some of the more popular DNS providers are listed here.
Microsoft Azure
Amazon Route53
Cloudflare
Akamai
GoDaddy
Infoblox
Windows Server
A list of all supported DNS plugins for Posh-ACME can be found here.
Certificate Binding
Administrators can use the following PowerShell example code to automate the process of binding the new TLS certificate to the SSTP listener in RRAS.
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.
PowerShell
Administrators can also implement this setting by running the following PowerShell command.
Another option for implementing this setting is by enabling the following Active Directory Group Policy setting.
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication