Always On VPN Updates to Improve Connection Reliability

Always On VPN Updates to Improve Connection ReliabilityA longstanding issue with Windows 10 Always On VPN is that of VPN tunnel connectivity reliability and device tunnel/user tunnel interoperability. Many administrators have reported that Always On VPN connections fail to establish automatically at times, that only one tunnel comes up at a time (user tunnel or device tunnel, but not both), or that VPN tunnels fail to establish when coming out of sleep or hibernate modes. Have a look at the comments on this post and you’ll get a good understanding of the issues with Always On VPN.

Recent Updates

The good news is that most of these issues have been resolved with recent updates to Windows 10 1803 and 1809. Specifically, the February 19, 2019 update for Windows 10 1803 (KB4487029) and the March 1, 2019 update for Windows 10 1809 (KB4482887) include fixes to address these known issues. Administrators are encouraged to deploy Windows 10 1803 with the latest updates applied when implementing Always On VPN. Windows 10 1809 with the latest updates applied is preferred though.

Persistent Issues

Although initial reports are favorable for these updates and based on my experience the effectiveness and reliability of Windows 10 Always On VPN is greatly improved, there have still been some reports of intermittent VPN tunnel establishment failures.

Possible Causes

During my testing, after applying the updates referenced earlier both device tunnel and user tunnel connections are established much more consistently than before the updates were applied. I did encounter some issues, however. Specifically, when coming out of sleep or hibernate, VPN connections would fail to establish. Occasionally VPN connections would fail after a complete restart.

NCSI

After further investigation it was determined that the connectivity failure was caused by the Network Connectivity Status Indicator (NCSI) probe failing, causing Windows to report “No Internet access”.

Always On VPN Updates to Improve Connection Reliability

Cisco Umbrella Roaming Client

In this instance the NCSI probe failure was caused by the Cisco Umbrella Roaming Client installed and running on the device. The Umbrella Roaming Client is security software that provides client protection by monitoring and filtering DNS queries. It operates by configuring a DNS listener on the loopback address. NCSI probes are known to fail when the DNS server is running on a different interface than is being tested.

Resolution

Microsoft released a fix for this issue in Windows 10 1709. The fix involves changing a group policy setting to disable interface binding when perform DNS lookups by the NCSI. You can enable this setting via Active Directory group policy by navigating to Computer Configuration > Administrative Templates > Network > Network Connectivity Status Indicator > Specify global DNS. Select Enabled and check the option to Use global DNS, as shown here.

Always On VPN Updates to Improve Connection Reliability

For testing purposes this setting can be enabled individual using the following PowerShell command.

New-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\” -Name UseGlobalDNS -PropertyType DWORD -Value 1 -Force

Third-Party Software

As Always On VPN connectivity can be affected by NCSI, any third-party firewall or antivirus/antimalware solution could potentially introduce VPN connection instability. Observe NCSI operation closely when troubleshooting unreliable connections with Always On VPN.

Additional Information

Windows 10 1803 Update KB4487029

Windows 10 1809 Update KB4482887

Cisco Umbrella Roaming Client Limited Network Connectivity Warning

Network Connectivity Status Indicator (NCSI) Operation Explained

Always On VPN IKEv2 Features and Limitations

Always On VPN IKEv2 Features and LimitationsThe Internet Key Exchange version 2 (IKEv2) VPN protocol is a popular choice for Windows 10 Always On VPN deployments. IKEv2 is a standards-based IPsec VPN protocol with customizable security parameters that allows administrators to provide the highest level of protection for remote clients. In addition, it provides important interoperability with a variety of VPN devices, including Microsoft Windows Server Routing and Remote Access Service (RRAS) and non-Microsoft platforms such as Cisco, Checkpoint, Palo Alto, and others.

IKEv2 Limitations

IKEv2 is clearly the protocol of choice in terms of security. It supports modern cryptography and is highly resistant to interception. It’s not without some operational challenges, however. Consider the following.

Firewalls

IKEv2 uses UDP ports 500 and 4500 for communication. Unfortunately, these ports are not always open. Often, they are blocked by network administrators to prevent users from bypassing security controls or attackers from exfiltrating data.

Fragmentation

IKEv2 packets can become quite large at times, especially when using client certificate authentication with the Protected Extensible Authentication Protocol (PEAP). This can result in fragmentation occurring at the network layer. Unfortunately, many firewalls and network devices are configured to block IP fragments by default. This can result in failed connection attempts from some locations but not others.

Load Balancing

Load balancing IKEv2 connections is not entirely straightforward. Without special configuration, load balancers can cause intermittent connectivity issues for Always On VPN connections. Guidance for configuring IKEv2 load balancing on the Kemp LoadMaster and the F5 BIG-IP can be found here:

