Troubleshooting Always On VPN Error Code 809

When testing an Always On VPN connection, the administrator may encounter a scenario where the VPN client fails to connect to the VPN server. On the Windows 10 client the error message states the following.

“Can’t connect to [connection name]. The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g. firewalls, NAT, routers, etc.) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem.”

Always On VPN and IKEv2 Fragmentation

In addition, the Application event log records an error message with Event ID 20227 from the RasClient source. The error message states the following.

“The User [username] dialed a connection named [connection name] with has failed. The error code returned on failure is 809.”

Troubleshooting Always On VPN Error Code 809

Connection Timeout

The error code 809 indicates a VPN timeout, meaning the VPN server failed to respond. Often this is related directly to network connectivity, but sometimes other factors can come in to play.

Troubleshooting VPN Error Code 809

When troubleshooting VPN error code 809 the following items should be carefully checked.

  • Name Resolution – Ensure the VPN server’s public hostname resolves to the correct IP address.
  • Firewall Configuration – Confirm the edge firewall is configured properly. Inbound TCP port 443 is required for the Secure Socket Tunneling Protocol (SSTP) and inbound UDP ports 500 and 4500 are required for the Internet Key Exchange version 2 (IKEv2) protocol. Make sure that any NAT rules are forwarding traffic to the correct server.
  • Load Balancer Configuration – If VPN servers are located behind a load balancer, make certain that virtual IP address and ports are configured correctly and that health checks are passing. For IKEv2 specifically, it is crucial that UDP ports 500 and 4500 be delivered to the same backend server. This commonly requires custom configuration. For example, on the KEMP LoadMaster the administrator will configure “port following”. On the F5 BIG-IP a  custom “persistence profile” must be configured. On the Citrix NetScaler a “persistency group” must be defined.

IKEv2 Fragmentation

VPN error code 809 can also be caused by IKE fragmentation when using the IKEv2 VPN protocol. During IKEv2 connection establishment, payload sizes may exceed the IP Maximum Transmission Unit (MTU) for the network path between the client and server. This causes the IP packets to be fragmented. However, it is not uncommon for intermediary devices (routers, NAT devices, or firewalls) to block IP fragments. When this occurs, a VPN connection cannot be established. However, looking at a network trace of the connection attempt, the administrator will see that the connection begins but subsequently fails.

Troubleshooting Always On VPN Error Code 809

Enable IKEv2 Fragmentation Support

The IKEv2 protocol includes support for fragmenting packets at the IKE layer. This eliminates the need for fragmenting packets at the IP layer. IKEv2 fragmentation must be configured on both the client and server.

Client

IKEv2 fragmentation was introduced in Windows 10 1803 and is enabled by default. No client-side configuration is required.

Server

IKEv2 is commonly supported on many firewall and VPN devices. Consult the vendor’s documentation for configuration guidance. For Windows Server Routing and Remote Access (RRAS) servers, IKEv2 fragmentation was introduced in Windows Server 1803 and is also supported in Windows Server 2019. It is enabled via a registry key. The following PowerShell command can be used to enable IKEv2 fragmentation on supported servers.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\” -Name EnableServerFragmentation -PropertyType DWORD -Value 1 -Force

Validation

Once IKEv2 fragmentation is configured on the VPN server, a network capture will reveal the IKE_SA_INIT packet now includes the IKEV2_FRAGMENTATION_SUPPORTED notification message.

Always On VPN and IKEv2 Fragmentation

Additional Information

Windows 10 Always On VPN and IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Hands-On Training Classes

Always On VPN and Third Party VPN Devices

Always On VPN and Third Party VPN DevicesOne of the most important advantages Windows 10 Always On VPN has over DirectAccess is infrastructure independence. That is, Always On VPN does not rely exclusively on a Windows Server infrastructure to support Always On VPN connections. Always On VPN will work with many third-party firewalls and VPN devices, as long as they meet some basic requirements.

Advantages

Third-party firewalls or VPN devices offer some important advantages over Windows Servers running the Routing and Remote Access Services (RRAS), both in terms of security and performance.

Security

Dedicated security devices (physical or virtual) provide better security than a common Windows server. They commonly run specialized, security-hardened operating systems that are highly secure and resistant to attack. In addition, these solutions typically allow the administrator to define policy to restrict access to internal resources and do so in a centralized way. This is often easier to implement and manage than using traffic filters on the client side. They often include advanced security features such as URL filtering and malware inspection to better protect remote clients. Some solutions include Hardware Security Module (HSM) integration to further enhance security.

Performance

Purpose-built solutions often provide better throughput and performance than do Windows Servers by virtue of their proprietary operating systems. This allows for better network throughput and the ability to support many more connections per device.

Disadvantages

The main drawbacks for using a third-party device are cost and administrative overhead. Third-party solutions must be acquired, for which there is typically a non-trivial cost associated. They often need additional per-user licensing. In addition, many of these solutions require specialized skill sets to implement, manage, and support which could further increase the overall cost of the solution.

Interoperability Requirements

Any firewall or VPN device can be used for Always On VPN as long as they support the Internet Key Exchange version 2 (IKEv2) VPN protocol for remote access connections. Most modern firewalls today support IKEv2, but some (such as the Sophos XG firewall) do not. Check with your vendor to validate support.

Native Client

If the firewall or VPN device supports IKEv2 for remote access connections, the native Windows VPN provider can be used to establish an Always On VPN connection. The native provider is used when the Always On VPN ProfileXML is configured using the NativeProfile element.

Plug-In VPN Client

One crucial drawback to using IKEv2 is that it is commonly blocked by firewalls. Many third-party VPN vendors offer a plug-in client that enables support for TLS-based transport, which is more firewall friendly than IKEv2. Plug-in VPN providers are available in the Microsoft store.

Below is a current list of available third-party plug-in providers for Windows 10. Notably absent from this list is Cisco. Hopefully they will add support for a plug-in client soon. 🙂

  • Check Point Capsule
  • F5 Access
  • Fortinet Forticlient
  • Palo Alto GlobalProtect
  • Pulse Secure
  • SonicWall Mobile Connect

Always On VPN and Third Party VPN Devices

Note: Win32 VPN client applications from third-party vendors are not supported with Windows 10 Always On VPN.

Additional Information

What is the Difference Between DirectAccess and Always On VPN?

5 Things DirectAccess Administrators Should Know about Always On VPN

3 Important Advantages of Always On VPN over DirectAccess

Always On VPN IKEv2 and SSTP Fallback

Always On VPN IKEv2 and SSTP FallbackA while back I wrote about the various VPN protocols supported for Windows 10 Always On VPN. The two most common are Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). The article covers in detail each protocol’s advantages and disadvantages. To summarize, IKEv2 provides the best security (when configured correctly!) and SSTP is firewall-friendly ensuring ubiquitous access. Ideally an Always On VPN connection will attempt to use the more secure IKEv2 first, then fallback to SSTP only when IKEv2 is unavailable. Unfortunately, Always On VPN connections do not work this way today.

IKEv2 and SSTP

IKEv2 and SSTP are not mutually exclusive. When using Windows Routing and Remote Access Service (RRAS) as the VPN server, both protocols can be configured and enabled for VPN clients. To allow VPN clients to automatically select a protocol, the NativeProtocolType element in ProfileXML can be set to Automatic.

Always On VPN IKEv2 and SSTP Fallback

IKEv2 with SSTP Fallback?

In theory, with the NativeProtocolType set to Automatic, the Windows 10 client would first attempt to establish an IKEv2 connection, then fall back to SSTP if IKEv2 is not available. In practice, this is not the case.

SSTP Preferred over IKEv2

In operation, setting the NativeProtocolType to Automatic results in the Windows 10 client attempting to establish a VPN connection using SSTP first! If the SSTP connection fails, only then will IKEv2 be used. The only scenario in which I can imagine SSTP failing and IKEv2 being successful would be if SSTP is not supported by the VPN server. Sadly, this scenario may result in failed connections due to a bug in the way ProfileXML settings are processed. Details here.

VPN Strategy

The initial VPN protocol selection behavior is dictated by the VpnStrategy setting of the Always On VPN connection in the rasphone.pbk file. This file can be found under C:\Users\[username]\AppData\Roaming\Microsoft\Network\Connections\Pbk. The documentation on the Microsoft website is terribly outdated and does not include the following important VpnStrategy settings pertinent to Windows 10 Always On VPN connections.

  • 5 = Only SSTP is attempted
  • 6 = SSTP is attempted first
  • 7 = Only IKEv2 is attempted
  • 8 = IKEv2 is attempted first
  • 14 = IKEv2 is attempted followed by SSTP

Always On VPN Default Behavior

For Always On VPN, when the NativeProtocolType is set to Automatic in ProfileXML, VpnStrategy is set to 6 by default, which means the connection will attempt to use SSTP first. If it fails, IKEv2 will be attempted.

Always On VPN IKEv2 and SSTP Fallback

If the NativeProtocolType in ProfileXML is set to IKEv2, VpnStrategy is set to 7 and only IKEv2 is used. A connection using SSTP is never attempted.

Workaround

Setting the VpnStrategy to 8 or 14 will force the client to attempt an IKEv2 connection first. However, this setting is dynamically updated by Windows and is subject to change. For example, if an IKEv2 connection fails and SSTP is successful, Windows will then set the VpnStrategy to 6 and all subsequent VPN connection attempts will use SSTP first. Because of this it will be necessary to update the VpnStrategy setting each time prior to establishing a VPN connection. This will require some clever scripting and perhaps automation using a scheduled task based on an event trigger. I will leave that custom configuration as an exercise for the reader. If you’ve developed something to address this challenge, please feel free to share in the comments below. 🙂

Additional Information

Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN IKEv2 Security Configuration

Always On VPN Certificate Requirements for IKEv2

Always On VPN IKEv2 Load Balancing with KEMP LoadMaster Load Balancer

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

After installing and configuring DirectAccess in Windows Server 2019 you may encounter an error message indicating that IP-HTTPS is not working properly. Looking at the Operations Status overview in the Dashboard of the Remote Access Management console shows that the IP-HTTPS interface is in error.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

IP-HTTPS Route Error

Viewing the detailed Operations Status shows the following error message.

Error: The IP-HTTPS route does not have published property enabled.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Missing Route

Looking at the routing table on the DirectAccess server reveals that a route to the client IPv6 prefix is indeed missing.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Resolution

To resolve this error message, add the client IPv6 route to the DirectAccess server’s routing table and publish it. This is accomplished by running the following PowerShell commands on the DirectAccess server.

$IPv6prefix = (Get-RemoteAccess).ClientIPv6Prefix
New-NetRoute -AddressFamily IPv6 -DestinationPrefix $IPv6prefix -InterfaceAlias “Microsoft IP-HTTPS Platform Interface” -Publish Yes

Next, restart the Remote Access Management service (RaMgmtSvc) using the following PowerShell command.

Restart-Service RaMgmtSvc -PassThru

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Once complete, refresh the management console and the IP-HTTPS error message should be resolved and the operations status should state that it is now working properly.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

 

Additional Information

SSL Certificate Conisderations for DirectAccess IP-HTTPS

DirectAccess Expire IP-HTTPS Certificate and Error 0x800b0101

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803PowerShell is an essential tool for Windows administrators for configuration, task automation, monitoring, reporting, and problem resolution. When troubleshooting DirectAccess connectivity using the IP-HTTPS IPv6 transition technology, the Get-NetIPHttpsConfiguration and Get-NetIPHttpsState PowerShell commands are important for assessing the configuration and current state of the IP-HTTPS connection. When DirectAccess connectivity fails, these are some of the first commands an administrator will use to identify and resolve the issue.

Get-NetIPHttpsState

Get-NetIPHttpsState is especially helpful when IP-HTTPS connectivity fails because it returns an error code and interface status information that can provide clues as to why the connection was not completed successfully.

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

No Output in 1803

Beginning with Windows 10 1803, the DirectAccess administrator will notice that Get-NetIPHttpsState returns no data. The output of Get-NetIPHttpsState is blank.

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

Changes in 1803

