Optimize your Citrix Virtual Apps and Desktops services Traffic flow

The default traffic flow isn’t optimized when designing a new Citrix Virtual Apps and Desktops services (CVAD) environment. There are a couple of options that would result in a better traffic flow. The more you optimize the traffic flow, the better the User Experience, and I think that’s what everybody wants because happy users make happy admins. Some options are only for on-premises deployments, while others are for both on-premises and public cloud deployments. This article shows some options that don’t need any massive changes and are easy to implement.

The Default

The default traffic flow isn’t optimized, and it depends on a couple of different components that could all result in latency. When one of these components fails, it results in a disconnected session or even downtime. To better understand how the current traffic flows, look at the diagram below.

Default CVAD traffic Flow
Default CVAD traffic Flow

As you can see, all traffic goes through your Cloud Connectors, causing a high dependency on your Cloud Connectors. That’s why you would like to have them redundant and give them the appropriate resources.

Now that you understand the default traffic flow, it’s time to look at the options to optimize your traffic flow and realize a better user experience.

Rendezvous Protocol Traffic flow

The first option to optimize your traffic flow is the Rendezvous protocol. With this option enabled, your users don’t depend on the Cloud Connectors when they have a session. This option is available for public Cloud, Private Cloud, and on-premises. Whit every new Citrix Virtual Apps and Desktop Services deployment, this option is enabled by default, but current deployments could benefit from enabling this option.

What’s the benefit of this for you and your end-users:

  1. The user doesn’t notice any delay if the Cloud Connectors are overloaded or fail.
  2. As the cloud connectors no longer proxies the VDA-Gateway traffic makes them more scalable.

Have a look at the below diagram where the Rendezvous protocol is enabled

CVAD Rendezvous Traffic flow
CVAD Rendezvous Traffic flow

Requirements and validation

As mentioned before, Whit every new Citrix Virtual Apps and Desktop Services deployment, this option is enabled by default. An updated and detailed list of the requirements is available here. Below are some of the requirements you should take a look at:

  • Access to the environment using Citrix Workspace and Citrix Gateway service.
  • Control Plane: Citrix Virtual Apps and Desktops Service (Citrix Cloud).
  • VDA: Version 1912 or later.
    • 2012 is the minimum required for EDT Rendezvous.
    • 2012 is the minimum required for non-transparent proxy support (no PAC file support).
    • 2103 is the minimum required for proxy configuration with a PAC file.
  • The VDAs must have access to https://*.nssvc.net
  • The VDAs must be able to connect to the addresses mentioned above 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 in one of these two ways:
    • Enable DNS resolution for the site.
    • DNS Reverse Lookup Zone with PTR records for the VDAs.

If you meet all these requirements, you can validate if the rendezvous protocol is enabled. The first thing you should look at is to see if the policy is enabled. This option is enabled by default but could have been disabled by another admin or a previous deployment. Below you can see the policy enabled.

When the policy is configured correctly, you can validate if the rendezvous protocol is working by following these steps:

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

Direct Workload Connection Traffic flow

When you have configured the Rendezvous protocol and notice it, your users undoubtedly notice this next option. The downside of this next option is that it requires that your workload is on-premises or your branch offices have a direct connection to your data center.

The default traffic flow and rendezvous protocol traffic flow directs all traffic through the Gateway Service, even when you sit next to your VDA. We don’t want to take a detour while you can use a direct route. A direct route gives us fewer dependencies and the best user experience, and that’s when Direct Workload Connection comes in place.

Whit Direct Workload Connection, your internal users connect to the VDA directly, without the traffic going through the Gateway Service. Although there are numerous Points of Presence (PoPs) for the Gateway Services to reduce latency, this is never the most optimized connection for internal users that connect to an internal VDA routed through an external Gateway. That is causing latency, and latency causes unhappy users.

How does Direct Workload Connection work?

When a user connects to the Citrix Cloud, the traffic comes from a public IP address. This address is used to determine if the user is an Internal or External user. But before Citrix Workspace knows which Public IP Address is associated with your on-premises VDA and internal users, you need to create these locations in your workspace management plane.

