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/

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

Note: The issue described in this article has been resolved in Windows 10 version 1703 (Creators Update). Making these changes is no longer required after installing the Creators Update release of Windows 10.

Introduction

For organizations that have implemented DirectAccess manage out using the Intrasite Automatic Tunnel Addressing Protocol (ISATAP), you may find connecting to remote DirectAccess clients by hostname using Windows 10 or Windows Server 2016 fails. Connections to remote DirectAccess clients using Windows 7, Windows 8.x, Windows Server 2008/2008R2, and Windows Server 2012/2012R2 work without issue.

Troubleshooting

On a Windows 10 or Windows Server 2016 host configured to use ISATAP for DirectAccess manage out, the remote DirectAccess client resolves to an IPv6 address correctly.

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

In addition, a route to the DirectAccess client’s IPv6 prefix is also present in the routing table.

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

Nevertheless, attempts to connect to the remote DirectAccess client by name fail.

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

The DirectAccess client is reachable by its IPv6 address, however.

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

Known Issue

There is a known issue with Windows 10 and Windows Server 2016 DNS client that prevents manage out using ISATAP on these operating systems from working correctly. A while back I wrote about implementing some registry entries as a workaround for this issue on Windows 10. Recently, Karsten Hentrup brought another effective workaround to my attention that also involves adding a registry entry on the ISATAP client machine. This method is preferred as it requires only one registry entry and does not adversely affect existing DNS operation. To make this change, on each machine that requires DirectAccess manage out functionality open an elevated PowerShell command window and run the following command.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name AddrConfigControl -PropertyType DWORD -Value 0 -Force

Summary

When using ISATAP, ensure that this workaround is implemented on any Windows 10 or Windows Server 2016 machine that will require manage out functionality to remote DirectAccess clients.

Additional Resources

ISATAP Recommendations for DirectAccess Deployments

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

Implementing DirectAccess with Windows Server 2012 R2 Book

DirectAccess Consulting Services

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Introduction

DirectAccess is an IPv6 only solution, at least from the perspective of the client. When the DirectAccess client is remote, it communicates with the DirectAccess server using IPv6 exclusively. IPv6 transition technologies are used to enable this connectivity when the DirectAccess server and/or client are on the pubic IPv4 Internet.

IP-HTTPS

One of the IPv6 transition technologies used by DirectAccess is IP-HTTPS. With IP-HTTPS, IPv6 traffic is encapsulated in HTTP and delivered to the DirectAccess server using IPv4. IP-HTTPS is used exclusively when the DirectAccess server is located behind an edge firewall performing network address translation.

SSL Certificate

To support IP-HTTPS, an SSL certificate is installed on each DirectAccess server. The SSL certificate is commonly issued by a public certification authority, but it can also be issued by an internal PKI. The SSL certificate used for IP-HTTPS can and does expire, and when it does it will prevent any DirectAccess connection from being established using this transition technology.

Troubleshooting

When troubleshooting DirectAccess connectivity via IP-HTTPS, the first thing the administrator will notice is that the media state for the DirectAccess client’s IP-HTTPS tunnel adapter interface is shown as disconnected.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

In addition, the Get-NetIPHttpsState PowerShell command returns an error code 0x800b0101 indicating Failed to connect to the IP-HTTPS server; waiting to reconnect.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Err.exe translates this error to CERT_E_EXPIRED, indicating that the SSL certificate is no longer valid.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Viewing the IP-HTTPS SSL certificate is not possible using a web browser. Instead, use Nmap and the ssl-cert script to view the certificate.

nmap.exe -n -Pn -p443 [FQDN] –script ssl-cert

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

In the Operations Status window of the Remote Access Management console on the DirectAccess server, the IP-HTTPS status is listed as Critical. Details show IP-HTTPS not working properly, with an error stating the IP-HTTPS certificate is not valid, and clearly indicating that the certificate is expired.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

The IP-HTTPS status can also be viewed at the command line by issuing the following command in an elevated PowerShell command window.

Get-RemoteAccessHealth | Where-Object Component -eq IP-Https | Format-List

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Updating the Certificate

Simply renewing the SSL certificate is not sufficient to restore IP-HTTPS connectivity for remote DirectAccess clients. The DirectAccess configuration must also be updated to use the new certificate. In the Remote Access Management console, highlight DirectAccess and VPN under Configuration and then click Edit on Step 2 (for load-balanced or multisite DirectAccess deployments, first highlight the individual server and then click Configure Server Settings). Click Network Adapters, click Browse, and then select the new SSL certificate.

DirectAccess Expired IP-HTTPS Certificate and Error 0x800b0101

Click Ok, Next, and then Finish twice and Apply. Repeat these steps for each server in the load-balanced cluster, and for all servers in all entry points in the enterprise.

Alternatively, the IP-HTTPS certificate can be updated in the DirectAccess configuration by opening an elevated PowerShell command window and entering the following commands.

$cert = Get-ChildItem -Path cert:\localmachine\my | Where-Object Thumbprint -eq [cert_thumbprint]
Set-RemoteAccess -SslCertificate $cert -Verbose

For example…

$cert = Get-ChildItem -Path cert:\localmachine\my | Where-Object Thumbprint -eq 2BFD1BC5805EBBF8ACB584DA025AD75B341A8B33
Set-RemoteAccess -SslCertificate $cert -Verbose


Important Note: Be sure to execute these commands on each DirectAccess server in the load-balanced cluster, and for all servers in all entry points in the enterprise.


Self-Signed Certificates

When DirectAccess is deployed using the Getting Started Wizard (GSW), also known as a “simplified deployment“, a self-signed certificate is used for IP-HTTPS. By default, this certificate expires 5 years after it is created. The expiration of a self-signed certificate presentsa unique challenge. Although the self-signed certificate can’t be renewed, it can be re-created or cloned using the New-SelfSignedCertificate PowerShell command. However, DirectAccess clients will not trust this new certificate until they receive the updated client settings via group policy. DirectAccess clients outside the network will not be able to establish IP-HTTPS connections until they receive these new policies. When they attempt to connect to the DirectAccess server without first updating group policy, the IP-HTTPS status will indicate an error code 0x800b0109 which translates to CERT_E_UNTRUSTEDROOT.

If the expired self-signed certificate is replaced with another self-signed certificate (not recommended), DirectAccess clients will have to come back to the internal network or connect remotely via client-based VPN to update group policy and receive the new DirectAccess client settings. A better alternative is to replace the expired self-signed certificate with a public SSL certificate that matches the existing public hostname. This will allow remote clients to reestablish DirectAccess connectivity without the need to udpate group policy first.

Summary

Certificate expiration must be monitored closely to ensure the highest level of availability for the DirectAccess remote access solution. Certificate auto enrollment can be leveraged to ensure that IPsec certificates are automatically renewed prior to expiration. However, the IP-HTTPS certificate must be renewed manually and requires additional configuration after it has been updated.

Additional Resources

DirectAccess Computer Certificate Auto Enrollment

DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS

SSL Certificate Considerations for DirectAccess IP-HTTPS

Implementing DirectAccess with Windows Server 2016 book