Always On VPN SSTP with Let’s Encrypt Certificates

Always On VPN SSTP Security Configuration

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.

New-PACertificate -Domain vpn.example.net -Contact ‘[email protected]’ -CertKeyLength ec-256 -AcceptTOS -Install

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.

$Thumbprint = <TLS certificate thumbprint>
$Cert = Get-ChildItem -Path Cert:\LocalMachine\My\$thumbprint
Set-RemoteAccess -SslCertificate $Cert
Restart-Service RemoteAccess -Passthru

Additional Information

Posh-ACME Tutorial

Windows 10 Always On VPN TLS Certificate Requirements for SSTP

Windows 10 Always On VPN SSTP Security Configuration

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

Always On VPN Proxy Server Configuration

Always On VPN Proxy Server Configuration

Web proxy servers are not as common today as they once were, but a few organizations still leverage them to provide secure Internet access for their employees. Commonly they are used to inspect and control Internet traffic and to enforce acceptable use policies. Some organizations may wish to extend this protection to Always On VPN clients in the field by enabling force tunneling. Administrators can define a web proxy server for Always On VPN connections globally for web traffic or individual websites or domains.

VPN Proxy

A VPN web proxy server can be defined when the Always On VPN user tunnel connection uses force tunneling. Although you can still configure a VPN web proxy server with split tunneling enabled, it will not work. It is only functional when force tunneling is in use.

Administrators can configure a VPN web proxy server using the Microsoft Endpoint Manager UI or custom XML deployed with Endpoint Manager or PowerShell. Administrators can define a VPN web proxy server explicitly, or a proxy automatic configuration (PAC) file can be specified.

Note: VPN proxy server settings only work when force tunneling is enabled. Force tunneling is an unsupported configuration for the device tunnel, making the global proxy server setting for the device tunnel unsupported.

Proxy Autoconfiguration

Perform the following steps to configure a VPN web proxy server with a PAC file in Endpoint Manager.

  1. Expand the Proxy section in the Configuration settings of the Always On VPN configuration profile.
  2. Enter the URL for the PAC file in the Automatic configuration script field. Be sure to include the port number in the URL when using a non-standard port.
  3. Leave the Address and Port number fields blank.
  4. Choose Enable or Disable from the Bypass proxy for local addresses drop-down list.

To configure a VPN web proxy server with a PAC file using custom XML, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.

Explicit Proxy

Perform the following steps to configure an explicit VPN web proxy server in Endpoint Manager.

  1. Enter the IP address, hostname, or fully qualified domain name (recommended) in the Address field.
  2. Enter the port number in the Port number field.
  3. Choose Enable or Disable from the Bypass proxy for local addresses drop-down list.

To configure an explicit VPN web proxy server using custom XML, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.

Namespace Proxy

Administrators can also define VPN web proxy servers on a per-namespace or per-hostname basis. Namespace VPN proxy servers can be helpful for scenarios where routing public websites over the Always On VPN connection is required. Most commonly, this is necessary because the public website restricts access to the IP address of the on-premises Internet gateway.

A namespace VPN proxy server is implemented using a Name Resolution Policy Table (NRPT) rule. At the time of this writing, a bug in Microsoft Endpoint Manager prevents administrators from deploying this option using the UI.

As you can see here, administrators can specify a proxy server as part of an NRPT rule in the Endpoint Manager UI. Notice this section of the UI validates the proxy FQDN correctly.

Always On VPN Proxy Server Configuration

However, when you try to save the configuration profile, Endpoint Manager returns the following error.

“Unable to save due to invalid data. Update your data then try again: ProxyServerUri must be a valid URL or be empty.”

Interestingly, when entering a URL such as http://proxy.lab.richardhicks.net:8080/ in the Proxy field, the Endpoint Manager UI accepts it and successfully validates. But according to the VPNv2 Configuration Service Provider (CSP) reference, the value must be entered as an IP address. A hostname or FQDN also works based on my testing. Entering a URL as shown in the example above will not work at all.

With that, the only way to implement a namespace VPN web proxy server is to use custom XML. To do this, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.

Include the leading “.” to specify the entire domain, as shown above. Omit the leading “.” to specify an individual host (for example, app.richardhicks.com). Repeat this section for each additional host or domain, as required.

Caveat

Unfortunately, the Microsoft Internet Explorer web browser is the only browser that functions with the namespace VPN web proxy server. All modern web browsers, including Microsoft Edge, ignore the namespace proxy setting entirely, which seriously limits this feature’s usefulness in most organizations today.

Workaround

If routing a public website over the Always On VPN tunnel is required, adding its IP address(es) to the Always On VPN connection’s routing table is needed. However, doing this presents some unique challenges, as public websites frequently have many IP addresses, which are often dynamically changing. Also, it is common for public websites to pull content from many different domains or use Content Delivery Networks (CDNs), making the problem of identifying which IP addresses to add to the Always On VPN connection’s routing table even more challenging. Further, administrators must update the client configuration each a public website’s IP address changes, adding significant management overhead.

Summary

Routing client Internet traffic through an on-premises web proxy server for Always On VPN clients works well when force tunneling is enabled. Administrators can explicitly define a web proxy server or use a proxy automatic configuration (PAC) file. All web browsers work without issue in this scenario. Using a namespace proxy is only effective when browsing with Microsoft Internet Explorer. All modern web browsers, including Microsoft Edge, ignore namespace proxy settings.

Additional Information

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

Windows 10 VPNv2 Configuration Service Provider (CSP) Reference

Windows 10 Always On VPN Client DNS Server Configuration

%d bloggers like this: