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.
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.
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.
Interestingly, the default Windows firewall rule allowing inbound UDP port 1812 is enabled and set to allow for all profiles.
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.
DirectAccess 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.
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:
Once complete, an ISATAP tunnel adapter network interface with a unicast IPv6 address will appear in the output of ipconfig.exe, as shown here.
Running the Get-NetRoute -AddressFamily IPv6 PowerShell command will show routes to the client IPv6 prefixes assigned to each DirectAccess server.
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.
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.
Organizations are rapidly deploying Windows server infrastructure with public cloud providers such as Amazon Web Services (AWS) and Microsoft Azure. With traditional on-premises infrastructure now hosted in the cloud, DirectAccess is also being deployed there more commonly.
Supportability
Interestingly, Microsoft has expressly stated that DirectAccess is not formally supported on their own public cloud platform, Azure. However, there is no formal statement of non-support for DirectAccess hosted on other non-Microsoft public cloud platforms. With supportability for DirectAccess on AWS unclear, many companies are taking the approach that if it isn’t unsupported, then it must be supported. I’d suggest proceeding with caution, as Microsoft could issue formal guidance to the contrary in the future.
DirectAccess on AWS
Deploying DirectAccess on AWS is similar to deploying on premises, with a few notable exceptions, outlined below.
IP Addressing
It is recommended that an IP address be exclusively assigned to the DirectAccess server in AWS, as shown here.
Prerequisites Check
When first configuring DirectAccess, the administrator will encounter the following warning message.
“The server does not comply with some DirectAccess prerequisites. Resolve all issues before proceed with DirectAccess deployment.”
The warning message itself states that “One or more network adapters should be configured with a static IP address. Obtain a static address and assign it to the adapter.”
IP addressing for virtual machines are managed entirely by AWS. This means the DirectAccess server will have a DHCP-assigned address, even when an IP address is specified in AWS. Assigning static IP addresses in the guest virtual machine itself is also not supported. However, this warning message can safely be ignored.
No Support for Load Balancing
It is not possible to create load-balanced clusters of DirectAccess servers for redundancy or scalability on AWS. This is because enabling load balancing for DirectAccess requires the IP address of the DirectAccess server be changed in the operating system, which is not supported on AWS. To eliminate single points of failure in the DirectAccess architecture or to add additional capacity, multisite must be enabled. Each additional DirectAccess server must be provisioned as an individual entry point.
Network Topology
DirectAccess servers on AWS can be provisioned with one or two network interfaces. Using two network interfaces is recommended, with the external network interface of the DirectAccess server residing in a dedicated perimeter/DMZ network. The external network interface must use either the Public or Private Windows firewall profile. DirectAccess will notwork if the external interface uses the Domain profile. For the Public and Private profile to be enabled, domain controllers must not be reachable from the perimeter/DMZ network. Ensure the perimeter/DMZ network cannot access the internal network by restricting network access in EC2 using a Security Group, or on the VPC using a Network Access Control List (ACL) or custom route table settings.
External Connectivity
A public IPv4 address must be associated with the DirectAccess server in AWS. There are several ways to accomplish this. The simplest way is to assign a public IPv4 address to the virtual machine (VM). However, a public IP address can only be assigned to the VM when it is deployed initially and cannot be added later. Alternatively, an Elastic IP can be provisioned and assigned to the DirectAccess server at any time.
An ACL must also be configured for the public IP that restricts access from the Internet to only inbound TCP port 443. To provide additional protection, consider deploying an Application Delivery Controller (ADC) appliance like the Citrix NetScaler or F5 BIG-IP to enforce client certificate authentication for DirectAccess clients.
Network Location Server (NLS)
If an organization is hosting all of its Windows infrastructure in AWS and all clients will be remote, Network Location Server (NLS) availability becomes much less critical than with traditional on-premises deployments. For cloud-only deployments, hosting the NLS on the DirectAccess server is a viableoption. It eliminates the need for dedicated NLS, reducing costs and administrative overhead. If multisite is configured, ensure that the NLS is not using a self-signed certificate, as this is unsupported.
However, for hybrid cloud deployments where on-premises DirectAccess clients share the same internal network with cloud-hosted DirectAccess servers, it is recommended that the NLS be deployed on dedicated, highly available servers following the guidance outlined here and here.
Client Provisioning
All supported DirectAccess clients will work with DirectAccess on AWS. If the domain infrastructure is hosted exclusively in AWS, provisioning clients can be performed using Offline Domain Join (ODJ). Provisioning DirectAccess clients using ODJ is onlysupported in Windows 8.x/10. Windows 7 clients cannot be provisioned using ODJ and must be joined to the domain using another form of remote network connectivity such as VPN.
DirectAccess 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.