As it turns out, this is a bug first introduced in Windows 10 1803 that is the result of a fundamental change in the way in which the IP-HTTPS interface is implemented in Windows. As of this writing, the bug has not been addressed in Windows 10 1803 or 1809.

Workaround

The good news is that there’s an easy workaround for this. Instead of using Get-NetIPHttpsState, the administrator can retrieve essential information about the IP-HTTPS interface using the following netsh command.

netsh interface httpstunnel show interface

DirectAccess Get-NetIPHttpsState Fails on Windows 10 1803

Additional Information

SSL Certificate Considerations for DirectAccess IP-HTTPS 

Troubleshooting DirectAccess IP-HTTPS Error Code 0x800b0109

Troubleshooting DirectAccess IP-HTTPS Error Code 0x80090326

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Troubleshooting DirectAccess IP-HTTPS Error Code 0x2af9

Troubleshooting DirectAccess IP-HTTPS Error Code 0x800b0101

Always On VPN ECDSA SSL Certificate Request for SSTP

As I’ve discussed previously, it is strongly recommended that the TLS certificate used for SSTP be signed using the Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA provides better security and performance compared to RSA certificates for Windows 10 Always On VPN connections using SSTP. See my previous post Always On VPN SSL Certificate Requirements for SSTP for more information.

Certificate Signing Request

To generate a Certificate Signing Request (CSR) using ECDSA to send to a public Certification Authority (CA), open the local computer certificate store (certlm.msc) on any Windows server or client and follow the steps below.

  1. Expand Certificates – Local Computer.
  2. Right-click the Personal folder and choose All Tasks > Advanced Operations > Create Custom Request.
  3. Click Next.
  4. Select Proceed without enrollment policy.
  5. Click Next.
  6. From the Template drop-down list choose (No template) CNG key.
  7. Click Next.
  8. Click Details.Always On VPN ECDSA SSL Certificate Request for SSTP
  9. Click Properties.
  10. On the General tab enter a name in the Friendly name field.
  11. Click on the Subject tab.
    1. In the Subject name section, from the Type drop-down list choose Common name.
    2. In the Value field enter the VPN server’s public hostname and click Add.
    3. In the Alternative name section, from the Type drop-down list choose DNS.
    4. In the Value field enter the VPN server’s public hostname and click Add.Always On VPN ECDSA SSL Certificate Request for SSTP
  12. Click on the Extensions tab.
    1. Expand Extended Key Usage (application policies).
    2. Highlight Server Authentication.
    3. Click Add.Always On VPN ECDSA SSL Certificate Request for SSTP
  13. Click on the Private Key tab.
    1. Expand Cryptographic Service Provider.
    2. Uncheck RSA,Microsoft Software Key Storage Provider.
    3. Check ECDSA_P256,Microsoft Software Key Storage Provider.Always On VPN ECDSA SSL Certificate Request for SSTP
  14. Expand Key options.
    1. Select the option to Make private key exportable.Always On VPN ECDSA SSL Certificate Request for SSTP
  15. Click Ok.
  16. Click Next.
  17. Enter a name for the file in the File Name field.
  18. Click Finish.

Submit the Request

Once complete, submit the CSR for signing to your favorite public CA. Based on my experience, some CAs are easier to obtain ECDSA-signed certificates than other. Today, Digicert seems to be one of the better public CAs for obtaining EC TLS certificates.

Complete the Request

Once the CA has issued the certificate, import the certificate in to the local computer certificate store on the same client or server where the original CSR was created. The certificate can then be exported and imported on additional VPN servers, if required.

Additional Information

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN Protocol Recommendations for RRAS

 

Always On VPN Multisite with Azure Traffic Manager

Always On VPN Multisite with Azure Traffic ManagerEliminating single points of failure is crucial to ensuring the highest levels of availability for any remote access solution. For Windows 10 Always On VPN deployments, the Windows Server 2016 Routing and Remote Access Service (RRAS) and Network Policy Server (NPS) servers can be load balanced to provide redundancy and high availability within a single datacenter. Additional RRAS and NPS servers can be deployed in another datacenter or in Azure to provide geographic redundancy if one datacenter is unavailable, or to provide access to VPN servers based on the location of the client.

