Direct Workload Connection

With Direct Workload Connection in Citrix Cloud™, you can optimize internal traffic to the apps and desktops in workspaces to make HDX sessions faster. Ordinarily, users on both internal and external networks connect to VDAs through an external gateway. This gateway might be on-premises in your organization or provided as a service from Citrix and added to the resource location within Citrix Cloud. Direct Workload Connection allows internal users to bypass the gateway and connect to the VDAs directly, reducing latency for internal network traffic.

Note:

The HDX direct feature allows clients to automatically connect to VDAs directly if possible. This removes the need to manually configure your internal network locations.

To set up Direct Workload Connection, you need network locations that correspond to where clients launch apps and desktops in your environment. Add a public address for each office location where these clients reside using the network locations page in Citrix Cloud.

Network locations correspond to the public IP ranges of the networks that your internal users connect from, such as your office or branch locations. Citrix Cloud uses public IP addresses to determine whether the networks from which virtual apps or desktops launched are internal or external to the company network. If a subscriber connects from the internal network, Citrix Cloud routes the connection directly to the VDA, bypassing NetScaler Gateway. If a subscriber connects externally, Citrix Cloud routes them through NetScaler Gateway, then directs the session traffic through the Citrix Cloud Connector to the VDA in the internal network. If the Citrix Gateway service is used and the Rendezvous protocol is enabled, Citrix Cloud routes external users through the Gateway service to the VDA in the internal network. Roaming clients such as laptops might use either of these network routes, depending on whether the client is inside or outside the corporate network when the launch occurs.

Remote Browser Isolation launches always route through the gateway. These launches do not gain performance improvements from configuring Direct Workload Connection.

Requirements

Network requirements

• Corporate network and guest Wi-Fi networks must have separate public IP addresses. If your corporate and guest networks share public IP addresses, users on the guest network can’t launch DaaS sessions.
• Use the public IP address ranges of the networks that your internal users connect from. Internal users on these networks must have a direct connection to the VDAs. Otherwise, launches of virtual resources fail as Workspace tries to route internal users directly to the VDA, which isn’t possible.
• Although VDAs are typically located within your on-premises network, you can also use VDAs hosted within a public cloud such as Microsoft Azure. Client launches must have a network route to contact the VDAs without being blocked by a firewall. This requires a VPN tunnel from your on-premises network to a virtual network where the VDAs reside.

TLS requirements when opening resources in a web browser

If your end users use a web browser to open apps and desktops, Citrix recommends that you have TLS configured on the VDAs in your internal network. Configuring your VDAs to use TLS connections ensures direct launches to VDAs are possible. If VDAs don’t have TLS enabled, app and desktop launches must be routed through a gateway when subscribers use Citrix Workspace app for HTML5. Launches using the Desktop Viewer aren’t affected. For more information about securing direct VDA connections with TLS, see CTX134123 in the Citrix Support Knowledge Center.

Configure Network locations

You configure network locations within Citrix Cloud. For more information, see Network Locations.

If Adaptive Access is enabled then you must configure the locations as Internal. If Adaptive Access is disabled then you cannot select the network location type and all configured network locations are considered internal.

Verify that internal launches are routed correctly

To verify that internal launches are accessing VDAs directly, use one of the following methods:

• View VDA connections through the DaaS console.
• Use ICA® file logging to verify the correct addressing of the client connection.

Citrix DaaS™ console

Select Manage > Monitor and then search for a user with an active session. In the Session Details section of the console, direct VDA connections display as UDP connections while gateway connections display as TCP connections.

If you don’t see UDP on the DaaS Console then you must enable the HDX™ Adaptive Transport Policy for the VDAs.

ICA file logging

Enable ICA file logging on the client computer as described in Citrix Workspace app for Windows documentation. After launching sessions, examine the Address and SSLProxyHost entries in the logged ICA file.

Direct VDA connections

For direct VDA connections, the Address property contains the VDA’s IP address and port.

Here’s an example of an ICA file when a client launches an application using the NLS:

[Notepad++ Cloud]
Address=;10.0.1.54:1494
SSLEnable=Off
<!--NeedCopy-->

The SSLProxyHost property isn’t present in this file. This property is included only for launches through a gateway.

Gateway connections

For gateway connections, the Address property contains the Citrix Cloud STA ticket, the SSLEnable property is set to On, and the SSLProxyHost property contains the gateway’s FQDN and port.

Here’s an example of an ICA file when a client has a connection through the Citrix Gateway service and launches an application:

[PowerShell ISE Cloud]
Address=;40;CWSSTA;027C02199068B33889A40C819A85CBB4
SSLEnable=On
SSLProxyHost=global.g.nssvcstaging.net:443
<!--NeedCopy-->

Here’s an example of an ICA file when a client has a connection through an on-premises gateway and launches an application using an on-premises gateway that is configured within the resource location:

[PowerShell ISE Cloud]
Address=;40;CWSSTA;027C02199068B33889A40C819A85CBB5
SSLEnable=On
SSLProxyHost=onpremgateway.domain.com:443
<!--NeedCopy-->

Note:

On-premises gateway virtual servers that are used to launch virtual apps and desktops must be VPN virtual servers, not nFactor authentication virtual servers. The nFactor authentication virtual servers are for user authentication only and don’t proxy resource HDX and ICA launch traffic.

Troubleshooting

VDA launch failures

If VDA sessions are failing to launch, verify you’re using public IP address ranges from the correct network. When configuring your network locations, you must use the public IP address ranges of the network where your internal users are connecting from to reach the Internet. For more information, see Requirements in this article.

Internal VDA launches still routed through the gateway

If VDA sessions launched internally are still being routed through the gateway as if they were external sessions, verify you’re using the correct public IP address that your internal users are connecting from to reach their workspace. The public IP address listed in the NLS site must correspond to the address that the client launching the resources uses to access the Internet. To obtain the correct public IP address for the client, log on to the client machine, visit a search engine, and enter “what is my ip” in the search bar.

All clients that launch resources within the same office location typically access the Internet using the same network egress public IP address. These clients must have an internet network route to the subnets where the VDAs reside, which isn’t blocked by a firewall. For more information, see Requirements in this article.

Additional help and support

For troubleshooting help or questions, contact your Citrix sales representative or Citrix Support.