Issue and Background
Citrix Gateway service is a SaaS solution part of numerous Citrix Cloud offerings to provide secure remote access to resources within a customer’s private network. It is often associated with Citrix DaaS (formerly Citrix Apps and Desktops service) and is often used in conjunction with Citrix Workspace service for customers who wish (and are able) to transition from their on-premises Citrix access tier (StoreFront, Citrix ADCs) to a Citrix-hosted cloud service. In the case of Citrix DaaS, it serves as an HDX proxy solution alternative to customers operating their own Citrix Gateways on customer-managed ADCs.
In the field, we find many large enterprise customers remain with customer-managed Citrix Gateways for one or more various reasons and find organizations in the low thousands of users or less more inclined to consider Citrix Gateway service. With that in mind, depending on use cases we have seen the opposite as well including large financial organizations designing and/or deploying Citrix Gateway service. Some customers can use a mixture of both with the flexibility of assigning the HDX/ICA proxy method in the Resource Location within the Workspace service considerations. The Citrix Gateway service is architected with numerous points of presence (POPs) around the globe to allow HDX traffic to route through the most optimal pathway for the user into their Citrix sessions using some of Citrix’s Optimal HDX (formerly Gateway) Routing architecture.
One issue we have come up against on occasion is customers who find some of their user sessions are not performing well (while other users may work fine going to the same Resource Location and Citrix resource type). Being often last mile issues there may be many reasons for this such as poor Internet link quality, etc. In some other scenarios, the issue is a little less clear.
Potential Root Cause and Resolution
In several occasions, we’ve narrowed down the problem to one issue: DNS (it’s always DNS at some point, isn’t it?). Citrix Gateway service relies as a component of decision-making on DNS response time (RTT) to determine the proximity of the user to the nearest Citrix POP. As with many DNS-based proximity-determining solutions such as F5 GTM or Citrix GSLB, this means the user’s local DNS (LDNS) becomes a key point in determining the user’s location in relation to the Citrix POPs. And when there’s misalignment this can impact session performance.
Take for instance a user whose endpoint is set up to use an alternate DNS server, versus their ISP’s DNS and can result in Gateway service sending the user through a far away POP that results in much higher latency. We have also seen this with offshore users whose endpoints were configured to route through DNS services in North America resulting in a poor experience.
I will note that the Citrix Gateway Service is supported by Citrix’s Intelligent Traffic Management (ITM) infrastructure and it does in fact support EDNS0 according to the engineers. EDNS0 (which we’ve discussed before) is a useful way to overcome LDNS/RTT issues that might otherwise mask the true location of a user’s endpoint in relation to the most appropriate POP. Not all DNS servers may be configured to support the EDNS/ECS extensions however. And some popular DNS services such as Google’s 8.8.8.8 (from a performance/security perspective I prefer 9.9.9.9) do in fact state they support EDNS. Azure Traffic Manager also claims to support it as well. Other DNS services such as Cloudflare (1.1.1.1) may not. Regardless, I would discourage ruling out a client’s DNS servers as a contributor (either set on their endpoint, their home router or even forced down via a VPN client including the likes of ZScaler).
On several occasions, including recently as of this past week (July 4th) we’ve had users experience a performance issue with Gateway service which immediately resolved for both performance and ICA RTT latency (as per Director, Citrix Quality Indicator, etc.) when the user reverted to their ISP’s DNS servers. If some of your users are experiencing slowness and high latency in Citrix and running via the Citrix Gateway service remotely, we suggest adding the DNS config check of the user endpoint to the “last mile configuration check” on your service desk’s checklists as you may very well find it’s a large contributor.