Multisite Always On VPN

Unlike DirectAccess, Windows 10 Always On VPN does not natively include support for multisite. However, enabling multisite geographic redundancy can be implemented using Azure Traffic Manager.

Azure Traffic Manager

Traffic Manager is part of Microsoft’s Azure public cloud solution. It provides Global Server Load Balancing (GSLB) functionality by resolving DNS queries for the VPN public hostname to an IP address of the most optimal VPN server.

Advantages and Disadvantages

Using Azure Traffic manager has some benefits, but it is not with some drawbacks.

Advantages – Azure Traffic Manager is easy to configure and use. It requires no proprietary hardware to procure, manage, and support.

Disadvantages – Azure Traffic Manager offers only limited health check options. Azure Traffic Manager’s HTTPS health check only accepts HTTP 200 OK responses as valid. Most TLS-based VPNs will respond with an HTTP 401 Unauthorized, which Azure Traffic Manager considers “degraded”. The only option for endpoint monitoring is a simple TCP connection to port 443, which is a less accurate indicator of endpoint availability.

Note: This scenario assumes that RRAS with Secure Socket Tunneling Protocol (SSTP) or another third-party TLS-based VPN server is in use. If IKEv2 is to be supported exclusively, it will still be necessary to publish an HTTP or HTTPS-based service for Azure Traffic Manager to monitor site availability.

Traffic Routing Methods

Azure Traffic Manager provide four different methods for routing traffic.

Priority – Select this option to provide active/passive failover. A primary VPN server is defined to which all traffic is routed. If the primary server is unavailable, traffic will be routed to another backup server.

Weighted – Select this option to provide active/active failover. Traffic is routed to all VPN servers equally, or unequally if desired. The administrator defines the percentage of traffic routed to each server.

Performance – Select this option to route traffic to the VPN server with the lowest latency. This ensures VPN clients connect to the server that responds the quickest.

Geographic – Select this option to route traffic to a VPN server based on the VPN client’s physical location.

Configure Azure Traffic Manager

Open the Azure management portal and follow the steps below to configure Azure Traffic Manager for multisite Windows 10 Always On VPN.

Create a Traffic Manager Resource

  1. Click Create a resource.
  2. Click Networking.
  3. Click Traffic Manager profile.

Create a Traffic Manager Profile

  1. Enter a unique name for the Traffic Manager profile.
  2. Select an appropriate routing method (described above).
  3. Select a subscription.
  4. Create or select a resource group.
  5. Select a resource group location.
  6. Click Create.

Always On VPN Multisite with Azure Traffic Manager

Important Note: The name of the Traffic Manager profile cannot be used by VPN clients to connect to the VPN server, since a TLS certificate cannot be obtained for the trafficmanager.net domain. Instead, create a CNAME DNS record that points to the Traffic Manager FQDN and ensure that name matches the subject or a Subject Alternative Name (SAN) entry on the VPN server’s TLS and/or IKEv2 certificates.

Endpoint Monitoring

Open the newly created Traffic Manager profile and perform the following tasks to enable endpoint monitoring.

  1. Click Configuration.
  2. Select TCP from the Protocol drop-down list.
  3. Enter 443 in the Port field.
  4. Update any additional settings, such as DNS TTL, probing interval, tolerated number of failures, and probe timeout, as required.
  5. Click Save.

Always On VPN Multisite with Azure Traffic Manager

Endpoint Configuration

Follow the steps below to add VPN endpoints to the Traffic Manager profile.

  1. Click Endpoints.
  2. Click Add.
  3. Select External Endpoint from the Type drop-down list.
  4. Enter a descriptive name for the endpoint.
  5. Enter the Fully Qualified Domain Name (FQDN) or the IP address of the first VPN server.
  6. Select a geography from the Location drop-down list.
  7. Click OK.
  8. Repeat the steps above for any additional datacenters where VPN servers are deployed.

Always On VPN Multisite with Azure Traffic Manager

Summary

Implementing multisite by placing VPN servers is multiple physical locations will ensure that VPN connections can be established successfully even when an entire datacenter is offline. In addition, active/active scenarios can be implemented, where VPN client connections can be routed to the most optimal datacenter based on a variety of parameters, including current server load or the client’s current location.

Additional Information

Windows 10 Always On VPN Hands-On Training Classes

Always On VPN Hands On Training Classes Coming to Dallas and San Francisco

Windows 10 Always On VPN Hands-On Training Classes for 2018Two more dates for my popular three-day Windows 10 Always On VPN Hands-On Training classes have been added to the schedule for 2018! Classes are now forming in Dallas, October 23-25 and in San Francisco, November 13-15, 2018. These training classes will cover all aspects of designing, implementing, and supporting an Always On VPN solution in the enterprise. The following topics will be covered in detail.

  • Windows 10 Always On VPN overview
  • Introduction to CSP
  • Infrastructure requirements
  • Planning and design considerations
  • Installation, configuration, and client provisioning

Advanced topics will include…

  • Redundancy and high availability+
  • Cloud-based deployments
  • Third-party VPN infrastructure and client support
  • Multifactor authentication
  • Always On VPN migration strategies

Windows 10 Always On VPN Hands-On Training Classes for 2018

Register Today

Reservations are being accepted now! The cost for this 3-day hands-on training class is $4995.00 USD. Space is limited, so don’t wait to register! Fill out the form below to save your seat now.

Group discounts are available! Private training sessions for large organizations are also available upon request.

Always On VPN Routing Configuration

Windows 10 Always On VPN Routing ConfigurationWhen configuring Windows 10 Always On VPN, the administrator must choose between force tunneling and split tunneling. When force tunneling is used, all network traffic from the VPN client is routed over the VPN tunnel. When split tunneling is used, the VPN client must be configured with the necessary IP routes to establish remote network connectivity to on-premises resources. How those routes are established is a common source of confusion. This article provides guidance for properly configuring routing for Always On VPN clients.

Class Based Routing

IP addresses are assigned to Windows 10 Always On VPN clients from either a static pool of addresses configured by the administrator or by DHCP. If split tunneling is enabled, the client will also be assigned a class-based route that is derived from the IP address assigned to it by the VPN server, by default. If the client is assigned an IP address from the Class A network, a corresponding /8 prefix is used. For Class B networks a /16 prefix is defined, and for Class C networks a /24 prefix is used.

As an example, if the VPN server assigns the client an IP address of 10.21.12.103, a route to the 10.0.0.0/8 network is added to the client’s routing table, as shown here.

Windows 10 Always On VPN Routing Configuration

Complex Networks

This default class-based route is of limited use though, and is only applicable when the internal network is simple and VPN clients are assigned IP addresses from the same subnet class. In the example above, if the entire internal network resides in the 10.0.0.0/8 Class A address space, all resources will be reachable by the VPN client. Any resources in the Class B or Class C subnet ranges would be unreachable without additional configuration.

Route Configuration

To configure routing for Windows 10 Always On VPN clients, first disable the default class-based route by defining the following element in ProfileXML as shown here.

<VPNProfile>
   <NativeProfile>
      <DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
   </NativeProfile>
</VPNProfile>

Next, enable specific routes as needed by defining the following element(s) in ProfileXML. The example below defines routes for all private RFC 1918 networks.

<VPNProfile>
   <Route>
      <Address>10.0.0.0</Address>
      <PrefixSize>8</PrefixSize>
   </Route>
   <Route>
      <Address>172.16.0.0</Address>
      <PrefixSize>12</PrefixSize>
   </Route>
   <Route>
      <Address>192.168.0.0</Address>
      <PrefixSize>16</PrefixSize>
   </Route>
</VPNProfile>

Once implemented, the VPN client’s routing table will appear as shown here.

Windows 10 Always On VPN Routing Configuration

Summary

Proper routing is crucial for ensuring full network connectivity and access to internal resources for Windows 10 Always On VPN clients. When split tunneling is employed, avoid using the default class-based route and instead define specific routes using ProfileXML as required.

Additional Information

Always On VPN Client DNS Server Configuration

