Always On VPN SSTP Load Balancing with F5 BIG-IP

Always On VPN SSTP Load Balancing with F5 BIG-IP The Windows Server Routing and Remote Access Service (RRAS) includes support for the Secure Sockets Tunneling Protocol (SSTP), which is a Microsoft proprietary VPN protocol that uses SSL/TLS for security and privacy of VPN connections. The advantage of using SSTP for Always On VPN is that it is firewall friendly and ensures consistent remote connectivity even behind highly restrictive firewalls.

Load Balancing SSTP

In a recent post, I described some of the use cases and benefits of SSTP load balancing as well as the offloading of TLS for SSTP VPN connections. Using a load balancer for SSTP VPN connections increases scalability, and offloading TLS for SSTP reduces resource utilization and improves performance for VPN connections. There are positive security benefits too.

Configuration

Enabling load balancing for SSTP on the F5 BIG-IP platform is fundamentally similar to load balancing HTTPS web servers. However, there are a few subtle but important differences.

Default Monitor

The default HTTP and HTTPS monitors on the F5 will not accurately reflect the health of the SSTP service running on the RRAS server. In addition, using a simple TCP port monitor could yield unexpected results. To ensure accurate service status monitoring, a new custom monitor must be created to validate the health of the SSTP service.

Custom SSTP Monitor

Open the F5 BIG-IP management console and follow the steps below to create and assign a new custom monitor for SSTP.

Create Monitor

1. In the navigation tree highlight Local Traffic.
2. Click Monitors.
3. Click Create.

Always On VPN SSTP Load Balancing with F5 BIG-IP

4. Enter a descriptive name in the Name field and from the Type drop-down list choose HTTP if TLS offload is enabled, or HTTPS if it is not.
5. In the Send String field enter HEAD /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ HTTP/1.1\r\nHost:r\nConnection: Close\r\n\r\n.
6. In the Receive String field enter HTTP/1.1 401.
7. Click Finished.

Always On VPN SSTP Load Balancing with F5 BIG-IP

Assign Monitor

1. Below Local Traffic click Pools.
2. Click on the SSTP VPN server pool.
3. In the Health Monitors section select the SSTP VPN health monitor from the Available list and make it Active.
4. Click Update.

Always On VPN SSTP Load Balancing with F5 BIG-IP

CLI Configuration

If you prefer to configure the SSTP VPN monitor using the F5’s Command Line Interface (CLI), you can download the monitor configuration from my GitHub here.

TLS Offload

It is generally recommended that TLS offload not be enabled for SSTP VPN. However, if TLS offload is desired, it is configured in much the same way as a common HTTPS web server. Specific guidance for enabling TLS offload on the F5 BIG-IP can be found here. Details for configuring RRAS and SSTP to support TLS offload can be found here.

Certificates

When enabling TLS offload for SSTP VPN connections it is recommended that the public SSL certificate be installed on the RRAS server, even though TLS processing will be handled on the F5 and HTTP will be used between the F5 and the RRAS server. If installing the public SSL certificate on the RRAS server is not an option, additional configuration will be required. Specifically, TLS offload for SSTP must be configured using the Enable-SSTPOffload PowerShell script, which can be found here.

Once the script has been downloaded, open an elevated PowerShell command window and enter the following command.

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

Example:

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Re-Encryption

When offloading TLS for SSTP VPN connections, all traffic between the F5 and the RRAS server will be sent in the clear using HTTP. In some instances, TLS offload is required only for traffic inspection, not performance gain. In this scenario the F5 will be configured to terminate and then re-encrypt connections to the RRAS server. When terminating TLS on the F5 and re-encrypting connections to the RRAS server is required, the same certificate must be used on both the F5 and the RRAS server. Using different certificates on the RRAS server and the load balancer is not supported.

Additional Information

Windows 10 Always On VPN SSTP Load Balancing and SSL Offload

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN ECDSA SSL Certificate Request for SSTP

Windows 10 Always On VPN SSTP Connects then Disconnects

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers

 

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 IKEv2 Load Balancing with F5 BIG-IP

Always On VPN IKEv2 Load Balancing with F5 BIG-IPThe Internet Key Exchange version 2 (IKEv2) is the protocol of choice for Always On VPN deployments where the highest level of security is required. Implementing Always On VPN at scale often requires multiple VPN servers to provide sufficient capacity and to provide redundancy. Commonly an Application Delivery Controller (ADC) or load balancer is configured in front of the VPN servers to provide scalability and high availability for Always On VPN.

Load Balancing IKEv2

In a recent post I described some of the unique challenges load balancing IKEv2 poses, and I demonstrated how to configure the Kemp LoadMaster load balancer to properly load balance IKEv2 VPN connections. In this post I’ll outline how to configure IKEv2 VPN load balancing on the F5 BIG-IP load balancer.

Note: This article assumes the administrator is familiar with basic F5 BIG-IP load balancer configuration, such as creating nodes, pools, virtual servers, etc.

Initial Configuration

Follow the steps below to create a virtual server on the F5 BIG-IP to load balance IKEv2 VPN connections.

Pool Configuration

To begin, create two pools on the load balancer. The first pool will be configured to use UDP port 500, and the second pool will be configured to use UDP port 4500. Each pool is configured with the VPN servers defined as the individual nodes.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Virtual Server Configuration

Next create two virtual servers, the first configured to use UDP port 500 and the second to use UDP port 4500.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Persistence Profile

To ensure that both IKEv2 UDP 500 and 4500 packets are delivered to the same node, follow the steps below to create and assign a Persistence Profile.

1. Expand Local Traffic > Profiles and click Persistence.
2. Click Create.
3. Enter a descriptive name for the profile in the Name field.
4. Select Source Address Affinity from the Persistence Type drop-down list.
5. Click the Custom check box.
6. Select the option to Match Across Services.
7. Click Finished.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Assign the new persistence profile to both UDP 500 and 4500 virtual servers. Navigate to the Resources tab on each virtual server and select the new persistence profile from the Default Persistence Profile drop-down list. Be sure to do this for both virtual servers.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Additional Resources

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster Load Balancer 

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN and IKEv2 Fragmentation

Windows 10 Always On VPN Certificate Requirements for IKEv2

Video: Windows 10 Always On VPN Load Balancing with the Kemp LoadMaster Load Balancer

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 SSTP Load Balancing with F5 BIG-IP

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

 

Always On VPN SSTP Load Balancing and SSL Offload

SSL Certificate Considerations for DirectAccess IP-HTTPSThe Windows Server Routing and Remote Access Service (RRAS) is a popular choice for a VPN server to support Windows 10 Always On VPN deployments. One significant advantage RRAS provides is support for the Secure Socket Tunneling Protocol (SSTP). SSTP is a Microsoft proprietary VPN protocol that uses Transport Layer Security (TLS) to ensure privacy between the VPN client and server. The advantage to using a TLS-based transport is that it leverages the standard HTTPS TCP port 443, making it firewall friendly and ensuring ubiquitous remote access even behind highly restrictive firewalls.

Load Balancing SSTP

Load balancing SSTP can be accomplished in much the same way as a load balancing a common web server using HTTPS. The external load balancer is configured with a virtual IP address (VIP) and each VPN server is configured behind it. Session persistence should be configured to use SSL with source IP address persistence as a fallback.

SSL Offload for SSTP

In most cases, simply forwarding encrypted SSTP connections to the VPN server will be sufficient. However, offloading SSL/TLS processing to an Application Delivery Controller (ADC) or load balancer can be beneficial for the following reasons.

Resource Utilization

Enabling TLS offload for SSTP VPN connections can reduce CPU and memory utilization on the VPN server. However, this will likely only be necessary for very busy servers supporting many concurrent connections.

Security

In some cases, the administrator may not be able to install the public SSL certificate on the VPN server. For example, a security policy may exist that restricts SSL certificate installation to dedicated security devices using a Hardware Security Module (HSM). In some cases, it may be desirable to restrict access to high value certificates such as wildcard certificates.

Certificate Management

Often SSL certificates are implemented on load balancers to reduce certificate sprawl and to ease the management and administration burden in the enterprise. By having all enterprise certificates installed only on dedicated security devices, administrators can more effectively monitor and manage SSL certificate lifecycles.

SSTP Configuration for TLS Offload

Configuration changes must be made on the load balancer and the RRAS server to support TLS offload for SSTP.

Load Balancer

Install the public SSL certificate on the load balancer and configure it for TLS termination. Configure the load balancer to then use HTTP for backend server connections. Consult the load balancer vendor’s documentation for configuration guidance.

Load Balancing Always On VPN SSTP Load Balancing with F5 BIG-IP

RRAS Server

If the public SSL certificate is installed on the VPN server, enabling TLS offload for SSTP is simple and straightforward. Follow the steps below to enable TLS offload for SSTP VPN connections.

  1. Open the RRAS management console (rrasmgmt.msc).
  2. Right-click the VPN server and choose Properties.
  3. Select the Security tab.
  4. Check Use HTTP in the SSL Certificate Binding section.
  5. Click Ok and then Yes to restart the Remote Access service.

Always On VPN SSTP Load Balancing and SSL Offload

If the public SSL certificate is not or cannot be installed on the RRAS server, additional configuration will be required. Specifically, SSL offload for SSTP must be configured using the Enable-SSTPOffload PowerShell script, which can be downloaded here.

Once the script has been downloaded and imported, open an elevated PowerShell command window and enter the following command.

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

For example…

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Re-Encryption

When offloading TLS for SSTP VPN connections, all traffic between the load balancer and the VPN server will be sent in the clear using HTTP. In some scenarios, TLS offload is required only for traffic inspection, not performance gain. When terminating TLS on the load balancer and re-encrypting connections to the VPN server is required, it is only supported if the same certificate is used on both the load balancer and the VPN server.

Additional Information

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

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

Windows 10 Always On VPN IKEv2 and SSTP Fallback

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

 

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

DirectAccess Network Connectivity Assistant (NCA) Configuration GuidanceThe DirectAccess Network Connectivity Assistant (NCA), first introduced in Windows 8, provides DirectAccess connectivity status information as well as diagnostic support on the client. The NCA validates that DirectAccess is working end-to-end by attempting to reach internal resources defined by the administrator during the configuration of DirectAccess. NCA configuration and operation is a source of much confusion. This article serves to provide best practice configuration guidance for the NCA to ensure optimum and reliable operation.

NCA Operation

When a DirectAccess client is outside the corporate network, it will attempt to establish a DirectAccess connection any time it has an active Internet connection. After a DirectAccess connection is made, the NCA will attempt to validate DirectAccess connectivity by verifying availability of corporate resources as defined in the DirectAccess configuration (Remote Access Management console, Step 1, Edit, Network Connectivity Assistant).

If the NCA can reach the defined internal corporate resource(s), the DirectAccess connection is verified end-to-end and it will report the connection status as “Connected”. If it fails to connect to any internal corporate resource, it displays “Connecting”.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Figure 1. NCA successfully validated internal corporate resource connectivity.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Figure 2. NCA failed to connect to one or more corporate resources.

NCA Configuration

When first installing DirectAccess, the Remote Access Setup wizard will collect information to be used by the NCA, including corporate resources, helpdesk email address, and DirectAccess connection name. It will also provide the option to allow DirectAccess clients to use local name resolution.

Note: The NCA settings configured in the Remote Access Management console pertain only to Windows 8.x and Windows 10 clients. They are not used by Windows 7 clients at all.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

Intuitively it would appear that information needs to be entered in the Resource and Type fields. However, it is recommended to leave this blank when first configuring DirectAccess. This is because the Remote Access Setup Wizard will automatically populate this field later. Specifying a resource during initial configuration will result in two entries being included, as shown here.

DirectAccess Network Connectivity Assistant (NCA) Configuration Guidance

As you can see, the Remote Access Setup wizard automatically added the resource directaccess-WebProbeHost.<internal domain.>. A corresponding DNS record is created that resolves this hostname to the internal IPv4 address of the DirectAccess server. In this configuration, the DirectAccess server itself serves as the corporate resource used by the NCA.

Multiple Corporate Resources

Having more than one resource to validate connectivity to the internal network is problematic though. If there are multiple entries specified, they must ALL pass a validation check from the client to report the connection status as “Connected”. Some administrators configure multiple entries with the mistaken belief that it will provide redundancy for the NCA, but it actually has the opposite effect. Having more than one entry only increases the chance of a false positive.

NCA Configuration Best Practices

It is recommended that only a single corporate resource URL be defined for the NCA. The default directaccess-WebProbeHost running on the DirectAccess server can be used, or, alternatively, another internal web server can be specified if desired. Any web server will work, including Microsoft Internet Information Services (IIS), Apache, NGINX, and most Application Delivery Controllers (ADCs) or load balancers. HTTPS is not required for the web probe host, only HTTP. If using an internal web server, ensure that it is highly available.

Do NOT use the Network Location Server (NLS) as a corporate resource! The NLS is exempted from the Name Resolution Policy Table (NRPT) on the client and is not reachable over DirectAccess. This will result in the NCA failing and reporting a “Connecting” status perpetually. In addition, avoid the use of PING for validating internal corporate resources. Ping uses ICMP which is inherently unreliable and commonly blocked by host and intermediary firewalls, making it an unreliable indicator of corporate network connectivity over DirectAccess.

Summary

The NCA is a crucial and often misunderstood component in the DirectAccess architecture. Follow the guidance outlined here to ensure that the NCA works reliably and effectively in your environment.

Additional Resources

DirectAccess Clients in Connecting State when using External Load Balancer
Planning and Implementing DirectAccess on Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 book

KEMP LoadMaster Load Balancer Certificate Format Invalid

When implementing a KEMP LoadMaster load balancer, one of the first configuration tasks performed is importing root and intermediate Certification Authority (CA) certificates. When doing this, it is not uncommon to encounter the following error message.

Certificate Format Invalid.

KEMP LoadMaster Load Balancer Certificate Invalid

To resolve this issue, .CER files must first be converted to .PEM format before being imported in to the LoadMaster. Using OpenSSL, .CER files can quickly be converted to .PEM with the following command.

openssl x509 -inform der -in example.cer -out example.pem

Optionally, .CER files can be converted to .PEM online here.

If the root and/or intermediate certificates are from an internal PKI, export the certificates using the Base-64 encoded x.509 (.CER) option. Certificates exported using this format can be imported directly in to the LoadMaster without first having to be converted to .PEM.

KEMP LoadMaster Load Balancer Certificate Format Invalid

Pro tip: When entering the Certificate Name, it is not necessary to enter a file extension. The name will be appended with .PEM automatically upon import.

KEMP LoadMaster Load Balancer Certificate Format Invalid

KEMP LoadMaster Load Balancer Certificate Format Invalid

Additional Resources

DirectAccess Deployment Guide for KEMP LoadMaster Load Balancers

Maximize Your Investment in Windows 10 with KEMP LoadMaster Load Balancers

DirectAccess and the FREE KEMP LoadMaster Load Balancer

Configure KEMP LoadMaster Load Balancer for DirectAccess Network Location Server (NLS)

Planning and Implementing DirectAccess Video Training Course on Pluralsight

Implementing DirectAccess with Windows Server 2016 Book

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

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.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

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.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

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 not work 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 viable option. 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.

Deployment Considerations for DirectAccess on Amazon Web Services (AWS)

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 only supported 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.

Additional Resources

DirectAccess No Longer Supported in Microsoft Azure

Microsoft Server Software Support for Azure Virtual Machines

DirectAccess Network Location Server (NLS) Guidance

DirectAccess Network Location Server (NLS) Deployment Considerations for Large Enterprises

Provisioning DirectAccess Clients using Offline Domain Join (ODJ)

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

DirectAccess SSL Offload and IP-HTTPS Preauthentication with F5 BIG-IP

Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course

Implementing DirectAccess with Windows Server 2016 Book

DirectAccess Troubleshooting with Nmap

DirectAccess IP-HTTPS Discovery Script for NmapDirectAccess troubleshooting can be made much easier using open source tools such as Nmap. Nmap can be used to perform many essential network connectivity and configuration checks, including validating network paths, confirming DirectAccess server response, and viewing SSL configuration. Nmap can also be used to ensure that the attack surface of the DirectAccess server is properly minimized. Some tests can be performed using only native Nmap functionality, while others require the use of specialized Nmap scripts that are included with the tool.

Installation

Nmap can be installed on a wide variety of operating systems, including Windows. If you plan to install Nmap on Windows, be sure to also install WinPcap and the Microsoft Visual C++ 2013 Redistributable. The Visual C++ component is included with the Nmap download. WinPcap must be downloaded separately here.

Testing External Connectivity

Validating external connectivity is often one of the first DirectAccess troubleshooting steps I take. Confirm that the DirectAccess public hostname resolves to the correct IP address, then run the following Nmap command to validate network connectivity from the Internet to the DirectAccess server.

nmap -n -Pn -p443 <da_public_hostname>

DirectAccess Troubleshooting with Nmap

If the hostname resolves correctly and the network path is complete, the server should respond and Nmap will show the port as open. However, this doesn’t necessarily mean that the DirectAccess server is the device that replied! Due to misconfiguration, it is possible that another server or network device listening on TCP port 443 responded, so this is not a conclusive test.

DirectAccess Server Response

To confirm the DirectAccess server is responding to HTTPS requests and not some other server or device, run the following Nmap command with the ip-https-discover script.

nmap -n -Pn -p443 <da_public_hostname> –script ip-https-discover

If the DirectAccess server responds to the request, Nmap will return the following message:

IP-HTTPS is supported. This indicates that this host supports Microsoft DirectAccess.

DirectAccess Troubleshooting with Nmap

If the port is open but the script does not return this message, it is likely that another server or device is responding on TCP port 443, not the DirectAccess server.

Note: If an Application Delivery Controller (ADC) is configured to perform IP-HTTPS preauthentication, the Nmap IP-HTTPS discovery script will not return this result. This is expected and by design.

SSL Certificate Validation

It is not uncommon for DirectAccess clients to fail to connect via IP-HTTPS because of SSL certificate issues. Specifically, an SSL certificate that is not trusted, is expired, or its subject field does not match the public hostname will prevent DirectAccess clients from connecting. To view the SSL certificate configuration of a DirectAccess server, run the following Nmap command with the ssl-cert script.

nmap -n -Pn -p443 <da_public_hostname> –script ssl-cert

DirectAccess Troubleshooting with Nmap

SSL Cipher Suite Configuration

Occasionally there can be issues with the SSL configuration on the DirectAccess server that prevent some clients from connecting, or result in poor performance. This commonly occurs when administrators perform SSL hardening on the DirectAccess server and remove support for null cipher suites. Null cipher suites should never be disabled on the DirectAccess server. They are important to ensure the highest levels of performance for Windows 8.x and Windows 10 clients. Also, if an Application Delivery Controller (ADC) or load balancer is performing SSL offload, lack of support for null cipher suites will prevent Windows 8.x and Windows 10 clients from connecting. To determine if the DirectAccess server supports null cipher suites, run the following Nmap command with the ssl-enum-ciphers script.

nmap -n -Pn -p443 <da_public_hostname> –script ssl-enum-ciphers

DirectAccess Troubleshooting with Nmap

Attack Surface Audit

If DirectAccess implementation and security best practices are followed, the DirectAccess server will be behind an edge firewall. The only port required to be allowed inbound for DirectAccess is TCP port 443. It is recommended that a full port scan be performed against the DirectAccess server’s public IPv4 address to identify any unnecessary ports that may be open externally. To perform a full port scan, run the following Nmap command.

nmap -n -Pn -p- <da_public_hostname>

Ideally it should look like this.

DirectAccess Troubleshooting with Nmap

If it looks something like this, you’re in serious trouble!

DirectAccess Troubleshooting with Nmap

The DirectAccess server should never be listening for requests other that HTTPS on the public Internet. Exposing services such as SMB (TCP port 445), RDP (TCP port 3389), and others presents a significant security risk. It is recommended that edge firewalls be configured to allow inbound TCP port 443 only. If the DirectAccess server is connected directly to the public Internet (not recommended!) then the Windows Firewall should be configured to restrict access to inbound TCP port 443 only.

Additional Resources

DirectAccess IP-HTTPS Discovery Script for Nmap
Planning and Implementing DirectAccess with Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book
DirectAccess Troubleshooting and Consulting Services

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

A Windows 7 or Windows 8.x/10 client may fail to establish a DirectAccess connection using the IP-HTTPS IPv6 transition technology. When troubleshooting this issue, running ipconfig.exe shows that the media state for the tunnel adapter iphttpsinterface is Media disconnected.

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Running the Get-NetIPHttpsState PowerShell command on Windows 8.x/10 clients or the netsh interface httpstunnel show interface command on Windows 7 clients returns an error code of 0x90320, with an interface status Failed to connect to the IPHTTPS server; waiting to reconnect.

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Error code 0x90320 translates to SEC_I_INCOMPLETE_CREDENTIALS, indicating the client was unable to authenticate to the DirectAccess server during the TLS handshake when establishing the IP-HTTPS IPv6 transition tunnel. This occurs when the DirectAccess server or an Application Delivery Controller (ADC) is configured to perform client certificate authentication for IP-HTTPS connections. The client may fail to authenticate if it does not have a valid certificate issued by the organization’s internal certification authority (CA) or if the DirectAccess server or ADC is configured to perform IP-HTTPS client authentication incorrectly.

To resolve this issue, ensure that a valid certificate is installed on the DirectAccess client. In addition, ensure that the DirectAccess server or ADC is configured to use the correct CA when authenticating clients establishing IP-HTTPS connections.

Additional Information

DirectAccess IP-HTTPS Preauthentication 

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

DirectAccess SSL Offload and IP-HTTPS preauthentication using Citrix NetScaler 

DirectAccess IP-HTTPS preauthentication using F5 BIG-IP 

SSL Certificate Considerations for DirectAccess IP-HTTPS 

%d bloggers like this: