Always On VPN and IKEv2 Fragmentation

The IKEv2 protocol is a popular choice when designing an Always On VPN solution. When configured correctly it provides the best security compared to other protocols. The protocol is not without some unique challenges, however. IKEv2 is often blocked by firewalls, which can prevent connectivity. Another lesser know issue with IKEv2 is that of fragmentation. This can result in failed connectivity that can be difficult to troubleshoot.

IP Fragmentation

IKEv2 uses UDP for transport, and typically most packets are relatively small. The exception to this is when authentication takes place, especially when using client certificate authentication. The problem is further complicated by long certificate chains and by RSA keys, especially those that are greater than 2048 bit. If the payload exceeds 1500 bytes, the IP packet will have to be broken in to smaller fragments to be sent over the network. If an intermediary device in the path is configured to use a smaller Maximum Transmission Unit (MTU), that device may fragment the IP packets.

IP Fragmentation and Firewalls

Many routers and firewalls are configured to drop IP fragments by default. When this happens, IKEv2 communication may begin initially, but subsequently fail. This typically results in an error code 809 with a message stating 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

Troubleshooting

When troubleshooting potential IKEv2 fragmentation-related connection failures, a network trace should be taken of the connection attempt on the client. Observe the packet sizes during the conversation, especially IKE_AUTH packets. Packet sizes exceeding the path MTU will have to be fragmented, as shown here.

Always On VPN and IKEv2 Fragmentation

Measuring Path MTU

Measuring the path MTU between the client and server can be helpful when troubleshooting fragmentation related issues. The mtupath.exe utility is an excellent and easy to use tool for this task. The tool can be downloaded here.

Always On VPN and IKEv2 Fragmentation

IKEv2 Fragmentation

To address the challenges with IP fragmentation and potential connectivity issues associated with network devices dropping fragmented packets, the IKEv2 protocol itself can be configured to perform fragmentation at the IKE layer. This eliminates the need for IP layer fragmentation, resulting in better reliability for IKEv2 VPN connections.

Both the server and the client must support IKEv2 fragmentation for this to occur. Many firewall and VPN vendors include support for IKEv2 fragmentation. Consult the vendor’s documentation for configuration guidance. For Windows Server Routing and Remote Access (RRAS) servers, the feature was first introduced in Windows Server 1803 and is supported in Windows Server 2019. Windows 10 clients support IKEv2 fragmentation beginning with Windows 10 1803.

Enabling IKEv2 Fragmentation

Windows 10 clients support IKEv2 fragmentation by default. However, it must be enabled on the server via the registry. The following PowerShell command will enable IKEv2 fragmentation support on Windows Server 1803 and later.

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

Validation Testing

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 IKEv2 Security Configuration

RFC 7383 – IKEv2 Message Fragmentation

IEA Software MTU Path Scan Utility

Windows 10 Always On VPN Hands-On Training Classes

Always On VPN and Network Policy Server (NPS) Load Balancing

Always On VPN and Network Policy Server (NPS) Load BalancingLoad balancing Windows Server Network Policy Servers (NPS) is straightforward in most deployment scenarios. Most VPN servers, including Windows Server Routing and Remote Access Service (RRAS) servers allow the administrator to configure multiple NPS servers for redundancy and scalability. In addition, most solutions support weighted distribution, allowing administrators to distribute requests evenly between multiple NPS servers (round robin load balancing) or to distribute them in order of priority (active/passive failover).

The Case for NPS Load Balancing

Placing NPS servers behind a dedicated network load balancing appliance is not typically required. However, there are some deployment scenarios where doing so can provide important advantages.

Deployment Flexibility

Having NPS servers fronted by a network load balancer allows the administrator to configure a single, virtual IP address and hostname for the NPS service. This provides deployment flexibility by allowing administrators to add or remove NPS servers without having to reconfigure VPN servers, network firewalls, or VPN clients. This can be beneficial when deploying Windows updates, migrating NPS servers to different subnets, adding more NPS servers to increase capacity, or performing rolling upgrades of NPS servers.