Deploying Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Certificate Requirements for SSTP

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN Certificate Requirements for SSTPThe Windows Server 2016 Routing and Remote Access Service (RRAS) is commonly deployed as a VPN server for Windows 10 Always On VPN deployments. Using RRAS, Always On VPN administrators can take advantage of Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP) VPN protocol. SSTP is a Transport Layer Security (TLS) based VPN protocol that uses HTTPS over the standard TCP port 443 to encapsulate and encrypt communication between the Always On VPN client and the RRAS VPN server. SSTP is a firewall-friendly protocol that ensures ubiquitous remote network connectivity. Although IKEv2 is the protocol of choice when the highest level of security is required for VPN connections, SSTP can still provide very good security when implementation best practices are followed.

SSTP Certificate

Since SSTP uses HTTPS for transport, a common SSL certificate must be installed in the Local Computer/Personal/Certificates store on the RRAS VPN server. The certificate must include the Server Authentication Enhanced Key Usage (EKU) at a minimum. Often SSL certificates include both the Server Authentication and Client Authentication EKUs, but the Client Authentication EKU is not strictly required. The subject name on the certificate, or at least one of the Subject Alternative Name entries, must match the public hostname used by VPN clients to connect to the VPN server. Multi-SAN (sometimes referred to as UC certificates) and wildcard certificates are supported.

Always On VPN Certificate Requirements for SSTP

Certification Authority

It is recommended that the SSL certificate used for SSTP be issued by a public Certification Authority (CA). Public CAs typically have their Certificate Revocation Lists (CRLs) hosted on robust, highly available infrastructure. This reduces the chance of failed VPN connection attempts caused by the CRL being offline or unreachable.

Using an SSL certificate issued by an internal, private CA is supported if the CRL for the internal PKI is publicly available.

Key Type

RSA is the most common key type used for SSL certificates. However, Elliptic Curve Cryptography (ECC) keys offer better security and performance, so it is recommended that the SSTP SSL certificate be created using an ECC key instead.

Always On VPN Certificate Requirements for SSTP

To use an ECC key, be sure to specify the use of a Cryptographic Next Generation (CNG) key and select the ECDSA_P256 Microsoft Software Key Storage Provider (CSP) (or greater) when creating the Certificate Signing Request (CSR) for the SSTP SSL certificate.

Always On VPN Certificate Requirements for SSTP

Most public CAs will support certificate signing using ECC and Elliptic Curve Digital Signature Algorithm (ECDSA). If yours does not, find a better CA. 😉

Forward Secrecy

Forward secrecy (sometimes referred to as perfect forward secrecy, or PFS) ensures that session keys can’t be compromised even if the server’s private key is compromised. Using forward secrecy for SSTP is crucial to ensuring the highest levels of security for VPN connections.

To enforce the use of forward secrecy, the TLS configuration on the VPN server should be prioritized to prefer cipher suites with Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

Authenticated Encryption

Authenticated encryption (AE) and authenticated encryption with associated data (AEAD) is a form of encryption that provides better data protection and integrity compared to older block or stream ciphers such as CBC or RC4.

To enforce the use of authenticated encryption, the TLS configuration on the VPN server should be prioritized to prefer cipher suites that support Galois/Counter Mode (GCM) block ciphers.

Important Note: In Windows Server 2016, GCM ciphers can be used with both RSA and ECC certificates. However, in Windows Server 2012 R2 GCM ciphers can only be used when an ECC certificate is used.

SSL Offload

Offloading SSL to a load balancer or application delivery controller (ADC) can be enabled to improve scalability and performance for SSTP VPN connections. I will cover SSL offload for SSTP in detail in a future post.

Summary

SSTP can provide good security for VPN connections when implementation and security best practices are followed. For optimum security, use an SSL certificate with an EC key and optimize the TLS configuration to use forward secrecy and authenticated cipher suites.

Additional Information

Always On VPN ECDSA SSL Certificate Request for SSTP

Always On VPN and Windows Server Routing and Remote Access Service (RRAS)

Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN Certificate Requirements for IKEv2

3 Important Advantages of Always On VPN over DirectAccess

Microsoft SSTP Specification on MSDN

%d bloggers like this: