Product documentation
Citrix DaaS
View PDF

HDX Direct

December 16, 2024
Contributed by: 
C

When accessing Citrix-delivered resources, HDX Direct allows both internal and external client devices to establish a secure direct connection with the session host if direct communication is possible.

Important:

HDX Direct for external users is currently in preview. This feature is provided without support and is not yet recommended for use in production environments. To submit feedback or report issues, use this form.

System requirements

The following are the system requirements for using HDX Direct:

  • Control plane

    • Citrix DaaS
    • Citrix Virtual Apps and Desktops 2411 or later

  • Virtual Delivery Agent (VDA)

    • Windows: version 2411 or later

  • Workspace app

    • Windows: version 2409 or later
    • Linux: version 2411 or later
    • Mac: version 2411 or later

  • Access tier

    • Citrix Workspace with Citrix Gateway Service
    • Citrix Workspace with NetScaler Gateway

  • Other

    • Adaptive Transport must be enabled for external direct connections

Network requirements

The following are the network requirements for using HDX Direct.

Session hosts

If your session hosts have a firewall such as Windows Defender Firewall, you must allow the following inbound traffic for internal connections.

Description Source Protocol Port
Direct internal connection Client TCP 443
Direct internal connection Client UDP 443

Note:

The VDA installer adds the appropriate inbound rules to Windows Defender Firewall. If you use a different firewall, you must add the rules above.

Client network

The following table describes the client network for internal and external users.

Internal users

Description Protocol Source Source port Destination Destination port
Direct internal connection TCP Client network 1024–65535 VDA network 443
Direct internal connection UDP Client network 1024–65535 VDA network 443

External users

Description Protocol Source Source port Destination Destination port
STUN (external users only) UDP Client network 1024–65535 Internet (see note below) 3478, 19302
External user connection UDP Client network 1024–65535 Data center’s public IP address 1024–65535

Data center network

The following table describes the data center network for internal and external users.

Internal users

Description Protocol Source Source port Destination Destination port
Direct internal connection TCP Client network 1024–65535 VDA network 443
Direct internal connection UDP Client network 1024–65535 VDA network 443

External users

Description Protocol Source Source port Destination Destination port
STUN (external users only) UDP VDA network 1024–65535 Internet (see note below) 3478, 19302
External user connection UDP DMZ / Internal network 1024–65535 VDA network 55000–55250
External user connection UDP VDA network 55000–55250 Client’s public IP 1024–65535

Note:

Both the VDA and Workspace app attempt to send STUN requests to the following servers in the same order:

  • stun.cloud.com:3478
  • stun.cloudflare.com:3478
  • stun.l.google.com:19302

If you change the default port range for external user connections using the HDX Direct port range policy setting, the corresponding firewall rules must match your custom port range.

Configuration

HDX Direct is disabled by default. You can configure this feature using the HDX Direct setting in the Citrix policy.

  • HDX Direct: To enable or disable a feature.
  • HDX Direct mode: Determines if HDX Direct is available for internal clients only or for both internal and external clients.
  • HDX Direct port range: Defines the port range that the VDA uses for connections from external clients.

Considerations

The following are considerations for using HDX Direct:

  • HDX Direct for external users is only available with EDT (UDP) as the transport protocol. Therefore, Adaptive Transport must be enabled.
  • If you are using HDX Insight, note that using HDX Direct prevents the HDX Insight data collection, as the session would no longer be proxied through NetScaler Gateway.
  • When using non-persistent machines for your virtual apps and desktops, Citrix recommends enabling HDX Direct on the session hosts instead of in the master/template image so that each machine generates its own certificates.
  • Using your own certificates with HDX Direct is not currently supported.

How it works

HDX Direct allows clients to establish a direct connection to the session host when direct communication is available. When direct connections are made using HDX Direct, self-signed certificates are used to secure the direct connection with network level-encryption (TLS/DTLS).

Internal users

The following diagram depicts the overview of the HDX Direct connection process of internal users.

HDX Direct Overview

  1. The client establishes an HDX session through the Gateway Service.
  2. Upon a successful connection, the VDA sends to the client the VDA machine’s FQDN, a list of its IP addresses, and the VDA machine’s certificate via the HDX connection.
  3. The client probes the IP addresses to see if it can reach the VDA directly.
  4. If the client can reach the VDA directly with any of the IP addresses shared, the client establishes a direct connection with the VDA, secured with (D)TLS using a certificate that matches the one exchanged in step (2).
  5. Once the direct connection is successfully established, the session is transferred to the new connection, and the connection to the Gateway Service is terminated.

Note:

After establishing the connection in step 2, above, the session is active. The subsequent steps do not delay or interfere with the user’s ability to use the virtual application or desktop. If any of the subsequent steps fail, the connection through the Gateway is maintained without interrupting the user’s session.

External users

The following diagram depicts the overview of the HDX Direct connection process for external users:

HDX Direct connection process

  1. The client establishes an HDX session through the Gateway Service.
  2. Upon a successful connection, both the client and the VDA send a STUN request to discover their public IP addresses and ports.
  3. The STUN server responds to the client and VDA with their corresponding public IP addresses and ports.
  4. Through the HDX connection, the client and the VDA exchange their public IP addresses and UDP ports, and the VDA sends its certificate to the client.
  5. The VDA sends UDP packets to the client’s public IP address and UDP port. The client sends UDP packets to the VDA’s public IP address and UDP port.
  6. Upon receipt of a message from the VDA, the client responds with a secure connection request.
  7. During the DTLS handshake, the client verifies that the certificate matches the certificate exchanged in step (4). After validation, the client sends its authorization token. A secure direct connection is now established.
  8. Once the direct connection is successfully established, the session is transferred to the new connection, and the connection to the Gateway Service is terminated.

Note:

After establishing the connection in step 2, above, the session is active. The subsequent steps do not delay or interfere with the user’s ability to use the virtual application or desktop. If any of the subsequent steps fail, the connection through the Gateway is maintained without interrupting the user’s session.

Certificate management

Session host

The following two services on the VDA machine handle certificate creation and management, both of which are set to run automatically at machine startup:

  • Citrix ClxMtp Service: Responsible for CA certificate key generation and rotation.
  • Citrix Certificate Manager Service: Responsible for generating and managing the self-signed root CA certificate and the machine certificates.

The following steps depict the certificate management process:

  1. The services start at machine startup.
  2. Citrix ClxMtp Service creates keys if none has been created already.
  3. Citrix Certificate Manager Service checks if HDX Direct is enabled. If not, the service stops itself.
  4. If HDX Direct is enabled, the Citrix Certificate Manager Service checks if a self-signed root CA certificate exists. If not, a self-signed root certificate is created.
  5. Once a root CA certificate is available, the Citrix Certificate Manager Service checks if a self-signed machine certificate exists. If not, the service generates keys and creates a new certificate using the machine’s FQDN.
  6. If there is an existing machine certificate created by the Citrix Certificate Manager Service and the subject name does not match the machine’s FQDN, a new certificate is generated.

Note:

The Citrix Certificate Manager Service generates RSA certificates that leverage 2048-bit keys.

Client device

To successfully establish a secure HDX Direct connection, the client must trust the certificates used to secure the session. To facilitate this, the client receives the CA certificate for the session through the ICA file (supplied by Workspace), so it is not necessary to distribute CA certificates to the client devices’ certificate stores.

HDX Direct
December 16, 2024
Contributed by: 
C
December 16, 2024
Contributed by: 
C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.