Rendezvous V1

When using the Citrix Gateway Service, the Rendezvous protocol allows VDAs to bypass the Citrix Cloud Connectors to connect directly and securely with the Citrix Cloud control plane.

Requirements

• Access to environment using Citrix Workspace and Citrix Gateway service.
• Control Plane: Citrix DaaS (Citrix Cloud).
• VDA: Version 1912 or later.
  • Version 2012 is the minimum required for EDT Rendezvous.
  • Version 2012 is the minimum required for non-transparent proxy support (no PAC file support).
  • Version 2103 is the minimum required for proxy configuration with a PAC file.
• Enable the Rendezvous protocol in the Citrix policy. For more information, seeRendezvous protocol policy setting.
• The VDAs must have access tohttps://*.nssvc.net, including all subdomains. If you can’t add all subdomains to the allow list in that manner, usehttps://*.c.nssvc.netandhttps://*.g.nssvc.netinstead. For more information, see theInternet Connectivity Requirementssection of the Citrix Cloud documentation (under Citrix DaaS) and the Knowledge Center articleCTX270584.
• The VDAs must be able to connect to the addresses mentioned previously on TCP 443 and UDP 443 for TCP Rendezvous and EDT Rendezvous, respectively.
• Cloud Connectors must obtain the VDAs’ FQDNs when brokering a session. Accomplish this task in one of these two ways:
  • Enable DNS resolution for the site.Navigate toFull Configuration > Settingsand turn on theEnable DNS resolution设置。Alternatively, use the Citrix Virtual Apps and Desktops Remote PowerShell SDK and run the commandSet-BrokerSite -DnsResolutionEnabled $true. For more information about the Citrix Virtual Apps and Desktops Remote PowerShell SDK, seeSDKs and APIs.
  • DNS Reverse Lookup Zone with PTR records for the VDAs.If you choose this option, we recommend that you configure VDAs to always attempt to register PTR records. To do so, use the Group Policy Editor or Group Policy Object, navigate toComputer Configuration > Administrative Templates > Network > DNS Client, and setRegister PTR RecordstoEnabled and Register. If the connection’s DNS suffix does not match the domain’s DNS suffix, you must also configure theConnection-specific DNS suffixsetting for the machines to register PTR records successfully.

  Note:

  If using the DNS resolution option, the Cloud Connectors must be able to resolve the fully qualified domain names (FQDNs) of the VDA machines. In the case that internal users connect directly to the VDA machines, the client devices also must be able to resolve the VDA machines’ FQDNs.

  If using a DNS reverse lookup zone, the FQDNs in the PTR records must match the FQDNs of the VDA machines. If the PTR record contains a different FQDN, the Rendezvous connection fails. For example, if the machine’s FQDN isvda01.domain.net, the PTR record must containvda01.domain.net. A different FQDN such asvda01.sub.domain.netdoes not work.

Proxy configuration

The VDA supports establishing Rendezvous connections through a proxy.

Proxy considerations

Consider the following when using proxies with Rendezvous:

• Transparent proxies, non-transparent HTTP proxies, and SOCKS5 proxies are supported.
• Packet decryption and inspection are not supported. Configure an exception so that the ICA traffic between the VDA and the Gateway Service is not intercepted, decrypted, or inspected. Otherwise, the connection breaks.

• HTTP proxies support machine-based authentication by using Negotiate and Kerberos or NT LAN Manager (NTLM) authentication protocols.

  When you connect to the proxy server, the Negotiate authentication scheme automatically selects the Kerberos protocol. If Kerberos isn’t supported, Negotiate falls back to NTLM for authentication.

  Note:

  To use Kerberos, you must create the service principal name (SPN) for the proxy server and associate it with the proxy’s Active Directory account. The VDA generates the SPN in the formatHTTP/when establishing a session, where the proxy URL is retrieved from theRendezvous proxypolicy setting. If you don’t create an SPN, authentication falls back to NTLM. In both cases, the VDA machine’s identity is used for authentication.

• Authentication with a SOCKS5 proxy is not currently supported. If using a SOCKS5 proxy, you must configure an exception so that traffic destined to Gateway Service addresses (specified in the requirements) can bypass authentication.
• Only SOCKS5 proxies support data transport through EDT. For an HTTP proxy, use TCP as the transport protocol for ICA.

Transparent proxy

If using a transparent proxy in your network, no additional configuration is required on the VDA.

Non-transparent proxy

If using a non-transparent proxy in your network, configure the对接代理配置设置。当启用了设置,指定HTTP or SOCKS5 proxy address, or enter the path to the PAC file so the VDA knows which proxy to use. For example:

• Proxy address:http://:orsocks5://:
• PAC file:http:////.pac

If you use the PAC file to configure the proxy, define the proxy using the syntax required by the Windows HTTP service:PROXY [=]:. For example,PROXY socks5=:.

Rendezvous validation

If you meet all requirements, follow these steps to validate if Rendezvous is in use:

1. Launch PowerShell or a command prompt within the HDX session.
2. Runctxsession.exe –v.
3. The transport protocols in use indicate the type of connection:
   • TCP Rendezvous:TCP > SSL > CGP > ICA
   • EDT Rendezvous:UDP > DTLS > CGP > ICA
   • Proxy through Cloud Connector:TCP > CGP > ICA

Other considerations

Windows cipher suite order

For a custom cipher suite order, make sure that you include the VDA-supported cipher suites from the following list:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

If the custom cipher suite order does not contain these cipher suites, the Rendezvous connection fails.

Zscaler Private Access

If using Zscaler Private Access (ZPA), it is recommended that you configure bypass settings for the Gateway Service to avoid increased latency and the associated performance impact. To do so, you must define application segments for the Gateway Service addresses – specified in the requirements – and set them to always bypass. For information on configuring application segments to bypass ZPA, see theZscaler documentation.