IKEv2 Fragmentation

IKEv2 fragmentation can be enabled to avoid IP fragmentation and restore reliable connectivity. IKEv2 fragmentation is supported in Windows 10 and Windows Server beginning with v1803. Guidance for enabling IKEv2 fragmentation on Windows Server RRAS can be found here. Support for IKEv2 fragmentation on non-Microsoft firewall/VPN devices is vendor-specific. Consult with your device manufacturer for more information.

IKEv2 Security and RRAS

Be advised that the default security settings for IKEv2 on Windows Server RRAS are very poor. The minimum recommended security settings and guidelines for implementing them can be found here.

IKEv2 or TLS?

IKEv2 is recommend for deployments where the highest level of security and protection is required for remote connections. In these scenarios, the sacrifice of ubiquitous availability in favor of ultimate security might be desired.

SSTP or another TLS-based VPN protocol is recommended if reliable operation and connectivity are desired. SSTP and TLS VPNs can be configured to provide very good security by following the security and implementation guidelines found here.

IKEv2 with TLS Fallback

In theory, preferring IKEv2 and falling back to the Secure Socket Tunneling Protocol (SSTP) or another TLS-based VPN protocol when IKEv2 is unavailable would seem like a logical choice. This would ensure the highest level of protection, while still providing reliable connectivity. Unfortunately, the Windows VPN client doesn’t work this way in practice. Details here.

Additional Information

Windows 10 Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 and SSTP Fallback

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN LockDown Mode

Always On VPN LockDown ModeWhen an Always On VPN connection is provisioned to a Windows 10 client, there’s nothing to prevent a user from disconnecting or even deleting the connection. Some administrators have expressed concern about this, fearful that users may disable the VPN to improve performance or circumvent access controls when force tunneling is enabled. Also, administrators may wish to prevent users from accidentally or purposefully making changes to the configuration, or even deleting the connection entirely.

LockDown Mode

To address these concerns, Microsoft included a feature called LockDown mode for Always On VPN. Once enabled, the following conditions apply.

  • The LockDown VPN connection is always on.
  • The LockDown VPN connection cannot be disabled.
  • The user can’t make changes to or delete the LockDown connection.
  • No other VPN connections can exist on the client.
  • Force tunneling is enabled by default (split tunneling in LockDown mode is not supported).

Challenges with LockDown Mode

Always On VPN LockDown mode brings with it some unique challenges, however. Consider the following.

Limited Protocol Support

LockDown mode only supports IKEv2 and the native (built-in) VPN client. Third-party plug-in provider clients are not supported. IKEv2 is an excellent VPN protocol in terms of security, but operationally speaking it has some serious drawbacks.

Force Tunneling Only

LockDown mode uses force tunneling exclusively. All network traffic must go over the VPN connection. However, if the VPN connection is not available, the client will be unable to access any network resources at all, local or remote.

Captive Portal Issues

LockDown mode prevents clients from connecting to network resources from a network with a captive portal.

On-premises Connectivity

In LockDown mode all network traffic must flow over the VPN tunnel even if the client is on the internal network. This also means that if the VPN server is not reachable internally (unable to resolve public hostname, protocols/ports blocked by internal firewall, unable to route to VPN server, etc.) the client will not be able to access any internal or external network resources at all.

Deleting a LockDown VPN Connection

Deleting a LockDown VPN connection is also challenging. Administrators will find that trying to delete it using the UI or PowerShell often fails. To delete a LockDown Always On VPN connection, use psexec.exe to open an elevated PowerShell command window running in the system context using the following command.

.\psexec.exe -i -s C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe

In the new elevated PowerShell window run the following commands to delete the LockDown VPN connection.

$Namespace = “root\cimv2\mdm\dmmap”
$ClassName = “MDM_VPNv2_01”

$obj = Get-CimInstance -Namespace $Namespace -ClassName $ClassName
Remove-CimInstance -CimInstance $obj

Optionally, download and run Remove-LockDownVPN.ps1 here.

Summary

While Always On VPN LockDown mode might seem like a good idea initially, its implementation is heavy-handed and practically speaking ends up causing more problems than it solves. For administrators that plan to enable this feature, carefully consider the drawbacks and limitations outlined above and their impact on supportability and the user experience.

Additional Information

Windows Always On VPN Device Tunnel Config using Microsoft Intune

Windows 10 Always On VPN Security Configuration 

Windows 10 Always On VPN Hands-On Training

Always On VPN Training at TechMentor Redmond 2019

TechMentor Redmond 2019I’m pleased to announce that I’ll be delivering two technical training sessions at this year’s TechMentor Redmond event. This event takes place on the Microsoft campus in Redmond, WA August 5-9, 2019. I’ll be presenting two sessions on Thursday, August 8. They are:

TH16 – Wireshark Essentials: Your First Day with Wireshark

During this session you will learn essential techniques for optimizing packet analysis using Wireshark. Topics will include filter and display tips, workspace oganization, using shortcuts for common tools, and configuring Wireshark profiles. I’ll also touch upon some advanced techniques such as graphing and geography database integration.

TH20 – Always On VPN: The Good, the Bad, and the Ugly!

During this session you will gain a full understanding of Always On VPN including and how it compares with its predecessor, DirectAccess. I’ll share detailed information about this new technology, and how it best fits in to your organizations mobility strategy. Always On VPN has some important advantages over DirectAccess, and some challenging drawbacks. I’ll explain everything good, bad, and even the ugly.

TechMentor Redmond 2019

 

Don’t miss out on this fantastic event. Register now to take advantage of early bird savings, which end June 7. Hope to see you there!

Always On VPN Device Tunnel Configuration using Intune

Always On VPN Device Tunnel Configuration using IntuneA while back I described in detail how to configure a Windows 10 Always On VPN device tunnel connection using PowerShell. While using PowerShell is fine for local testing, it obviously doesn’t scale well. In theory you could deploy the PowerShell script and XML file using System Center Configuration Manager (SCCM), but using Microsoft Intune is the recommended and preferred deployment method. However, as of this writing Intune does not support device tunnel configuration natively. The administrator must create a ProfileXML manually and use Intune to deploy it.

Device Tunnel Prerequisites

I outlined the Always On VPN device tunnel prerequisites in my previous post here. To summarize, the client must be running Windows 10 Enterprise edition and be domain-joined. It must also have a certificate issued by the internal PKI with the Client Authentication EKU in the local computer certificate store.

ProfileXML

To begin, create a ProfileXML for the device tunnel that includes the required configuration settings and parameters for your deployment. You can find a sample Windows 10 Always On VPN device tunnel ProfileXML here.

Note: Be sure to define a custom IPsec policy in ProfileXML for the device tunnel. The default security settings for the IKEv2 protocol (required for the device tunnel) are quite poor. Details here.

Intune Deployment

Open the Intune management console and follow the steps below to deploy an Always On VPN device tunnel using Microsoft Intune.

Create Profile

1. Navigate to the Intune portal.
2. Click Device configuration.
3. Click Profiles.
4. Click Create profile.

Define Profile Settings

1. Enter a name for the VPN connection in the Name field.
2. Enter a description for the VPN connection in the Description field (optional).
3. Select Windows 10 and later from the Platform drop-down list.
4. Select Custom from the Profile type drop-down list.

Always On VPN Device Tunnel Configuration using Intune

Define Custom OMA-URI Settings

1. On the Custom OMA-URI Settings blade click Add.
2. Enter a name for the device tunnel in the Name field.
3. Enter a description for the VPN connection in the Description field (optional).
4. Enter the URI for the device tunnel in the OMA-URI field using the following syntax. If the profile name includes spaces they must be escaped, as shown here.

./Device/Vendor/MSFT/VPNv2/Example%20Profile%Name/ProfileXML

5. Select String (XML file) from the Data Type drop-down list.
6. Click the folder next to the Select a file field and chose the ProfileXML file created previously.
7. Click Ok twice and then click Create.

Always On VPN Device Tunnel Configuration using Intune

Assign Profile

Follow the steps below to assign the Always On VPN device tunnel profile to the appropriate device group.

1. Click Assignments.
2. Click Select groups to include.
3. Select the group that includes the Windows 10 client devices.
4. Click Select.
5. Click Save.

Always On VPN Device Tunnel Configuration using Intune

Demonstration Video

A video demonstration of the steps outlined above can be viewed here.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN IKEv2 Security Configuration

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Missing in the UI

Always On VPN SSTP Connects then Disconnects

Always On VPN SSTP Connects then DisconnectsWhen Always On VPN clients are configured to use the Secure Socket Tunneling Protocol (SSTP) with Windows Server Routing and Remote Access Service (RRAS), administrators may encounter a scenario in which a client can establish a VPN connection using SSTP successfully, but is then disconnected immediately. The system event log contains an entry with Event ID 6 from the RasSstp source that includes the following error message.

“The SSTP-based VPN connection to the remote access server was terminated because of a security check failure. Security settings on the remote access server do not match settings on this computer. Contact the system administrator of the remote access server and relay the following information.”

Always On VPN Connect and Disconnect with SSTP

Common Causes

The two most common causes of this issue are when SSTP is configured for SSL offload, and when a VPN client is on a network where SSL inspection is taking place.

SSTP Offload

The most common cause of this issue is when SSL offload is configured for SSTP on an external load balancer or application delivery controller (ADC). To prevent interception from a Man-in-the-Middle attack, the VPN client sends the certificate hash of the SSL certificate used when the VPN connection was established. If this information does not match what is configured on the RRAS server, the connection is assumed to be compromised and the connection is immediately dropped.

SSL Inspection

Another scenario where this issue may occur is when a VPN client is behind a network device configured to perform SSL deep-packet inspection (DPI). SSTP VPN clients will be unable to connect to the VPN server in this scenario.

Resolution

When offloading SSL to another device, the RRAS server must be configured to know which SSL certificate is being presented to remote clients. This information is stored in the following registry key.

HKLM:\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters\SHA256CertificateHash

However, this registry entry requires a binary value, which makes it a challenge to configure manually. To resolve this problem, it is recommended that the same SSL certificate installed on the load balancer/ADC also be installed on the VPN server (even though SSL will be offloaded). To do this, first import the SSL certificate and private key in to the Local Computer certificate store, then open the RRAS management console and perform the following steps.

  1. Right-click the VPN server and choose Properties.
  2. Select the Security tab.
  3. Uncheck Use HTTP in the SSL Certificate Binding section.
  4. Select the appropriate SSL certificate from the Certificate drop-down list (click View to verify).
  5. Click Apply.

This will add the correct SSL certificate information to the registry. Next, re-enable HTTP for SSL offload by performing the following steps.

  1. Check Use HTTP in the SSL Certificate Binding section.
  2. Click Apply.

PowerShell Configuration

If the SSL certificate cannot be installed on the VPN server, or to automate this configuration across multiple servers remotely, download and run the Enable-SstpOffload PowerShell script from my GitHub repository here and run the following command.

Enable-SSTPOffload -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

For example…

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Additional Information

Windows 10 Always On VPN Load Balancing and SSL Offload

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

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 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 ProfileXML Editing and Formatting with Visual Studio Code

Always On VPN ProfileXML Editing and Formatting with Visual Studio CodeWindows 10 Always On VPN is designed to be implemented and managed using a Mobile Device Management (MDM) platform such as Microsoft Intune. With Intune specifically, there is an option to configure an Always On VPN profile in the UI. However, it provides only limited support and does not include all settings and options required for many deployments. Crucially, IKEv2 advanced security settings cannot be configured using the Intune portal. Also, there is currently no option for configuring a device tunnel with Intune. In these scenarios the administrator must manually create a ProfileXML file and provision it using Intune, System Center Configuration Manager (SCCM), or PowerShell.

ProfileXML

ProfileXML includes all settings that define the Always On VPN connection. The options and settings available are documented in the VPNv2 Configuration Service Provider (CSP) reference on Microsoft’s web site. ProfileXML is formatted using elements and settings within those elements. The formatting and syntax are critical to ensuring proper operation. Any error in syntax or formatting can result in an error, such as those described here.

XML Readability

Formatting is also important for readability, which is often helpful when reviewing configuration settings or troubleshooting syntax errors. For example, an element may be defined correctly but may be nested wrong. Often XML files are created with all text being left-justified, or with everything on a single line, making the content difficult to read. Using a file editor that recognizes XML files can be beneficial.

Visual Studio Code

To create, edit, and review ProfileXML it is recommended that a proper editing tool be used. I recommend using Microsoft’s Visual Studio Code. It is free, and it is especially helpful when editing XML files. Visual Studio Code can be downloaded here.

XML Tools VS Code Plug-In

To further enhance Visual Studio Code’s XML editing and formatting capabilities I recommend installing the XML Tools plug-in. This tool extends the native features of VS code for handling XML files. One important thing it adds is a formatting feature that will make your ProfileXML much easier to manage. The XML Tools plug-in for VS Code can be downloaded here.

XML Formatting

Once the XML Tools plug-in for VS code has been installed, formatting XML for readability is straightforward. Simply right-click anywhere in the document and choose Format Document.

Always On VPN ProfileXML Editing and Formatting with Visual Studio CodeOnce complete, the XML document will be formatted with proper indenting and nesting of elements, as shown here.

Always On VPN ProfileXML Editing and Formatting with Visual Studio CodeSummary

Formatting and syntax must be strictly adhered to when creating a ProfileXML file for Windows 10 Always On VPN. Using Visual Studio Code with the XML Tools plug-in allow the administrator to create and edit XML with proper formatting, which greatly improves readability and allows for streamlined configuration review and troubleshooting.

Acknowledgements

Special thanks to Colin, an avid reader of the articles on this web site for this tip. Thanks, Colin! 🙂

Additional Information

Always On VPN and DirectAccess Scripts and Sample Files on GitHub

Always On VPN IKEv2 Security Configuration

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

Always On VPN Hands-On Training Classes in 2019

%d bloggers like this: