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 Google’s 126.96.36.199 or Quad9’s 188.8.131.52 (IMHO a more secure, performant option), versus their ISP’s DNS. This will mask the user’s location to an extent as recursive DNS is often in use across DNS infrastructure (there are some ways around this with EDNS but we won’t get into that here, and not aware of the Gateway service presently employing it) 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 terrible experience.
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.