Traffic Shaping

Dedicated network load balancers allow for more granular control and of NPS traffic. For example, NPS routing decisions can be based on real server availability, ensuring that authentication requests are never sent to an NPS server that is offline or unavailable for any reason. In addition, NPS traffic can be distributed based on server load, ensuring the most efficient use of NPS resources. Finally, most load balancers also support fixed or weighted distribution, enabling active/passive failover scenarios if required.

Traffic Visibility

Using a network load balancer for NPS also provides better visibility for NPS authentication traffic. Most load balancers feature robust graphical displays of network utilization for the virtual server/service as well as backend servers. This information can be used to ensure enough capacity is provided and to monitor and plan for additional resources when network traffic increases.

Configuration

Before placing NPS servers behind a network load balancer, the NPS server certificate must be specially prepared to support this unique deployment scenario. Specifically, the NPS server certificate must be configured with the Subject name of the cluster, and the Subject Alternative Name field must include both the cluster name and the individual server’s hostname.

Always On VPN and Network Policy Server (NPS) Load Balancing

Always On VPN and Network Policy Server (NPS) Load Balancing

Create Certificate Template

Perform the following steps to create a certificate template in AD CS to support NPS load balancing.

  1. Open the Certificate Templates management console (certtmpl.msc) on the certification authority (CA) server or a management workstation with remote administration tool installed.
  2. Right-click the RAS and IAS Servers default certificate template and choose Duplicate.
  3. Select the Compatibility tab.
    1. Select Windows Server 2008 or a later version from the Certification Authority drop-down list.
    2. Select Windows Vista/Server 2008 or a later version from the Certificate recipient drop-down list.
  4. Select the General tab.
    1. Enter a descriptive name in the Template display name field.
    2. Choose an appropriate Validity period and Renewal period.
    3. Do NOT select the option to Publish certificate in Active Directory.
  5. Select the Cryptography tab.
    1. Chose Key Storage Provider from the Provider Category drop-down list.
    2. Enter 2048 in the Minimum key size field.
    3. Select SHA256 from the Request hash drop-down list.
  6. Select the Subject Name tab.
    1. Select the option to Supply in the request.
  7. Select the Security tab.
    1. Highlight RAS and IAS Servers and click Remove.
    2. Click Add.
    3. Enter the security group name containing all NPS servers.
    4. Check the Read and Enroll boxes in the Allow column in the Permissions for [group name] field.
  8. Click Ok.

Perform the steps below to publish the new certificate template in AD CS.

  1. Open the Certification Authority management console (certsrv.msc) on the certification authority (CA) server or a management workstation with remote administration tool installed.
  2. Expand Certification Authority (hostname).
  3. Right-click Certificate Templates and choose New and Certificate Template to Issue.
  4. Select the certificate template created previously.
  5. Click Ok.

Request Certificate on NPS Server

Perform the following steps to request a certificate for the NPS server.

  1. Open the Certificates management console (certlm.msc) on the NPS server.
  2. Expand the Personal folder.
  3. Right-click Certificates and choose All Tasks and Request New Certificate.
  4. Click Next.
  5. Click Next.
  6. Select the NPS server certificate template and click More information is required to enroll for this certificate link.
  7. Select the Subject tab.
    1.  Select Common name from the Type drop-down list in the Subject name section.
    2. Enter the cluster fully-qualified hostname (FQDN) in the Value field.
    3. Click Add.
    4. Select DNS from the Type drop-down list in the Alternative name section.
    5. Enter the cluster FQDN in the Value field.
    6. Click Add.
    7. Enter the NPS server’s FQDN in the Value field.
    8. Click Add.
      Always On VPN and Network Policy Server (NPS) Load Balancing
  8. Select the General tab.
    1. Enter a descriptive name in the Friendly name field.
  9. Click Ok.
  10. Click Enroll.

Load Balancer Configuration

Configure the load balancer to load balance UDP ports 1812 (authentication) and 1813 (accounting). Optionally, to ensure that authentication and accounting requests go to the same NPS server, enable source IP persistence according to the vendor’s guidance. For the KEMP LoadMaster load balancer, the feature is called “port following”. On the F5 BIG-IP it is called a “persistence profile”, and on the Citrix NetScaler it is called a “persistency group”.

Additional Information

Always On VPN IKEv2 Load Balancing with KEMP LoadMaster

Always On VPN Hands-On Training Classes in U.S. and Europe

Always On VPN IKEv2 Connection Failure Error Code 800

Always On VPN administrators may encounter a scenario in which Windows 10 clients are unable to establish an IKEv2 VPN connection to a Windows Server Routing and Remote Access Service (RRAS) server or a third-party VPN device under the following conditions.

  1. The VPN connection is configured using ProfileXML.
  2. ProfileXML includes the <CryptographySuite> element.
  3. The VPN server is configured to use a custom IPsec policy.
  4. The VPN server supports only IKEv2.
  5. The <NativeProtocolType> in ProfileXML is set to Automatic.

When these specific conditions are met, the client will be unable to connect to the VPN server using IKEv2. The error message states:

The remote connection was not made because the attempted VPN tunnels failed. The VPN server might be unreachable. If this connection is attempting to use an L2TP/IPsec tunnel, the security parameters required for IPsec negotiation might not be configured properly.

Always On VPN IKEv2 VPN Connection Failure Error Code 800

In addition, the event log will include an error message from the RasClient source with event ID 20227 that includes the following error message.

The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 800.

Always On VPN IKEv2 VPN Connection Failure Error Code 800

A manually configured VPN connection using IKEv2 will connect successfully under these same conditions, however.

IKEv2 Error Code 800

Error code 800 translates to ERROR_AUTOMATIC_VPN_FAILED, which is somewhat ambiguous. The error description is:

Unable to establish the VPN connection. The VPN server may be unreachable, or security parameters may not be configured properly for this connection.

Digging Deeper

A network trace of the IKEv2 VPN connection reveals the true source of the problem, which is a failure of the client and server to successfully negotiate an IKEv2 security association (SA). During the SA initiation process, the parameters offered by the client are unacceptable to the server, resulting in a NO_PROPOSAL_CHOSEN notification being returned by the server.

Always On VPN IKEv2 VPN Connection Failure Error Code 800

Custom Cryptography Settings Ignored

It appears that the Always On VPN connection ignores the custom cryptography settings defined in the CryptographySuite element in ProfileXML. However, this only occurs when the NativeProtocolType is set to Automatic. Presumably, this is a bug. 🙂

Workaround

As a workaround, set the NativeProtocolType to IKEv2. When NativeProtocolType is set to IKEv2, the VPN connection recognizes the IKEv2 parameters defined in the CryptographySuite element and the VPN connection will be established successfully.

Additional Information

Always On VPN IKEv2 Security Configuration

Always On VPN Certificate Requirements for IKEv2

Always On VPN IKEv2 Load Balancing with the KEMP LoadMaster Load Balancer

Always On VPN IKEv2 Security Configuration

Always On VPN IKEv2 Security ConfigurationWhen deploying Windows 10 Always On VPN, many administrators choose the Internet Key Exchange version 2 (IKEv2) protocol to provide the highest level of security and protection for remote connections. However, many do not realize the default security parameters for IKEv2 negotiated between a Windows Server running the Routing and Remote Access Service (RRAS) and a Windows 10 VPN client are far less than ideal from a security perspective. Additional configuration on both the server and the client will be required to ensure adequate security and protection for IKEv2 VPN connections.

Windows 10 and RRAS IKEv2 Defaults

In their default configuration, a Windows 10 client connecting to a Windows Server running RRAS will negotiate an IKEv2 VPN connection using the following IPsec security parameters.

  • Encryption: 3DES
  • Authentication/Integrity: SHA-1
  • Key Size: DH Group 2 (1024 bit)

This information can be obtained by opening an elevated PowerShell command window and running the following command.

Get-NetIPsecMainModeSA | Select-Object -First 1

Always On VPN IKEv2 Security Configuration

This can also be confirmed by viewing a network trace as shown here.

Always On VPN IKEv2 Security Configuration

These IPsec security parameters might have been acceptable in the 90’s, but they certainly are not today. 🙂

Improving IKEv2 Security

To provide a baseline level of protection to meet today’s requirements for security and privacy for IKEv2 VPN connections, the following are the minimum recommended IPsec security parameters.

  • Encryption: AES128
  • Authentication/Integrity: SHA-256
  • Key Size: DH Group 14 (2048 bit)

RRAS Custom IPsec Policy

To implement these recommended security baselines for IKEv2 on a Windows Server running RRAS it will be necessary to define a custom IPsec security policy. To do this, open an elevated PowerShell command window and run the following commands on each RRAS server.

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SADataSizeForRenegotiationKilobytes 102400

Restart the Remote Access Management service for the changes to take effect.

Restart-Service RaMgmtSvc -PassThru

Always On VPN IKEv2 Security Configuration

Windows 10 Client Settings

The IPsec policy must match on both the server and the client for an IKEv2 VPN connection to be successful. Unfortunately, none of the IKEv2 IPsec security association parameters proposed by default on Windows 10 clients use 2048-bit keys (DH Group 14), so it will be necessary to define a custom IPsec security policy on the client to match the settings configured on the server.

To configure a matching IPsec security policy on an individual Windows 10 VPN client, open an elevated PowerShell command window and run the following command.

$connection = “[connection name]”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

Always On VPN IKEv2 Security Configuration

Restore Defaults

In the process of testing it may be necessary to restore the default IKEv2 configuration on both the client and the server. This can be accomplished by running the following PowerShell commands.

Server – Set-VpnServerConfiguration -RevertToDefault

Client – Set-VpnConnectionIPsecConfiguration -ConnectionName [connection_name] -RevertToDefault -Force

Always On VPN XML Settings

To implement a custom IPsec policy using the minimum recommended security settings for an Always On VPN connection using IKEv2, add the following settings to your ProfileXML.

<VPNProfile>
 <NativeProfile>
  <CryptographySuite>
   <AuthenticationTransformConstants>SHA256128</AuthenticationTransformConstants>
   <CipherTransformConstants>AES128</CipherTransformConstants>
   <EncryptionMethod>AES128</EncryptionMethod>
   <IntegrityCheckMethod>SHA256</IntegrityCheckMethod>
   <DHGroup>Group14</DHGroup>
   <PfsGroup>PFS2048</PfsGroup>
  </CryptographySuite>
 </NativeProfile>
</VPNProfile>

Why Not AES 256?

In the examples above you’ll notice that I’ve chosen to use AES128 and not AES256. This is by design, as AES256 does not provide any practical additional security in most use cases. Details here.

Enhanced Security and Performance

To further improve security and performance for IKEv2, consider implementing Elliptic Curve Cryptography (EC) certificates and using Galois Counter Mode (GCM) cipher suites such as GCMAES128 for authentication and encryption.

Additional Information

Always On VPN Certificate Requirements for IKEv2

Always On VPN IKEv2 Connection Failure Error Code 800

Always On VPN IKEv2 Load Balancing with the KEMP LoadMaster Load Balancer

Troubleshooting Always On VPN Error Code 0x80092013

Troubleshooting Always On VPN Error Code 0x80092013Windows Server Routing and Remote Access Service (RRAS) is commonly used for Windows 10 Always On VPN deployments because it is easy to configure and manage and it includes Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP). SSTP is a Transport Layer Security (TLS) VPN protocol that is firewall-friendly and ubiquitously available. However, a common configuration mistake can lead to failed connections.

Error 0x80092013

A Windows 10 Always On VPN client may fail to establish a VPN connection to an RRAS VPN server when using SSTP. The VPN client will return the following error message.

“Can’t connect to Always On VPN. The revocation function was unable to check revocation because the revocation server was offline.”

Troubleshooting Always On VPN Error Code 0x80092013

The event log will also include RasClient event ID 20227 with the following error.

“The user [domain\user] dialed a connection named [connection name] which has failed. The error code returned on failure is -2146885613.”

Troubleshooting Always On VPN Error Code 0x80092013

The Win32 error code –2146885613 converts to hexadecimal 0x80092013, which translates to CRYPT_E_REVOCATION_OFFLINE, indicating that the client was unable to successfully perform a check of the VPN server’s SSL certificate.

Revocation Checking

When the VPN client attempts to establish an SSTP connection to the Windows RRAS VPN, it will check the Certification Revocation List (CRL) using the information provided in the SSL certificate. If the CRL is unreachable for any reason, the client will not complete the connection

Common Cause of Error 0x80092013

Certificate revocation failures for Windows 10 Always On VPN SSTP connections commonly occur when the RRAS VPN server is configured with an SSL certificate issued by an internal certification authority (CA) and the CRL is not publicly available.

Resolving Error 0x80092013

Making the internal CA’s CRL available publicly will of course resolve this error. However, best practice recommendations for the SSTP SSL certificate call for the use of a certificate issued by a public CA. For detailed information about SSL certificate requirements and recommendations, please see Always On VPN SSL Certificate Requirements for SSTP.

Additional Information

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN ECDSA SSL Certificate Request for SSTP

Always On VPN Protocol Recommendations for Windows RRAS

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 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

Deploying Windows 10 Always On VPN with Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft IntuneWindows 10 Always On VPN is the replacement for Microsoft’s popular DirectAccess remote access solution. It provides the same seamless, transparent, always on remote connectivity as DirectAccess. Where DirectAccess relied heavily on classic on-premises infrastructure such as Active Directory and Group Policy, Always On VPN is infrastructure independent and is designed to be provisioned and managed using a Mobile Device Management (MDM) platform such as Microsoft Intune.

Intune and Always On VPN

Until recently, provisioning Windows 10 Always On VPN connections involved manually creating a ProfileXML and uploading to Intune using a custom profile. This has proven to be challenging for many, as the process is unintuitive and error prone.

A recent Intune update now allows administrators to create a basic Windows 10 Always On VPN deployment. Although it still has its limitations, it will go a long way to making the adoption of Always On VPN easier.

Prerequisites

Certificates must first be provisioned to all clients before deploying Windows 10 Always On VPN using Intune. In addition, if using a third-party VPN client, the VPN plug-in software must be installed prior to deploying the VPN profile.

Test VPN Connection

It is recommended that a test VPN connection be created on a client machine locally before deploying an Always On VPN profile using Intune. This allows the administrator to test connectivity and validate Extensible Authentication Protocol (EAP) settings. Once complete, run the following PowerShell commands to extract the EAP configuration settings to a file for later publishing with Intune.

$Vpn = Get-VpnConnection -Name [Test VPN connection name]
$Xml = $Vpn.EapConfigXmlStream.InnerXml | Out-File .\eapconfig.xml -Encoding ASCII

Deploying Always On VPN with Intune

Follow the steps below to deploy an Always On VPN connection using Intune.

Create a VPN Profile

  1. Open the Microsoft Intune management portal.
  2. Click Device configuration.
  3. Click Profiles.
  4. Click Create profile.

Deploying Windows 10 Always On VPN with Microsoft Intune

  1. Enter a name for the VPN profile.
  2. Enter a description (optional).
  3. From the Platform drop-down menu select Windows 10 and later.
  4. From the Profile type drop-down menu select VPN.
  5. In the Settings section click Configure.

Deploying Windows 10 Always On VPN with Microsoft Intune

Define VPN Profile Settings

  1. Click Base VPN.
  2. Enter a name for the connection.
  3. Enter a description and provide the Fully Qualified Domain Name (FQDN) of the VPN server. If it will be the default server select True and click Add.
  4. Enter a description and provide the FQDN for any additional VPN servers, as required.
  5. From the Connection type drop-down list choose the preferred connection type.
  6. In the Always On section click Enable.
  7. Select Enable to Remember credentials at each logon (optional).
  8. Click Select a certificate.
  9. Choose a client authentication certificate and click Ok.
  10. Paste the contents of eapconfig.xml (saved previously) in the EAP Xml field.
  11. Click Ok.

Deploying Windows 10 Always On VPN with Microsoft Intune

Define Additional Settings

You can also configure the following optional VPN settings using Intune.

  • Apps and Traffic Rules
  • Conditional Access
  • DNS Settings
  • Proxy
  • Split Tunneling

Deploying Windows 10 Always On VPN with Microsoft Intune

After configuring any required additional settings, click Create.

Assign VPN Profile

  1. Click Assignments.
  2. From the Assign to drop-down menu choose Selected Groups.
  3. Click Select groups to include.
  4. Choose an Azure Active Directory group to apply the VPN profile and click Select.
  5. Click Save.

Deploying Windows 10 Always On VPN with Microsoft Intune

Limitations

Although the ability to provision Always On VPN using Microsoft Intune without using a custom profile is welcome, it is not without its limitations. At the time of this writing, only Always On VPN user profiles can be configured. A device tunnel, which is optional, must be configured manually using a custom profile. In addition, the Intune user interface lacks the ability to define settings for the following parameters:

  • Exclusion routes
  • Name Resolution Policy Table (NRPT) exemptions
  • Lockdown mode
  • DNS registration
  • Trusted network detection
  • Custom IKEv2 cryptography policy

To make changes to the default settings for any of the above parameters, a ProfileXML must be created manually and provisioned with Intune using a custom policy.

Additional Information

Windows 10 Always On VPN Device Tunnel Step-by-Step Configuration using PowerShell

Windows 10 Always On VPN Certificate Requirements for IKEv2

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

Windows 10 Always On VPN Hands-On Training

Always On VPN Certificate Requirements for IKEv2

Always On VPN Certificate Requirements for IKEv2Internet Key Exchange version 2 (IKEv2) is one of the VPN protocols supported for Windows 10 Always On VPN deployments. When the VPN server is Windows Server 2016 with the Routing and Remote Access Service (RRAS) role configured, a computer certificate must first be installed on the server to support IKEv2. There are some unique requirements for this certificate, specifically regarding the subject name and Enhanced Key Usage (EKU) configuration. In addition, some deployment scenarios may require a certificate to be provisioned to the client to support IKEv2 VPN connections.

Server Certificate

The IKEv2 certificate on the VPN server must be issued by the organization’s internal private certification authority (CA). It must be installed in the Local Computer/Personal certificate store on the VPN server. The subject name on the certificate must match the public hostname used by VPN clients to connect to the server, not the server’s hostname. For example, if the VPN server’s hostname is VPN1 and the public FQDN is vpn.example.net, the subject field of the certificate must include vpn.example.net, as shown here.

Always On VPN Certificate Requirements for IKEv2

In addition, the certificate must include the Server Authentication EKU (1.3.6.1.5.5.7.3.1). Optionally, but recommended, the certificate should also include the IP security IKE intermediate EKU (1.3.6.1.5.5.8.2.2).

Always On VPN Certificate Requirements for IKEv2

Client Certificate

Client certificate requirements vary depending on the type of VPN tunnel and authentication method being used.

User Tunnel

No certificates are required on the client to support IKEv2 when using MSCHAPv2, EAP-MSCHAPv2, or Protected EAP (PEAP) with MSCHAPv2. However, if the option to verify the server’s identity by validating the certificate is selected when using PEAP, the client must have the certificates for the root CA and any subordinate CAs installed in its Trusted Root Certification and Intermediate Certificate Authorities certificate stores, respectively.

User Tunnel with Certificate Authentication

Using certificate authentication for the user tunnel is the recommended best practice for Always On VPN deployments. A client certificate must be installed in the Current User/Personal store to support PEAP authentication with smart card or certificate authentication. The certificate must include the Client Authentication EKU (1.3.6.1.5.5.7.3.2).

Always On VPN Certificate Requirements for IKEv2

Device Tunnel

A computer certificate must be installed in the Local Computer/Personal certificate store to support IKEv2 machine certificate authentication and the Always On VPN device tunnel. The certificate must include the Client Authentication EKU (1.3.6.1.5.5.7.3.2).

Always On VPN Certificate Requirements for IKEv2

More information about configuring the Always On VPN device tunnel can be found here.

Additional Information

Always On VPN with Trusted Platform Module (TPM) Certificates

Always On VPN Protocol Recommendations for Windows Server 2016 RRAS

Always On VPN and Windows Server RRAS

Always On VPN Training

DirectAccess IP-HTTPS and Symantec SSL Certificates

DirectAccess IP-HTTPS and Symantec SSL CertificatesAn SSL certificate is required to support the IP-HTTPS IPv6 transition technology when configuring DirectAccess. Implementation best practices dictate using a public SSL certificate signed by a trusted third-party vendor such as Entrust, Verisign, DigiCert, and others. SSL certificates issued by a private PKI are acceptable if the client trusts the issuing CA. Self-signed certificates are supported in some deployment scenarios, but their use is generally discouraged. For more detailed information regarding SSL certificate considerations for DirectAccess IP-HTTPS click here.

Symantec Issued Certificates

Symantec is a popular commercial SSL certificate provider that has been commonly used for many years. However, due to integrity issues associated with their PKI management practices, Google and Mozilla announced they will soon be deprecating these certificates. This means users who browse to an HTTPS web site protected with a Symantec SSL certificate will receive a warning in their browser indicating the certificate is not trusted.

DirectAccess IP-HTTPS

It is important to note that there is no impact at all for DirectAccess when the server is configured to use an SSL certificate issued by Symantec. There is nothing you need to do to address this issue in this scenario. However, if a wildcard certificate is installed on the DirectAccess server and it is also used on other public-facing web servers in the organization, it is likely that the certificate will replaced, perhaps by another certificate provider. In this case, DirectAccess IP-HTTPS must be configured to use the new or updated SSL certificate.

Updating IP-HTTPS SSL Certificate

To update the DirectAccess IP-HTTPS SSL certificate, import the SSL certificate along with the private key in to the local computer certificate store on each DirectAccess server. Next identify the thumbprint of the new SSL certificate. Finally, open an elevated PowerShell command window and enter the following command.

$thumbprint = “ssl_cert_thumbprint”
$cert = Get-ChildItem -Path cert:\localmachine\my | where {$_.thumbprint -eq $thumbprint}
Set-RemoteAccess -SslCertificate $cert -PassThru

Be sure to replace “ssl_cert_thumbprint” with the actual thumbprint of your SSL certificate. 😉 In addition, for load-balanced and/or multisite deployments, run these PowerShell commands on each server in the enterprise.

Additional Information

SSL Certificate Considerations for DirectAccess IP-HTTPS

DirectAccess IP-HTTPS Null Cipher Suites Not Available 

DirectAccess IP-HTTPS Performance Issues

%d bloggers like this: