Always On VPN and Windows Server 2019 NPS Bug

Note: This post updated March 19,2019 to reflect new workaround configuration guidance.

When deploying a Windows Server 2019 Network Policy Server (NPS) to support a Windows 10 Always On VPN implementation, administrators may encounter the following error when attempting to establish a VPN connection on a remote Windows 10 client.

Can’t connect to [connection name].

The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.

Always On VPN and Windows Server 2019 Network Policy Server Bug
In addition, an event ID 20227 from the RasClient will be recorded in the application event log with the following error message.

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

Always On VPN and Windows Server 2019 Network Policy Server Bug

Common Causes

Always On VPN error code 812 indicates an authentication policy mismatch between the client and the server. This often occurs when, for example, the server is configured to use Protected Extensible Authentication Protocol (PEAP), but the client is configured to use Microsoft CHAP Version 2 (MS-CHAP v2).

Troubleshooting

Carefully review the authentication policy on both the client and server to ensure they match. Next, enable firewall logging on the NPS server to log both allowed and dropped packets. Attempt another VPN connection and observe the firewall logs. In this example the firewall is dropping packets inbound on UDP port 1812.

Always On VPN and Windows Server 2019 Network Policy Server Bug

Interestingly, the default Windows firewall rule allowing inbound UDP port 1812 is enabled and set to allow for all profiles.

Always On VPN and Windows Server 2019 Network Policy Server Bug

Windows Server 2019 Bug

It appears that Microsoft’s recently released Windows Server 2019 has a bug that prevents NPS from working correctly out of the box. Specifically, it looks like the default Windows firewall rules to allow inbound UDP port 1812 (RADIUS authentication) and inbound UDP port 1813 (RADIUS accounting) do not work.

Resolution

To resolve this issue, open an elevated command window and enter the following command.

sc.exe sidtype IAS unrestricted

Once complete, restart the server and the default Windows Firewall rules for NPS traffic will work correctly.

Additional Information

Windows 10 Always On VPN NPS Load Balancing Strategies

DirectAccess IP-HTTPS Performance Issues

DirectAccess IP-HTTPS Performance IssuesPerformance issues with DirectAccess are not uncommon. In fact, there are numerous threads on Microsoft and third-party forums where administrators frequently complain about slow download speeds, especially when using the IP-HTTPS IPv6 transition technology. Based on my experience the problem does not appear to be widespread but occurs with enough regularity that it is worthy of further investigation.

DirectAccess Design

The inherent design of DirectAccess is a major limiting factor for performance. DirectAccess uses a complex and heavy communication channel, with multiple layers of encapsulation, encryption, and translation. Fundamentally it is IPsec encrypted IPv6 traffic, encapsulated in HTTP, and then encrypted with Transport Layer Security (TLS) and routed over IPv4. It is then decrypted, decapsulated, decrypted again, then converted back to IPv4. The high protocol overhead incurred with multiple layers of encapsulation, encryption, and translation result in increased packet fragmentation, which further reduces performance.

DirectAccess Performance

Even under the best circumstances, DirectAccess performance is limited by many other factors, most notably the quality of the network connection between the client and the server. DirectAccess performs reasonably well over high bandwidth, low latency connections. However, network performance drops precipitously as latency increases and packet loss is encountered. This is to be expected given the design of the solution.

Intermediary Devices

It is not uncommon to find intermediary devices like firewalls, intrusion detection systems, malware scanners, and other security inspection devices limit the performance of DirectAccess clients. In addition, many security appliances have bandwidth caps enforced in software for licensing restrictions. Further, incorrect configuration of inline edge devices can contribute to increased fragmentation, which leads to poor performance as well.

Slow Downloads over IP-HTTPS

Many people report that download speeds seem to be artificially capped at 355Kbps. While this seems to be a display bug in the UI, there is plenty of evidence to indicate that, in some scenarios, DirectAccess is incapable of high throughput even over high-quality connections. Some who have deployed DirectAccess and VPN on the same server have reported that download speeds are only limited when using DirectAccess over IP-HTTPS and not with VPN using Secure Socket Tunneling Protocol (SSTP), which also uses TLS. This has led many to speculate that the issue is either a bug or a design flaw in the IP-HTTPS tunnel interface itself.

TCP Window Scaling Issues

In some of the network traces I’ve analyzed I’ve seen evidence that seems to support this theory. For example, a network trace taken when downloading a file over DirectAccess with IP-HTTPS showed the TCP window never scaled beyond 64K, which would seriously impede performance. Interestingly this doesn’t seem to happy when the client uploads files over IP-HTTPS. Clearly something unusual is happening.

Microsoft KB Article

Microsoft recently released a vaguely-worded KB article that appears to lend credence to some of these findings. The article seems to acknowledge the fact there are known issues with DirectAccess performance, but it lacks any specific details as to what the root cause is. Instead, it simply advises migrating to Windows 10 Always On VPN.

Summary

DirectAccess IP-HTTPS performance issues don’t appear to affect everyone, and the problem only seems to apply to file downloads and not to other types of traffic. However, there is mounting evidence of a systemic issue with DirectAccess performance especially over IP-HTTPS. Customers are advised to closely evaluate their uses cases for DirectAccess and if remote clients are frequently required to download large files over a DirectAccess connection, an alternative method of file transfer might be required. Optionally customers can consider evaluating alternative remote access solutions that offer better performance such as Windows 10 Always On VPN or third-party solutions such as NetMotion Mobility.

Additional Resources

Always On VPN and the Future of DirectAccess

What’s the Difference Between DirectAccess and Always On VPN?

NetMotion Mobility as an Alternative to Microsoft DirectAccess

DirectAccess Manage Out with ISATAP and NLB Clustering

DirectAccess Manage Out with ISATAP and NLB ClusteringDirectAccess connections are bidirectional, allowing administrators to remotely connect to clients and manage them when they are out of the office. DirectAccess clients use IPv6 exclusively, so any communication initiated from the internal network to remote DirectAccess clients must also use IPv6. If IPv6 is not deployed natively on the internal network, the Intrasite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 transition technology can be used to enable manage out.

ISATAP Supportability

According to Microsoft’s support guidelines for DirectAccess, using ISATAP for manage out is only supported for single server deployments. ISATAP is not supported when deployed in a multisite or load-balanced environment.

Not supported” is not the same as “doesn’t work” though. For example, ISATAP can easily be deployed in single site DirectAccess deployments where load balancing is provided using Network Load Balancing (NLB).

ISATAP Configuration

To do this, you must first create DNS A resource records for the internal IPv4 address for each DirectAccess server as well as the internal virtual IP address (VIP) assigned to the cluster.

DirectAccess Manage Out with ISATAP and NLB Clustering

Note: Do NOT use the name ISATAP. This name is included in the DNS query block list on most DNS servers and will not resolve unless it is removed. Removing it is not recommended either, as it will result in ALL IPv6-enabled hosts on the network configuring an ISATAP tunnel adapter.

Once the DNS records have been added, you can configure a single computer for manage out by opening an elevated PowerShell command window and running the following command:

Set-NetIsatapConfiguration -State Enabled -Router [ISATAP FQDN] -PassThru

DirectAccess Manage Out with ISATAP and NLB Clustering

Once complete, an ISATAP tunnel adapter network interface with a unicast IPv6 address will appear in the output of ipconfig.exe, as shown here.

DirectAccess Manage Out with ISATAP and NLB Clustering

Running the Get-NetRoute -AddressFamily IPv6 PowerShell command will show routes to the client IPv6 prefixes assigned to each DirectAccess server.

DirectAccess Manage Out with ISATAP and NLB Clustering

Finally, verify network connectivity from the manage out host to the remote DirectAccess client.

Note: There is a known issue with some versions of Windows 10 and Windows Server 2016 that may prevent manage out using ISATAP from working correctly. There’s a simple workaround, however. More details can be found here.

Group Policy Deployment

If you have more than a few systems on which to enable ISATAP manage out, using Active Directory Group Policy Objects (GPOs) to distribute these settings is a much better idea. You can find guidance for creating GPOs for ISATAP manage out here.

DirectAccess Client Firewall Configuration

Simply enabling ISATAP on a server or workstation isn’t all that’s required to perform remote management on DirectAccess clients. The Windows firewall running on the DirectAccess client computer must also be configured to securely allow remote administration traffic from the internal network. Guidance for configuring the Windows firewall on DirectAccess clients for ISATAP manage out can be found here.

ISATAP Manage Out for Multisite and ELB

The configuration guidance in this post will not work if DirectAccess multisite is enabled or external load balancers (ELB) are used. However, ISATAP can still be used. For more information about enabling ISATAP manage out with external load balancers and/or multisite deployments, fill out the form below and I’ll provide you with more details.

Summary

Once ISATAP is enabled for manage out, administrators on the internal network can remotely manage DirectAccess clients wherever they happen to be. Native Windows remote administration tools such as Remote Desktop, Windows Remote Assistance, and the Computer Management MMC can be used to manage remote DirectAccess clients. In addition, enterprise administration tools such as PowerShell remoting and System Center Configuration Manger (SCCM) Remote Control can also be used. Further, third-party remote administration tools such as VNC, TeamViewer, LogMeIn, GoToMyPC, Bomgar, and many others will also work with DirectAccess ISATAP manage out.

Additional Information

ISATAP Recommendations for DirectAccess Deployments

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016 

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

DirectAccess Manage Out and System Center Configuration Manager (SCCM)

Contact Me

Interested in learning more about ISATAP manage out for multisite and external load balancer deployments? Fill out the form below and I’ll get in touch with you.

← Back

Thank you for your response. ✨