Configuring DTLS 1.2 on NetScaler to Support EDT for Citrix
Introduction
Citrix official documentation and the options available for DTLS configuration on NetScaler (Citrix) Gateway vServers is confusing with regard to the use of DTLS 1.2 for EDT ICA proxy connections for Citrix applications and desktops. There are multiple methods for configuring Citrix Gateway vServers to support DTLS connections and Citrix official documentation “seems” to indicate that DTLS 1.2 is not supported on Gateway vServers for DTLS while the NetScaler GUI for NetScaler DTLS Gateway vServers allows the choice of enabling and disabling both DTLS 1.0 and DTLS 1.2. While DTLS 1.0 is simple enough to do within the standard “SSL” Citrix Gateway Server, it does not support DTLS 1.2 and relies on a TLS cipher that some organizations may be uncomfortable with. The confusion pertaining to DTLS 1.2 functionality and Citrix Gateway appears to primarily be an issue of conflicting documentation. Several large organizations have configured Citrix Gateway DTLS vServers (as opposed to SSL vServers) with DTLS 1.0 disabled and DTLS 1.2 enabled and have tens of thousands of concurrent user ICA sessions successfully connecting and using DTLS 1.2. This blog attempts to discuss the methods of enabling DTLS for NetScaler Gateway and the limitations of different methods.
Note: This article may reference NetScaler Gateway and Citrix Gateway. They are interchangeable and mean the same thing.
Methods of Configuring Citrix Gateway for DTLS and EDT
There are two methods for configuring DTLS for a NetScaler providing NetScaler Gateway services for access to applications and desktops.
Method 1 – The “DTLS Checkbox” on a Configured SSL Gateway vServers
The default setting for the use of front-end DTLS has been DTLS = ON for newly created NetScaler Gateway SSL vServers since firmware version 12.0.56.20.
When configuring a standard SSL NetScaler Gateway vServer on modern NetScaler firmware, the ability to modify settings related to DTLS versions and ciphers is limited.
Note: This method only supports DTLS 1.0.
The screenshots below show the configurations created for a standard SSL NetScaler Gateway vServer configured for HDX traffic with OGR in a lab.
The GUI configuration above creates the following command lines:
add vpn vserver Standard_SSL_GW_VIP_with_DTLS_checkbox SSL 192.168.7.119 443 -authentication OFF -downStateFlush DISABLED -Listenpolicy NONE set ssl vserver Standard_SSL_GW_VIP_with_DTLS_checkbox -dtls1 DISABLED
Notice that the “set ssl vserver” command is set with DTLS 1.0 disabled. Despite being disabled, the DTLS listener created will only take DTLS 1.0 connections. This setting cannot be modified from the GUI or the CLI.
> set ssl vserver Standard_SSL_GW_VIP_with_DTLS_checkbox -dtls1 ENABLED ERROR: DTLS options are not applicable to non-DTLS vserver/Service > set ssl vserver Standard_SSL_GW_VIP_with_DTLS_checkbox -dtls12 ENABLED ERROR: DTLS options are not applicable to non-DTLS vserver/Service
Additionally, the only way to specify the ciphers used by the DTLS connections is to modify the cipher list used by the non-DTLS SSL listener. Since DTLS 1.0 is in use, weaker TLS 1.0 ciphers are required to be placed in the same list with the ciphers used by the SSL listener. This can be remediated by using SSL settings on the SSL Gateway vServer and disabling TLS 1.0 or using an SSL profile on the SSL Gateway vServer with TLS 1.0 disabled. This may increase the difficulty of security auditing for the settings on the SSL Gateway vServer and the use of DTLS 1.0 on the DTLS listener may not pass security audits.
The cipher list below applied to an SSL Gateway vServer may pass the security auditing smell test.
The commands below create the SSL Cipher Group depicted in the screenshot above.
add ssl cipher CUSTOM-SECURE-Q2-2024 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.3-AES256-GCM-SHA384 -cipherPriority 1 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.3-CHACHA20-POLY1305-SHA256 -cipherPriority 2 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.3-AES128-GCM-SHA256 -cipherPriority 3 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256 -cipherPriority 4 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384 -cipherPriority 5 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.2-ECDHE-RSA-CHACHA20-POLY1305 -cipherPriority 6
The cipher list below required for enabling DTLS 1.0 with the DTLS checkbox on an SSL Gateway vServer will rightfully raise some security auditor’s eyebrows and require detailed explanations and likely filing security exceptions.
The commands below create the SSL Cipher Group depicted in the screenshot above.
add ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1.3-AES256-GCM-SHA384 -cipherPriority 1 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1.3-CHACHA20-POLY1305-SHA256 -cipherPriority 2 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1.3-AES128-GCM-SHA256 -cipherPriority 3 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256 -cipherPriority 4 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384 -cipherPriority 5 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1.2-ECDHE-RSA-CHACHA20-POLY1305 -cipherPriority 6 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1-AES-256-CBC-SHA -cipherPriority 7 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1-AES-128-CBC-SHA -cipherPriority 8 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1-ECDHE-RSA-AES256-SHA -cipherPriority 9 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1-ECDHE-RSA-AES128-SHA -cipherPriority 10 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1-ECDHE-ECDSA-AES256-SHA -cipherPriority 11 bind ssl cipher CUSTOM-SECURE-PLUS-DTLS1-Q2-2024 -cipherName TLS1-ECDHE-ECDSA-AES128-SHA -cipherPriority 12
If an organization is willing to allow weaker ciphers for DTLS 1.0 and requires stronger ciphers for SSL for Citrix Gateway vServers, or has a hard requirement for the use of the DTLS checkbox on an SSL Gateway vServer, the following configuration will function.
The commands below create the configurations depicted in the screenshot above.
add vpn vserver Standard_SSL_GW_VIP_with_DTLS_checkbox SSL 192.168.7.119 443 -authentication OFF -dtls ON -downStateFlush DISABLED -Listenpolicy NONE set ssl vserver Standard_SSL_GW_VIP_with_DTLS_checkbox -ssl3 DISABLED -tls1 DISABLED -tls11 DISABLED -tls13 ENABLED -dtls1 DISABLED -HSTS ENABLED -maxage 31536000 bind ssl vserver Standard_SSL_GW_VIP_with_DTLS_checkbox -cipherName CUSTOM-SECURE-PLUS-DTLS1-Q2-2024
Method 2 – Creation of DTLS Citrix Gateway vServer
Several years ago, NetScaler introduced the DTLS Citrix Gateway vServer which provides support for both DTLS 1.0 and DTLS 1.2. It does not support TLS, however. Configuring a DTLS NetScaler Gateway vServer with the same IP address as the SSL NetScaler Gateway vServer on modern NetScaler firmware allows the ability to modify settings related to DTLS versions and ciphers.
The screenshots below show the configurations modified for a standard SSL NetScaler Gateway vServer configured for HDX Gateway OGR and the configurations for an additional DTLS NetScaler Gateway vServer with custom DTLS settings and Ciphers.
In this configuration example, we are assuming the Citrix Gateways are for HDX traffic only, and not for authentication traffic, although the regular SSL Citrix Gateway Server could be configured for authentication for your use case if required (this would not be required for the DTLS vServer).
The end result will be two Citrix Gateway vServers with the same IP: one supporting TCP connections via SSL/TLS and one supporting UDP connections via DTLS. This provides support for both TCP and UDP (EDT/HDX Adaptive Transport) Citrix ICA traffic. While the DTLS vServer alone might suffice in theory, the Citrix HDX Adaptive Transport architecture defaults to allowing a fallback to TCP, so including both is recommended to accommodate different use case situations that might prevent connectivity such as client limitations (as of June 2024, several Workspace App clients do not yet support DTLS 1.2 such as macOS).
SSL Gateway vServer configured for HDX Gateway OGR with Authentication Disabled and DTLS unchecked
Set up a standard SSL Gateway vServer with the DTLS checkbox unchecked or if the Gateway vServer is already created, uncheck the DTLS checkbox.
The commands below create the configurations depicted in the screenshot above.
add vpn vserver Standard_SSL_GW_VIP_without_DTLS SSL 192.168.7.119 443 -authentication OFF -dtls OFF -downStateFlush DISABLED -Listenpolicy NONE
The standard SSL Gateway vServer can be configured to use more secure cipher groups.
The commands below create the SSL Cipher Group depicted in the screenshot above.
add ssl cipher CUSTOM-SECURE-Q2-2024 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.3-AES256-GCM-SHA384 -cipherPriority 1 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.3-CHACHA20-POLY1305-SHA256 -cipherPriority 2 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.3-AES128-GCM-SHA256 -cipherPriority 3 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256 -cipherPriority 4 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384 -cipherPriority 5 bind ssl cipher CUSTOM-SECURE-Q2-2024 -cipherName TLS1.2-ECDHE-RSA-CHACHA20-POLY1305 -cipherPriority 6
The more secure cipher group can be bound to the standard SSL Gateway vServer.
The commands below create configurations depicted in the screenshot above.
set ssl vserver Standard_SSL_GW_VIP_without_DTLS -ssl3 DISABLED -tls1 DISABLED -tls11 DISABLED -tls13 ENABLED -dtls1 DISABLED -HSTS ENABLED -maxage 31536000 bind ssl vserver Standard_SSL_GW_VIP_without_DTLS -cipherName CUSTOM-SECURE-Q2-2024
Configuring the SSL Gateway vServer without the DTLS checkbox clicked allows the creation of a dedicated DTLS Gateway vServer which is capable of handling DTLS 1.2 traffic and allows the use of a custom cipher group with only DTLS 1.2 ciphers.
DTLS Gateway vServer configured for HDX Gateway OGR with Authentication Disabled
Create a dedicated DTLS Gateway vServer to handle DTLS traffic.
add vpn vserver DTLS_GW_VIP DTLS 192.168.7.119 443 -downStateFlush DISABLED
Create a Custom DTLS cipher group with only DTLS 1.2 ciphers.
The commands below create the SSL Cipher Group depicted in the screenshot above.
add ssl cipher CUSTOM_DTLS bind ssl cipher CUSTOM_DTLS -cipherName TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384 -cipherPriority 1 bind ssl cipher CUSTOM_DTLS -cipherName TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256 -cipherPriority 2
Create a custom DTLS profile that can be modified in the future in the event that security requires changes to DTLS settings. The current default settings for DTLS profiles meet the standards required to remediate all previous security issues with Citrix NetScalers, but the default DTLS profiles cannot be modified.
The commands below create configurations depicted in the screenshot above.
add ssl dtlsProfile Custom_DTLS_Profile
Bind the custom DTLS cipher group and the custom DTLS Profile to the dedicated DTLS Gateway Server.
The commands below create configurations depicted in the screenshot above.
set ssl vserver DTLS_GW_VIP -sessReuse ENABLED -sessTimeout 1800 -ssl3 DISABLED -tls1 DISABLED -tls11 DISABLED -tls12 DISABLED -dtls1 DISABLED -dtls12 ENABLED -pushEncTrigger Ignore -dtlsProfileName Custom_DTLS_Profile bind ssl vserver DTLS_GW_VIP -cipherName CUSTOM_DTLS
You will have two NetScaler Gateway vServer objects with the same IP address and listening on the same port, but one will be listening on TCP port 443 and the other will be listening on UDP 443 as depicted in the screenshot below.
Note on STAs: While STAs should be set on the SSL vServer (not shown), they should not be required on the DTLS vServer. In fact, on firmware 13.1 b 53.17 we were unable to bind them at all (not an option in GUI and errors out in CLI).
When a user initially connects a new ICA session, it will attempt to connect via the DTLS Gateway vServer on UDP port 443. If there are any issues with the DTLS connection, the session will fall back to a connection on the standard SSL Gateway vServer on TCP port 443.
Below is a wireshark image showing the traffic flowing using DTLS 1.2.
Nice explanation. As a lot of clients use CS in front of GW, we found that apart of enabling DTLS flag on CS, you can just add predefined DTLS_FIPS ciphers in order to ger DTLS working
Hi Greg, what type of CS vServer did you create? And did your config actually enable the use of DTLS 1.2?
Hi. It was classical SSL CS vserver with addeed DTLS_FIPS ciphers. I am 99% positve we saw DTLS 1.2 traffic in wireshark, but can double check next week once customer is back.
(Late) update – if you enable DTLS flag on CS, it will only enable DTLS 1.0 – similar to what you explain in your post. In DTLS handshake, server only respnds with 1.0 version. So, for customers that use CS in front of GW, your solution would also be appropriate. You would need to create GW on same IP+port, just with DTLS type.
Nice details, thanks for that! In your case it’s for HDX EDT – would you also recommend to do the same thing (second vServer with same IP for UDP) for SSLVPN? I’m just wondering if the CSA client would also do a correct fallback to TCP, if the tunnel is not able to connect via UDP.
Great article. We also implemented DTLS 1.2 for some environments but we see if we are binding the ciphers in the CUSTOM_DTLS ciphergroup we can’t get HDX adaptive transport over UDP to work. When we add the cipher “TLS1-ECDHe-RSA-AES128-SHA” to the Custom_DTLS ciphergroup it works. Do you have any explanation why we still need the tls1 ciphers? We would like to use only ciphers with TLS 1.2.
Hi, have you built the configuration exactly as outlined in the guide? If you are using merely an SSL vServer, you need that TLS1 cipher as the SSL vServer can only do DTLS 1.0. For DTLS 1.2 must also build the DTLS type vServer (and disable DTLS on the SSL vServer prior) at which point you can bind the custom DTLS cipher group to the DTLS vServer. Please also be sure your clients support DTLS 1.2. For example MacOS Workspace App does not yet support DTLS 1.2 while it does support DTLS 1.0.
Hi Michael,
I’ve built the configuration exactly as outlined in the guide. I’ve created a new vServer with DTLS 1.2 enabled and disabled DTLS on the SSL vServer. I used the same ciphers as in the article for the SSL vServer and employed the custom TLS ciphers for the DTLS vServer. When only the two ciphers are bound to the DTLS vServer, there is no UDP traffic, and it fails back to TCP. However, when I add the ciphers as I mentioned before, the connection is over UDP.