But why shouldn’t you use the internal Ip address, you would think? The answer is relatively simple. When using the endpoint/internal IP address, we quickly would run into issues. How many users, public places, and customers you visit have the following internal-only IP Address scheme (,, Suppose you connect to Citrix Workspace with an endpoint with an IP address the same as you defined as internal. In that case, Citrix Workspace thinks you are internal and tries to bypass the Gateway Service, resulting in a failed connection.

Below you can see the diagram of how Direct Workload Connection is working. As you can see, the internal user has the same Public IP (I think everyone knows this one) as the VDA, which means the internal user connects directly to the VDA. The External user has a different Public IP address (non-existing) as the VDA, so this traffic goes through the Gateway Service.

To add the public IP addresses of your on-premises environment and branch offices that have a direct connection to your data center. Sign in to Citrix Cloud and go to the “Network Locations”, there you can see all previously added locations and add a new Network location.

Validate Direct Workload

There are two options to see if Direct Workload is configured correctly and is working

Option 1: Using the Citrix Director
Go to a user’s session and then go to the Details of that session, there you see the Session Details. When the Connected via IP address equals its Endpoint IP address, Directworkload is working. See below two examples:

Option 2: ICA file logging

Navigate to the following registry key by using the registry editor:

32-bit Systems: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\Logging

64-bit Systems: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\Logging

Set the following two string key values:

  1. LogFile=” path to the log file”
  2. LogICAFile=true

Then start a new Citrix Session and open the log file, there you see that it shows the VDA’s IP INTERNAL address. See the image below:


There are a few options to optimize the traffic flow as described before. The Rendezvous Protocol can you use on-premises as in the public cloud, where Direct Workload Connection is only an option when you can connect to your VDA’s directly. Both options help you get a better user experience. Your external users will benefit from the rendezvous protocol, where your internal users will benefit from the Direct Workload Connection. All that matters is that happy users make happy admins.

HTTP error with the Powershell SDK – Quickpost

This week we were having issues while connecting to Citrix Cloud using the Powershell SDK (more info) for Citrix Virtual Apps and Desktops services; we received the following error:

An error occurred while making the HTTP request to https://<customerID>.xendesktop.net/Citrix/SdkRouter/V2. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server.

Powershell SDK
Powershell SDK error

After some intensive troubleshooting, we discovered that it’s a .net Framework security issue. It took us 4 hours to discover this. 🙁

To solve this issue you need to modify the following registry keys:



Where you can change V4.0.30319 to a higher or lower number as it’s compatible with newer releases. That means that if you are using .net V4.8 and change the key in version 4.0 it works and you can use the Powershell SDK to manage your Citrix Cloud environment.

Hope I save you a lot of troubleshooting when you have this issue with Powershell SDK.

Reauthentication period for Workspace app

In the latest update, Citrix released a new feature called “Reauthentication period for Workspace app”. This enables the Citrix admin to set the reauthentication time for a user. This is one of the most frequently asked questions when I implement Citrix Virtual Apps and Desktops services with Citrix Gateway Services. People authenticate using the defined Identity Provider (IdP) (look here for choosing the correct IdP) and keep signed in, without the need to reauthenticate when they go home and continue to work there.

Yes, they authenticated when they started the Citrix Workspace app, and yes they authenticated when signing into their laptop at home. But for most IT managers it feels strange that when they sign on at the office where conditional access doesn’t require MFA, the user can go home and continue working without authentication with MFA. They think it’s a security risk, which I understand, but everything depends on the security of the mobile device.

Before Citrix released the feature “Reauthentication period for Workspace app” (which currently is in Tech Preview), the only option to control the authentication token is to set it with a GPO or Registry Key. The authentication tokens were designed so a user doesn’t need to reenter their credentials when the system or session restarted. The token is stored encrypted on the device, but it was not possible to set a maximum duration. As of Citrix Workspace app v2106, you are able to disable or enable storing the authentication token on the local device using the Global App Configuration Service

Configuring the Reauthentication period

The default setting requires users to sign in every 24 hours (1 day). You could specify a longer time up to 365 days (I won’t know why you would choose such a long time, but it’s possible). If you specify a longer period than 24 hours, the user always needs to reauthenticate after four days of inactivity.

To change the default reauthentication period, sign in to the Citrix Cloud console, go to the workspace configuration, and select preferences. Scroll down to workspace sessions, where it’s possible to change the current reauthentication period.

Supported Workspace app clients

The following versions of the Citrix Workspace app support this feature:

  • Workspace app 2106 for Windows or later
  • Workspace app 2106 for Mac or later
  • Workspace app for 21.6.5 iOS or later
  • Workspace app for 21.6.0 Android or later

Supported authentication methods

Staying signed in to the Workspace app is supported for the following authentication methods:

  • Active Directory
  • Active Directory plus token
  • Azure Active Directory
  • Citrix Gateway
  • Okta

I personally would like to set the reauthentication time to a shorter time than 1 day, let’s say 12 hours, this makes it more secure and the user will notice that he needs to sign in again when continuing work after going home. For more information regarding the reauthentication period, see the Citrix docs.

Choosing the correct Identity Provider (IdP) for Citrix Cloud

Updated 22-09-2021!

Choosing the correct Identity Provider (IdP) for your new Citrix Cloud environment is one of the most discussed items and one of the first points when starting a new deployment. Most organizations already have an Identity Provider (IdP) and would like to give users the easiest way to migrate to their new deployments. Sadly it’s not always possible to keep it that simple.

I explain the pros and cons as much as possible and what I learned during my latest projects. I don’t have any experience with Okta or SAML, so I can’t give all the details about those issues. If anyone has additional information about the integration with Okta or SAML, please let me know, and I update the article. I look at Citrix Virtual Apps and Desktops services and Gateway Services integration for SSO to SaaS apps or Enterprise web apps.

My projects are starting with a migration of their traditional on-premises Citrix Virtual Apps and Desktops (CVAD) deployment and would like to move to a cloud setup. The reason for this varies per customer. At the start of a new project, we talk about customer requirements. The topics covered most are authentication, security, and application compatibility. When using Citrix Cloud, it is essential to make it clear which IdP to choose at the start of the project because we get more and more authentication options than on-premises when implementing a CVAD environment.

Scenario’s and requirements

Below I describe some scenario’s

  1. Double hop
    There are many customers that use published apps that start from another VM within their published desktop (called a double hop), and there are numerous reasons:
    1. The app is for archive only;
    2. The app doesn’t support the same OS as the desktop;
    3. The app conflicts with other apps;
    4. The app can only be used by some users, and licenses don’t allow us to install it on the same image as the desktop.

      In the case of a double hop scenario, you need an on-premises StoreFront, which means you still need to manage the StoreFront server and keeping it up to date. To configure a double hop with an on-premises storefront take a look here.
  2. Federated Authentication Service (FAS)
    When choosing AAD, Okta, or SAML for your CVAD requires a FAS server (or two for redundancy). FAS uses certificates to sign in to the VDA’s. To use FAS requires a Microsoft Certificate Authority. To make this secure, you have to install it with an offline root CA and an online issuing CA.
  3. SSO to Saas or enterprise web apps limitations
    When choosing AAD, Okta, or SAML with Citrix Gateway services, you could not use all SSO solutions to your SaaS apps. Basic and form-based SSO will not work. This is because when you authenticate, your credentials (username and password) aren’t cached in a hash on the gateway services. Only the authentication token is sent to the Gateway, and thus basic, and form-based SSO can’t get the credentials.   https://docs.citrix.com/en-us/citrix-gateway-service/support-web-apps.html
  4. Second public domain needed for Azure federation
    When choosing AAD, the primary domain is used for authentication to Citrix Cloud. You can’t use the same domain for federation to Azure for SaaS apps. This mostly isn’t a problem because most companies have multiple public domains, but you need to think of it. See: https://docs.citrix.com/en-us/citrix-gateway-service/saas-apps-templates/citrix-gateway-o365-saas.html#authentication-methods-supported-for-office365
  5. Password change not supported within Citrix Cloud
    When choosing AAD, Okta, or SAML, you can’t use the default option to let users change their password, and you need to configure this on the chosen IdP. This won’t stop your project, but you need to keep this in mind.
  6. Existing MFA provider
    When you need to support an existing MFA provider (RSA, Gemalto, etc.), you can get this to work with an on-premises setup only or with Okta.
  7. No support for authentication to Office 365
    When you need to authenticate your Office 365 applications from the Citrix Gateway services, this isn’t supported for Okta and SAML.

Identity Providers

Looking at the available IdP’s, Citrix Cloud currently support the following:

  1. Active Directory
  2. Active Directory + token
  3. Azure Active Directory (AAD)
  4. Citrix Gateway (on-premises)
  5. Okta
  6. SAML 2.0

I explain all the IdP’s one by one and give some pros and cons I experienced during my last projects.

On-premises AD with or without token

I combine options 1 & 2 because the main functionality is the same. The only difference is a token code that gives some extra security.

Using your on-premises AD (with a token) is the easiest setup. You only need to add two cloud connectors, and you’re good to go. You can use all the services without any additional requirements. In the case of Citrix Gateway SSO, this enables you to also use form-based authentication with on-premises SaaS apps.


  1. Easy setup
  2. No additional requirements
  3. Free MFA
  4. SSO with form-based authentication
  5. Allows password Changes


  1. When using this token, users need to replace their current MFA or need another MFA solution.

Azure Active Directory (AAD)

As more and more companies are using Azure AD, as needed when using Microsoft 365, Microsoft keeps adding features to the suite. One of those features is Azure MFA, where you can use conditional access (with the appropriate license). With conditional access, it’s possible to give users the option to only sign in with username and password from trusted locations (think about HQ and branch offices).


  1. You can use your existing Azure MFA for Citrix
  2. You don’t need additional MFA products
  3. Conditional access
  4. Users can sign in with there same username and password as AD


  1. FAS server required
  2. Double hop only with on-premises StoreFront
  3. SSO to SaaS or enterprise web apps limitations
  4. Second public domain needed for Azure federation
  5. Password change not supported with Citrix Cloud
  6. Can’t use existing MFA solution

Citrix Gateway (on-premises)

When you have a Citrix Gateway (f.k.a. NetScaler Gateway), you could use that to manage the authentication to your on-premises domain. Using the Gateway gives you more flexibility to the way users are going to sign in.  When looking at MFA, the on-premises Gateway gives you the possibility to use your current MFA solution, like Gemalto, RSA, or Azure MFA. The downside is that you will need to maintain an on-premises gateway. And because that is your point of entry to your environment, you need to keep it very secure.


  1. More flexibility in authentication providers with or without MFA
    When using MFA, make sure the LDAP password is the default password (https://docs.citrix.com/en-us/citrix-cloud/citrix-cloud-management/identity-access-management/connect-ad-gateway.html#troubleshooting)
  2. Keep using load balancing
    When using an on-premises gateway, you could leverage all the functionality of the appliance. This gives you the option to use it for load balancing features


  1. More costs and management you need to manage, update, and buy support for the appliance. Which will cost you more than using the Gateway Services  managed and updated by Citrix
  2. Password change not supported with Citrix Cloud
  3. Double hop only with on-premises StoreFront



  1. Use existing MFA solutions (if supported)
  2. Use Okta as your IdP for multiple scenarios


  1. No support for authentication to Office 365
  2. FAS server required
  3. Double hop only with on-premises StoreFront
  4. SSO to SaaS or enterprise web apps limitations
  5. Password change not supported with Citrix Cloud

Security Assertion Markup Language (SAML)

SAML is currently in technical preview. SAML 2.0 is now generally available. All pros and cons are based on information that Citrix provides in its documentation. Take a look at the Citrix blog for more info.


  1. Use the same SAML setup for more partner/app integrations


  1. No support for authentication to Office 365
  2. FAS server required
  3. Double hop only with on-premises StoreFront
  4. SSO to SaaS or enterprise web apps limitations
  5. Password change not supported with Citrix Cloud

Looking at all these pros and cons could make it hard to choose the right Identity provider. I hope this article is a good starting point and makes a choice easier so you won’t have the same issues I had during my latest projects.
Would you please let me know if you have some pros and cons I have forgotten to mention or need some additional information?