Together, Citrix Workspace and Gateway service provide a convenient and secure remote access solution for Citrix DaaS resources. And they’re delivered as a service via Citrix Cloud! Customers don’t have to maintain access layer infrastructure, time to deploy is compressed, there’s inherent multi-datacenter resiliency, and much more.
That all sounds great. And you just have to flip a switch and you’re good to go, right? Mostly yes, but there are a few things you should think about before you flip that switch.
In this blog post, I’ll cover some key design considerations around deploying a Citrix Cloud-hosted access tier. For a full list of design considerations, please check out our product documentation for Citrix Workspace and Gateway service.
Design Consideration #1: Does Workspace make sense for your use case?
Certain use cases have dependencies that require Citrix Workspace (or StoreFront). For example, Azure AD-joined VDAs and non-domain-joined VDAs require Workspace and Gateway service, as does HDX Plus for Windows 365. However, Workspace doesn’t support connections from legacy clients that use a XenApp Services (formerly known as PNAgent) URL or advanced webpage modifications. In this case, you need StoreFront.
In addition to determining whether Workspace or StoreFront suits you best, you must also determine for each use case whether service continuity is sufficient as a resiliency feature (allowing the use of Workspace) or whether Local Host Cache (LHC) is required (which requires StoreFront). For the purposes of this blog post, I will assume the reader is familiar with both features.
While service continuity does not require customer-managed StoreFront servers, there are several design considerations to keep in mind. I have summarized them below but check out our product documentation for the complete list. First, let’s look at scenarios that aren’t currently supported:
- Thin clients. We’re working to address this, but this will also require vendor-side modifications to allow access to writable storage (and specific locations therein).
- Site aggregation in Workspace with customer-managed Citrix Virtual Apps and Desktops deployments.
- Customer-managed NetScaler Gateways being used for ICA proxy (using Gateway as the identity provider for Workspace is still supported).
- Adaptive authentication.
- Single sign-on (including single sign-on with FAS). Users will need to enter their AD credentials on the VDA to gain access.
- Endpoint Analysis (EPA).
- Kiosk devices, as connection leases are only supported for one user per device.
Additionally, the following features aren’t supported during an outage:
- VDAs which are assigned on first use
- Enlightened Data Transport (EDT)
- Citrix resources that are secured with app protection
- Direct Workload Connection (DWC)
Finally, the following considerations should be kept in mind:
- There are minimum Citrix Workspace app and VDA version requirements. Refer to our product documentation.
- For a connection lease to be created, the user must sign in at least once. Additionally, the default behavior is to delete connection leases when users sign out of Workspace during an outage (but this can be changed by using the PowerShell commands, as documented here).
- Connection lease duration can be configured to allow access for up to 30 days. The customer security team will usually be the determining factor in setting this.
- VDAs must be joined to an AD domain.
- Access via a web browser requires a browser extension on a supported browser, which could be challenging for deploying to BYO/unmanaged devices. Again, refer to our product documentation.
Review your requirements and figure out if service continuity is right for you. If you require LHC and/or are affected by the above, please note that Gateway service does not support LHC, and you will need to deploy customer-managed StoreFront and Gateway. Make sure to gather your requirements carefully and design accordingly. And remember, you can always deploy both a Citrix Cloud-hosted access tier and a customer-managed access tier!
Design Consideration #2: Is your network ready?
When using Gateway service, the default session launch behavior is for the HDX/ICA traffic to be routed from the endpoint device to Cloud Connectors to the VDA. But as you might suspect, this is a bottleneck and doesn’t scale well.
To remove the dependency on routing via the Cloud Connectors, Citrix created Rendezvous protocols v1 and v2. While Citrix Consulting recommends Rendezvous protocol to simplify the launch process and reduce the load on Cloud Connectors, customers also should consider the firewalls, proxy servers, and any packet inspection devices they use.
With both Rendezvous versions, all VDAs must be able to communicate with the necessary Citrix Cloud URLs. Certain security-conscious customers might require individual firewall rule exceptions to be made for each VDA, which does not scale well. Other customers might simply prefer the ease of managing firewall rules for a handful of Cloud Connectors rather than VDAs. Regardless, don’t overlook these operational considerations. Moreover, please note that packet decryption/inspection is not supported with Gateway service and exceptions must be made for it to function properly.
A second consideration pertains to Zscaler Private Access (or similar solutions). If in use, we recommend bypassing the Gateway service’s required URLs to avoid increased session latency and the corresponding performance impact.
Design Consideration #3: Does it make sense to use Direct Workload Connection?
Direct Workload Connection (DWC) allows internal users to bypass Gateway service and connect to VDAs directly, reducing latency. While this has its benefits, customers must first determine the public IP ranges of the networks their internal users will connect from, such as their office or branch locations. Citrix Cloud then uses these ranges to determine whether a launch is internal or external.
For small customers with a limited number of locations, this might not seem like a big ask. But for large multinational customers with potentially hundreds of offices, this can be a daunting task. And don’t forget, if the customer has firewalls separating internal network segments, firewall rules might also need to be updated (see Design Consideration #2).
A related consideration is to make sure that corporate and guest Wi-Fi networks have separate public IP addresses. Because this feature assumes that users have a direct network path to the VDAs, using the same shared public IP address for these networks will result in Citrix Cloud incorrectly assuming users on the guest Wi-Fi have a direct network path to the VDAs, resulting in failure to launch.
One final consideration: When service continuity is enabled, DWC is not available during outages. Plan accordingly!
Design Consideration #4: Are users going to connect to the optimal Gateway service point-of-presence?
Gateway service uses the endpoint device’s DNS server to determine the closest Gateway service point-of-presence (PoP). While this generally works well, in some scenarios the endpoint device is configured to use a remote DNS server. For example, offshore clients might be configured to use a DNS server in North America because they are using devices supplied by a North American company. Gateway service routes the offshore user via the internet to a North American PoP, adding session latency.
Customers should review their endpoint device DNS configuration where possible and factor it in when troubleshooting session latency. Using technologies such as a VPN could also cause routing to an unexpected PoP. Our friends at Ferroque Systems have a great blog post that covers this issue.
Design Consideration #5: How can I optimize audio traffic when using Gateway Service?
The best way to optimize audio traffic with Gateway service is to use the respective vendor’s optimization technology (we cover that here and here). When audio/video traffic is optimized, Citrix DaaS renders the content on the endpoint and sends related traffic directly from the endpoint rather than through the HDX/ICA session to improve performance.
When this optimization isn’t possible and audio must be sent over the HDX/ICA session, customer-managed access tiers may use policies such as Audio over UDP to separate and prioritize audio traffic to improve performance. However, Gateway service does not support Audio over UDP. So, what should we do?
First, use adaptive audio (enabled by default and requires Citrix Workspace app/VDA 2109+), which dynamically adjusts audio policy settings and replaces legacy audio compression formats to optimize the user experience.
The next thing you should do is test using Enlightened Data Transport (EDT) — Citrix’s proprietary UDP-based protocol — to deliver the entire HDX/ICA session, which could offer improved performance. Please note that this feature is only available when using Rendezvous protocol (see Design Consideration #2), and due to OS MTU limitations this feature is only recommended on Windows 10+ and Windows Server 2019 +.
Finally, if using Gateway service without Rendezvous, the significant increase in bandwidth utilization due to unoptimized audio traffic can drastically affect the scalability of Cloud Connectors, requiring more Cloud Connectors to be able to proxy all sessions.
Ultimately, unoptimized audio traffic should only be used as a last resort. And it goes without saying that all audio solutions should be thoroughly tested before you deploy at scale.
Design Consideration #6: Does my customer need to analyze sources of network latency?
Many customers currently use Application Delivery Management (ADM) or ADM service with customer-managed NetScalers to gather HDX Insight data that enable them to troubleshoot user latency. Gateway service does not integrate with ADM service, though Citrix Analytics for Performance provides the following Gateway service metrics: connector names, PoPs, and connector performance information. These Gateway service metrics, when paired with Citrix Analytics for Performance’s endpoint network metrics (bandwidth, round-trip time, latency, and Wi-Fi signal strength), can assist in troubleshooting sources of network latency. If a customer absolutely requires HDX Insight data, you can integrate ADM service with Citrix Analytics for Performance. Please note that Citrix Analytics for Performance is sold separately.
Weigh this operational consideration before recommending a move from customer-managed NetScalers to Gateway service. For some customers, having access to NetScaler-provided HDX Insight data in ADM service and Citrix Analytics for Performance outweighs the gains from a Citrix Cloud-managed access tier.
Conclusion
A Citrix Cloud-hosted access tier can be a terrific way to simplify deployments by removing the need to maintain access layer infrastructure, provide inherent multi-datacenter resiliency, and achieve faster deployments. You just need to make sure you think things through — or hire the smart people at Citrix Consulting Services to do it for you. 😊
Get started with Citrix Workspace and Gateway service today!
(Credit to my colleagues Johan Rios, Harold Winne, and Brandon Coto for providing a blueprint for these design considerations.)