Always On VPN IKEv2 Load Balancing and NAT

Always On VPN IKEv2 Load Balancing and NATOver the last few weeks, I’ve worked with numerous organizations and individuals troubleshooting connectivity and performance issues associated with Windows 10 Always On VPN, and specifically connections using the Internet Key Exchange version 2 (IKEv2) VPN protocol. An issue that appears with some regularity is when Windows 10 clients fail to connect with error 809. In this scenario, the server will accept connections without issue for a period of time and then suddenly stop accepting requests. When this happens, existing connections continue to work without issue in most cases. Frequently this occurs with Windows Server Routing and Remote Access Service (RRAS) servers configured in a clustered array behind an External Load Balancer (ELB).

Network Address Translation

It is not uncommon to use Network Address Translation (NAT) when configuring Always On VPN. In fact, for most deployments the public IP address for the VPN server resides not on the VPN server, but on an edge firewall or load balancer connected directly to the Internet. The firewall/load balancer is then configured to translate the destination address to the private IP address assigned to the VPN server in the perimeter/DMZ or the internal network. This is known a Destination NAT (DNAT). Using this configuration, the client’s original source IP address is left intact. This configuration presents no issues for Always On VPN.

Source Address Translation

When troubleshooting these issues, the common denominator seems to be the use of Full NAT, which includes translating the source address in addition to the destination. This results in VPN client requests arriving at the VPN server as appearing not to come from the client’s original IP address, but the IP address of the network device (firewall or load balancer) that is translating the request. Full NAT may be explicitly configured by an administrator, or in the case of many load balancers, configured implicitly because the load balancer is effectively proxying the connection.

Known Issues

IKEv2 VPN connections use IPsec for encryption, and by default, Windows limits the number of IPsec Security Associations (SAs) coming from a single IP address. When a NAT device is performing destination/full NAT, the VPN server sees all inbound IKEv2 VPN requests as coming from the same IP address. When this happens, clients connecting using IKEv2 may fail to connect, most commonly when the server is under moderate to heavy load.

Resolution

The way to resolve this issue is to ensure that any load balancers or NAT devices are not translating the source address but are performing destination NAT only. The following is configuration guidance for F5, Citrix ADC (formerly NetScaler), and Kemp load balancers.

F5

On the F5 BIG-IP load balancer, navigate to the Properties > Configuration page of the IKEv2 UDP 500 virtual server and choose None from the Source Address Translation drop-down list. Repeat this step for the IKEv2 UDP 4500 virtual server.

Always On VPN IKEv2 Load Balancing and NAT

Citrix ADC

On the Citrix ADC load balancer, navigate to System > Settings > Configure Modes and check the option to Use Subnet IP.

Always On VPN IKEv2 Load Balancing and NAT

Next, navigate to Traffic Management > Load Balancing > Service Groups and select the IKEv2 UDP 500 service group. In the Settings section click edit and select Use Client IP. Repeat these steps for the IKEv2 UDP 4500 service group.

Always On VPN IKEv2 Load Balancing and NAT

Kemp

On the Kemp LoadMaster load balancer, navigate to Virtual Services > View/Modify Services and click Modify on the IKEv2 UDP 500 virtual service. Expand Standard Options and select Transparency. Repeat this step for the IKEv2 UDP 4500 virtual service.

Always On VPN IKEv2 Load Balancing and NAT

Caveat

Making the changes above may introduce routing issues in your environment. When configuring these settings, it may be necessary to configure the VPN server’s default gateway to use the load balancer to ensure proper routing. If this is not possible, consider implementing the workaround below.

Workaround

To fully resolve this issue the above changes should be made to ensure the VPN server can see the client’s original source IP address. If that’s not possible for any reason, the following registry key can be configured to increase the number of established SAs from a single IP address. Be advised this is only a partial workaround and may not fully eliminate failed IKEv2 connections. There are other settings in Windows that can prevent multiple connections from a single IP address which are not adjustable at this time.

To implement this registry change, open an elevated PowerShell command window on the RRAS server and run the following commands. Repeat these commands on all RRAS servers in the organization.

New-ItemProperty -Path ‘HKLM:SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\’ -Name IkeNumEstablishedForInitialQuery -PropertyType DWORD -Value 50000 -Force

Restart-Service IKEEXT -Force -PassThru

Additional Information

IPsec Traffic May Be Blocked When A Computer is Behind a Load Balancer

Windows 10 Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

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

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN SSTP Load Balancing with Citrix NetScaler ADCThe Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice when the highest level of security is required for Always On VPN connections. It uses IPsec and features configurable security parameters that allow administrators to adjust policies to meet their specific security requirements. IKEv2 is not without some important limitations, but organizations may insist on the use of IKEv2 to provide the greatest protection possible for remote connected clients. Due to complexities of the IKEv2 transport, special configuration on the Citrix ADC (formerly NetScaler) is required when load balancing this workload.

Special Note: In December 2019 a serious security vulnerability was discovered on the Citrix ADC that gives an unauthenticated attacker the ability to arbitrarily execute code on the appliance. As of this writing a fix is not available (due end of January 2020) but a temporary workaround can be found here.

Load Balancing IKEv2

When an Always On VPN client establishes a connection using IKEv2, communication begins on UDP port 500, but switches to UDP port 4500 if Network Address Translation (NAT) is detected in the communication path between the client and the server. Because UDP is connectionless, custom configuration is required to ensure that VPN clients maintain connectivity to the same backend VPN server during this transition.

Initial Configuration

Load balancing IKEv2 using the Citrix ADC is similar to other workloads. Below are specific settings and parameters required to load balance IKEv2 using the Citrix ADC.

Note: This article is not a comprehensive configuration guide for the Citrix ADC. It assumes the administrator is familiar with basic load balancing concepts and has experience configuring the Citrix ADC.

Service Settings

The load balancing services for IKEv2 VPN will use UDP ports 500 and 4500. Create the service group and assign group members for UDP 500 as follows.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Repeat the steps above to create the service group for UDP port 4500.

Virtual Server Settings

Two virtual servers are required, one for UDP port 500 and one for UDP port 4500. Ensure that the service group using UDP port 500 is bound to the virtual server using the same port.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Repeat the steps above to create the virtual service for UDP port 4500.

Service Monitoring

Since IKEv2 uses the UDP protocol, the only option for service monitoring is to use PING, which is configured by default. Ensure that the firewall on the VPN server allows inbound ICMPv4 and ICMPv6 Echo Request. The default PING monitor on the Citrix ADC will ping the resource every 5 seconds. If a different interval is required, the administrator can edit the PING monitor and bind that to the service or service group as necessary.

Persistency Group

A Persistency Group on the Citrix ADC will be configured to ensure that IKEv2 VPN client requests from the same client are always routed to the same backend server. Follow the steps below to create a Persistency Group and assign it to both IKEv2 virtual servers created previously.

  1. In the Citrix ADC management console expand Traffic Management > Load Balancing > Persistency Groups.
  2. Click Add.
  3. Enter a descriptive name for the Persistency Group.
  4. Select SOURCEIP from the Persistence drop-down list.
  5. Next to the Virtual Server Name section click the Add button.
  6. Add both previously configured IKEv2 virtual servers for UDP 500 and 4500.
  7. Click Create.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Use Client IP

To ensure reliable connectivity for IKEv2 VPN connections it is necessary for the VPN server to see the client’s original source IP address. Follow the steps below to configure the Service Group to forward the client’s IP address to the VPN server.

  1. In the Citrix ADC management console expand System, click Settings, and then click Configure Modes.
  2. Select Use Subnet IP.
  3. Click Ok.Always On VPN IKEv2 Load Balancing and NAT
  4. Expand Traffic Management, click Load Balancing, and then click Service Groups.
  5. Select the IKEv2 UDP 500 Service Group.
  6. Click Edit in the Settings section.
  7. Select Use Client IP.
  8. Repeat these steps on the IKEv2 UDP 4500 Service Group.Always On VPN IKEv2 Load Balancing and NAT

Note: Making the above changes will require configuring the VPN server to use the Citrix ADC as its default gateway.

Additional Information

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 AlWAYS On VPN and IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Certificate Requirements for IKEv2

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Always On VPN SSTP Load Balancing with Citrix NetScaler ADCOne of the many advantages of using Windows Server Routing and Remote Access Service (RRAS) as the VPN server to support Windows 10 Always On VPN connections is that it includes support for the Secure Socket Tunneling Protocol (SSTP). SSTP is a TLS-based VPN protocol that is easy to configure and deploy and is very firewall friendly. This ensures consistent and reliable connectivity even behind restrictive firewalls. The Citrix ADC (formerly NetScaler) is a popular platform for load balancing Always On VPN connections. In this article I’ll describe how to configure load balancing on the Citrix ADC for RRAS VPN connections using the SSTP VPN protocol.

Special Note: In December 2019 a serious security vulnerability was discovered on the Citrix ADC that gives an unauthenticated attacker the ability to arbitrarily execute code on the appliance. As of this writing a fix is not available (due end of January 2020) but a temporary workaround can be found here.

Load Balancing SSTP

Previously I’ve written about some of the use cases and benefits of SSTP load balancing as well as the options for offloading TLS for SSTP VPN connections. Load balancing SSTP eliminates single points of failure and enables support for multiple RRAS VPN servers to increase scalability. It is generally recommended that the Citrix ADC be configured to pass through encrypted SSTP VPN connections. However, TLS offloading can be configured to improve performance and reduce resource utilization on VPN servers, if required.

Configuration

Load balancing SSTP on the Citrix ADC is straightforward and not unlike load balancing a common HTTPS web server. Below are specific settings and parameters required to load balance SSTP using the Citrix ADC.

Note: This article is not a comprehensive configuration guide for the Citrix ADC. It assumes the administrator is familiar with basic load balancing concepts and has experience configuring the Citrix ADC.

Service Settings

The load balancing service for SSTP VPN should be configured to use TCP port 443 and the SSL_BRIDGE protocol. If TLS offload is required, TCP port 80 and the HTTP protocol can be configured. Additional configuration is required on the RRAS server when TLS offload is enabled, however. Detailed information for configuring RRAS and SSTP for TLS offload can be found here.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Virtual Server Settings

The virtual server is configured to use TCP port 443. It is recommended to use SSLSESSION persistence.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

The LEASTCONNECTION load balancing method is the recommend option for load balancing method.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Service Monitoring

Using the default TCP monitor (tcp-default) is not recommended for monitoring SSTP, as a simple TCP port check does not accurately reflect the health of the SSTP service running on the RRAS server. To more precisely monitor the SSTP service status, a new custom monitor must be created and bound to the load balancing services. Follow the steps below to configure a custom SSTP VPN monitor on the Citrix ADC.

  1. Open the Citrix ADC management console and expand Traffic Management.
  2. Select Monitors.
  3. Click Add.
  4. Enter a descriptive name in the Name field.
  5. Select HTTP form the Type drop-down list and click Select.
  6. Adjust the Interval and Response Time-out values according to your requirements.
  7. Enter 401 in the Response Codes field and click the “+” button.
  8. In the Response Codes field click the “x” next to 200.
  9. In the HTTP Request field enter HEAD /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/.
  10. Check the box next to Secure (not required if TLS offload is enabled).
  11. Select ns_default_ssl_profile_backend from the SSL profile drop-down list (not required if TLS offload is enabled).
  12. Click Create.

Always On VPN SSTP Load Balancing with Citrix NetScaler ADC

Once complete, bind the new service monitor to the load balancing services or service groups accordingly.

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 Citrix ADC 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 Citrix ADC and HTTP will be used between the Citrix ADC 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.ps1 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.ps1 -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

Example:

.\Enable-SSTPOffload.ps1 -CertificateHash ‘C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2’ -Restart

Re-Encryption

When offloading TLS for SSTP VPN connections, all traffic between the Citrix ADC 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 Citrix ADC will be configured to terminate and then re-encrypt connections to the RRAS server. When terminating TLS on the Citrix ADC and re-encrypting connections to the RRAS server is required, the same certificate must be used on both the Citrix ADC 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 Load Balancing and SSL Offload

SSL Offload Configuration for Citrix ADC (NetScaler)

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster

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

Windows 10 Always On VPN Connects then Disconnects

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

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

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.

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

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

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

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 and error code of 0x80090326, with an interface status Failed to connect to the IPHTTPS server; waiting to reconnect.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

Error code 0x80090326 translates to SEC_E_ILLEGAL_MESSAGE, indicating the client encountered a fatal error during the SSL handshake.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

There are a number of things that can cause this to happen. The most common scenario occurs when an Application Delivery Controller (ADC) is improperly configured to perform client certificate authentication for IP-HTTPS connections. Common examples are an incorrect or missing root CA certificate, or null SSL/TLS cipher suites not enabled when supporting Windows 8.x/10 clients.

To troubleshoot DirectAccess IP-HTTPS error 0x80090326, perform a network trace on the DirectAccess client and observe the TLS handshake for clues as to which configuration error is the culprit. If the TLS handshake failure occurs immediately after the client sends a Client Hello, it is likely that the ADC does not have null cipher suites enabled.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

If the TLS handshake failure occurs after the Server Hello, it is likely that the ADC is configured to perform client certificate authentication incorrectly, or the client does not have a valid certificate.

Troubleshooting DirectAccess IP-HTTPS Error 0x80090326

IP-HTTPS error 0x80090326 can also occur if an intermediary device is performing SSL/TLS inspection or otherwise tampering with the TLS request. It can also happen if the edge firewall and/or NAT device is forwarding IP-HTTPS connections to the wrong internal server, or if the firewall itself is responding to the HTTPS connection request. Remember, just because the server is responding on TCP port 443 doesn’t necessarily mean that it is the DirectAccess server responding!

Additional Information

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Troubleshooting DirectAccess IP-HTTPS Error 0x2af9

SSL Certificate Considerations for DirectAccess IP-HTTPS

DirectAccess Troubleshooting Consulting Services

Implementing DirectAccess with Windows Server 2016

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 

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Introduction

Communication between the DirectAccess client and server takes place exclusively over IPv6. When DirectAccess servers and/or clients are on the IPv4 Internet, an IPv6 transition technology must be employed to allow those clients to connect to the DirectAccess server. DirectAccess deployment best practices dictate that only the IP-HTTPS IPv6 transition technology be used. IP-HTTPS uses SSL/TLS for server authentication and optionally encryption. To improve security and performance for IP-HTTPS, an Application Delivery Controller (ADC) like the Citrix NetScaler can be configured to perform SSL offloading and client preauthentication for DirectAccess IP-HTTPS connections.

Please note that the following caveats apply when enabling SSL offload for DirectAccess clients:

  • Enabling SSL offload and IP-HTTPS preauthentication on an ADC for DirectAccess is formally unsupported by Microsoft.
  • SSL offload should not be enabled with DirectAccess is configured to use one-time password (OTP) authentication. Offloading SSL will break OTP functionality.

IP-HTTPS Challenges

The IP-HTTPS IPv6 transition technology is a simple and effective way to allow DirectAccess clients and servers to communicate by encapsulating IPv6 traffic in HTTP and routing it over the public IPv4 Internet. However, there are two critical issues with the default implementation of IP-HTTPS in DirectAccess. One is a security issue, the other affects performance.

Security

The DirectAccess server does not authenticate clients establishing IP-HTTPS connections. This could allow an unauthorized client to obtain an IPv6 address from the DirectAccess server using the IPv6 Neighbor Discovery (ND) process. With a valid IPv6 address, the unauthorized user could perform internal network reconnaissance or launch a variety of Denial of Service (DoS) attacks on the DirectAccess infrastructure and connected clients. More details here.

Performance

Windows 7 DirectAccess clients use encrypted cipher suites when establishing IP-HTTPS connections. However, the payload being transported is already encrypted using IPsec. This double encryption increases resource utilization on the DirectAccess server, reducing performance and limiting scalability. More details here.


Note: Beginning with Windows Server 2012 and Windows 8, Microsoft introduced support for null encryption for IP-HTTPS connections. This eliminates the needless double encryption, greatly improving scalability and performance for DirectAccess clients using IP-HTTPS.


SSL Offload for DirectAccess IP-HTTPS

The Citrix NetScaler can be configured to perform SSL offload to improve performance for Windows 7 DirectAccess clients using IP-HTTPS. Since DirectAccess does not natively support SSL offload, the NetScaler must be configured in a non-traditional way. While the NetScaler will be configured to terminate incoming IP-HTTPS SSL connections, it must also use SSL for the back-end connection to the DirectAccess server. However, the NetScaler will be configured only to use null cipher suites when connecting to the DirectAccess server. Even though Windows 7 clients will still perform double encryption to the NetScaler, this configuration effectively offloads from the server the heavy burden of double encrypting every IP-HTTPS connection for all connected DirectAccess clients. This results in reduced CPU utilization on the DirectAccess server, yielding better scalability and performance.

SSL Offload and Windows 8.x/10 Clients

Offloading SSL for Windows 8.x/10 clients will not improve performance because they already use null cipher suites for IP-HTTPS when connecting to a Windows Server 2012 or later DirectAccess server. However, terminating SSL on the NetScaler is still required to perform IP-HTTPS preauthentication.

Supported NetScaler Platforms for DirectAccess SSL Offloading

The following configuration for Citrix NetScaler can be performed on any release of the VPX virtual ADC platform. However, be advised that there is a known issue with older releases on the MDX and SDX hardware platforms that will prevent this from working. For MDX and SDX deployments, upgrading to release 11.1 build 50.10 or later will be required.

Configure Citrix NetScaler for IP-HTTPS SSL Offload

To enable SSL offloading for DirectAccess IP-HTTPS on the Citrix NetScaler, open the NetScaler management console, expand Traffic Management and Load Balancing, and then perform the following procedures in order.

Add Servers

  1. Click Servers.
  2. Click Add.
  3. In the Name field enter a descriptive name for the first DirectAccess server.
  4. Select IP Address.
  5. In the IP Address field enter the IP address of the first DirectAccess server.
  6. Click Create.
  7. Repeat these steps for any additional servers in the load-balanced cluster.

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Add Services

  1. Click Services.
  2. Click Add.
  3. In the Service Name field enter a descriptive name for the service.
  4. Select Existing Server from the Server drop-down list.
  5. Choose the first DirectAccess server in the cluster.
  6. Choose SSL from the Protocol drop-down list.
  7. Click Ok.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler
  8. Edit SSL Parameters.
    1. In the Protocol section uncheck SSLv3.
    2. Click Ok.
  9. Edit SSL Ciphers.
    1. Click Remove All.
    2. Click Add.
    3. Type NULL in the Search Ciphers box.
    4. Check the box next to the first entry for SSL3-NULL-SHA.
    5.  Click the right arrow to add the cipher to the list.
    6. Click Ok.
    7. Click Done.
    8. Repeat these steps for any additional servers in the load-balanced cluster.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

A warning message may be displayed indicating that no usable ciphers are configured on the SSL vserver/service. This message can be safely ignored.

DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Add Virtual Server

  1. Click Virtual Servers.
    1. Click Add.
    2. In the Name field enter a descriptive name for the virtual server.
    3. Choose SSL from the Protocol drop-down list.
    4. In the IP Address field enter the IP address for the virtual server.
    5. Click Ok.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

      Note: When enabling load balancing in DirectAccess, the IP address assigned to the first DirectAccess server is reallocated for use as the load balancing Virtual IP Address (VIP). Ideally this IP address will be assigned to the load balancing virtual server on the NetScaler. However, this is not a hard requirement. It is possible to configure the VIP on the NetScaler to reside on any subnet that the load balancer has an interface to. More details here.


  2. In the Services and Groups section click No Load Balancing Virtual Server Service Binding.
    1. Click on the Select Service field.
    2. Check all DirectAccess server services and click Select.
    3. Click Bind.
    4. Click Continue.
  3. In the Certificate section click No Server Certificate.
    1. Click on the Select Server Certificate field.
    2. Choose the certificate to be used for DirectAccess IP-HTTPS.
    3. Click Select.
    4. Click Bind.
    5. Click Continue.
  4. Edit SSL Ciphers.
    1. Click Remove All.
    2. Click Add.
    3. Type ECDHE in to the Search Ciphers box.
    4. Check the box next to TLS1-ECDHE-RSA-AES128-SHA.
    5. Click the right arrow to add the cipher to the list.
    6. Type NULL in to the Search Ciphers box.
    7. Check the box next to SSL3-NULL-SHA.
    8. Click the right arrow to add the cipher to the list.
    9. Click Ok.
    10. Click Done.DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

      Note: If Windows 8.x/10 clients are supported exclusively, SSL3-NULL-SHA is the only cipher suite required to be configured on the virtual server. If Windows 7 client support is required, the TLS1-ECDHE-RSA-AES128-SHA cipher suite should also be configured on the virtual server.


  5. Edit SSL Parameters.
    1. Uncheck SSLv3.
    2. Click Ok.

      Note: If Windows 8.x/10 clients are supported exclusively, TLSv1 can also be unchecked on the virtual server. If Windows 7 client support is required, TLSv1 must be enabled.


  6. In the Advanced Settings section click Persistence.
    1. Choose SSLSESSION.
    2. Enter 10 minutes for the Time-out (mins) value.
    3. Click Ok.
    4. Click Done.

Optional IP-HTTPS Preauthentication

To enable IP-HTTPS preauthentication to prevent unauthorized network access, perform the following procedures on the Citrix NetScaler appliance.

  1. Expand Traffic Management, Load Balancing, and then click Virtual Servers.
  2. Select the DirectAccess virtual server and click Edit.
    1. In the Certificate section click No CA Certificate.
    2. Click the Select CA Certificate field.
    3. Choose the certificate for the CA that issues certificates to DirectAccess clients and servers.

      Note: The CA certificate used for DirectAccess can be found by opening the Remote Access Management console, clicking Edit on Step 2, and then clicking Authentication. Alternatively, the CA certificate can be found by running the following PowerShell command.

      (Get-RemoteAccess).IPsecRootCertificate | Format-Table Thumbprint


    4. Click Select.
    5. Choose CRL Optional from the CRL and OCSP Check drop-down list.
    6. Click Bind.
  3. Edit SSL Parameters.
    1. Check the box next to Client Authentication.
    2. Choose Mandatory from the Client Certificate drop-down list.
    3. Click Ok.
    4. Click Done.
      DirectAccess SSL Offload and IP-HTTPS Preauthentication with Citrix NetScaler

Summary

Leveraging the advanced capabilities of the Citrix NetScaler ADC can improve performance when supporting Windows 7 clients and enhance security for all DirectAccess clients using IP-HTTPS. In terms of supportability, all of the changes described in this article are completely transparent and do not alter the native DirectAccess client or server configuration. If a Microsoft support engineer declines support due to this configuration, switching from SSL offload to SSL bridge is all that’s required to restore full supportability.

Additional Resources

NetScaler release 11.1 build 50.10 (requires login) – https://www.citrix.com/downloads/netscaler-adc/firmware/release-111-build-5010

Release notes for build 50.10 of NetScaler 11.1 release – https://www.citrix.com/content/dam/citrix/en_us/documents/downloads/netscaler-adc/NS_11_1_50_10.html

VIDEO: Enable Load Balancing for DirectAccess – https://www.youtube.com/watch?v=3tdqgY9Y-uo

DirectAccess IP-HTTPS preauthentication using F5 BIG-IP – https://directaccess.richardhicks.com/2016/05/23/directaccess-ip-https-preauthentication-using-f5-big-ip/

DirectAccess SSL offload for IP-HTTPS using F5 BIG-IP – https://directaccess.richardhicks.com/2013/07/10/ssl-offload-for-ip-https-directaccess-traffic-from-windows-7-clients-using-f5-big-ip/

Implementing DirectAccess with Windows Server 2016 book – http://directaccessbook.com/

Deploying DirectAccess in Microsoft Azure

Introduction

DirectAccess Now a Supported Workload in Microsoft AzureMany organizations are preparing to implement DirectAccess on Microsoft’s public cloud infrastructure. Deploying DirectAccess in Azure is fundamentally no different than implementing it on premises, with a few important exceptions (see below). This article provides essential guidance for administrators to configure this unique workload in Azure.

Important Note: There has been much confusion regarding the supportability of DirectAccess in Azure. Historically it has not been supported. Recently, it appeared briefly that Microsoft reversed their earlier decision and was in fact going to support it. However, the Microsoft Server Software Suport for Microsoft Azure Virtual Machines document has once again been revised to indicate that DirectAccess is indeed no longer formally supported on Azure. More details can be found here.

Azure Configuration

The following is guidance for configuring network interfaces, IP address assignments, public DNS, and network security groups for deploying DirectAccess in Azure.

Virtual Machine

Deploy a virtual machine in Azure with sufficient resources to meet expected demand. A minimum of two CPU cores should be provisioned. A VM with 4 cores is recommended. Premium storage on SSD is optional, as DirectAccess is not a disk intensive workload.

Network Interfaces

It is recommended that an Azure VM with a single network interface be provisioned for the DirectAccess role. This differs from on-premises deployments where two network interfaces are preferred because deploying VMs in Azure with two NICs is prohibitively difficult. At the time of this writing, Azure VMs with multiple network interfaces can only be provisioned using PowerShell, Azure CLI, or resource manager templates. In addition, Azure VMs with multiple NICs cannot belong to the same resource group as other VMs. Finally, and perhaps most importantly, not all Azure VMs support multiple NICs.

Internal IP Address

Static IP address assignment is recommended for the DirectAccess VM in Azure. By default, Azure VMs are initially provisioned using dynamic IP addresses, so this change must be made after the VM has been provisioned. To assign a static internal IP address to an Azure VM, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network Interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click IP configurations.
  6. Click Ipconfig1.
  7. In the Private IP address settings section choose Static for the assignment method.
  8. Enter an IP address for the VM.
  9. Click Save.

Deploying DirectAccess in Microsoft Azure

Public IP Address

The DirectAccess VM in Azure must have a public IP address assigned to it to allow remote client connectivity. To assign a public IP address to an Azure VM, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network Interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click IP configurations.
  6. Click Ipconfig1.
  7. In the Public IP address settings section click Enabled.
  8. Click Configure required settings.
  9. Click Create New and provide a descriptive name for the public IP address.
  10. Choose an address assignment method.
  11. Click Ok and Save.

Deploying DirectAccess in Microsoft Azure

Deploying DirectAccess in Microsoft Azure

Public DNS

If the static IP address assignment method was chosen for the public IP address, create an A resource record in public DNS that resolves to this address. If the dynamic IP address assignment method was chosen, create a CNAME record in public DNS that maps to the public hostname for the DirectAccess server. To assign a public hostname to the VM in Azure, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Overview.
  4. Click Public IP address/DNS name label.Deploying DirectAccess in Microsoft Azure
  5. Under Settings click Configuration.
  6. Choose an assignment method (static or dynamic).
  7. Enter a DNS name label.
  8. Click Save.

Deploying DirectAccess in Microsoft Azure

Note: The subject of the SSL certificate used for the DirectAccess IP-HTTPS listener must match the name of the public DNS record (A or CNAME) entered previously. The SSL certificate does not need to match the Azure DNS name label entered here.

Network Security Group

A network security group must be configured to allow IP-HTTPS traffic inbound to the DirectAccess server on the public IP address. To make the required changes to the network security group, open the Azure management portal and perform the following steps:

  1. Click Virtual machines.
  2. Select the DirectAccess server VM.
  3. Click Network interfaces.
  4. Click on the network interface assigned to the VM.
  5. Under Settings click Network security group.
  6. Click the network security group assigned to the network interface.
  7. Click Inbound security rules.
  8. Click Add and provide a descriptive name for the new rule.
  9. Click Any for Source.
  10. From the Service drop-down list choose HTTPS.
  11. Click Allow for Action.
  12. Click Ok.

Deploying DirectAccess in Microsoft Azure

Note: It is recommended that the default-allow-rdp rule be removed if it is not needed. At a minimum, scope the rule to allow RDP only from trusted hosts and/or networks.

DirectAccess Configuration

When performing the initial configuration of DirectAccess using the Remote Access Management console, the administrator will encounter the following warning message.

“One or more network adapters should be configured with a static IP address. Obtain a static address and assign it to the adapter.”

Deploying DirectAccess in Microsoft Azure

This message can safely be ignored because Azure infrastructure handles all IP address assignment for hosted VMs.

The public name of the DirectAccess server entered in the Remote Access Management console must resolve to the public IP address assigned to the Azure VM, as described previously.

Deploying DirectAccess in Microsoft Azure

Additional Considerations

When deploying DirectAccess in Azure, the following limitations should be considered.

Load Balancing

It is not possible to enable load balancing using Windows Network Load Balancing (NLB) or an external load balancer. Enabling load balancing for DirectAccess requires changing static IP address assignments in the Windows operating system directly, which is not supported in Azure. This is because IP addresses are assigned dynamically in Azure, even when the option to use static IP address assignment is chosen in the Azure management portal. Static IP address assignment for Azure virtual machines are functionally similar to using DHCP reservations on premises.

Deploying DirectAccess in Microsoft Azure

Note: Technically speaking, the DirectAccess server in Azure could be placed behind a third-party external load balancer for the purposes of performing SSL offload or IP-HTTPS preauthentication, as outlined here and here. However, load balancing cannot be enabled in the Remote Access Management console and only a single DirectAccess server per entry point can be deployed.

Manage Out

DirectAccess manage out using native IPv6 or ISATAP is not supported in Azure. At the time of this writing, Azure does not support IPv6 addressing for Azure VMs. In addition, ISATAP does not work due to limitations imposed by the underlying Azure network infrastructure.

Summary

For organizations moving infrastructure to Microsoft’s public cloud, formal support for the DirectAccess workload in Azure is welcome news. Implementing DirectAccess in Azure is similar to on-premises with a few crucial limitations. By following the guidelines outlined in this article, administrators can configure DirectAccess in Azure to meet their secure remote access needs with a minimum of trouble.

Additional Resources

Implementing DirectAccess in Windows Server 2016
Fundamentals of Microsoft Azure 2nd Edition
Microsoft Azure Security Infrastructure
DirectAccess Multisite with Azure Traffic Manager
DirectAccess Consulting Services

%d bloggers like this: