Intermittent Disconnects Through Citrix ADC in Azure
Adventure Works publishes 2,200 remote users through two Citrix ADC VPX instances in a single Azure VNet. The ADCs are deployed one per availability zone, sit in the same subnet, and are fronted by a public Standard SKU Azure Load Balancer with a TCP health probe; the pair is also configured in HA mode. The load balancer was deployed with default settings and no keepalive tuning. Home broadband users report sessions freezing and reconnecting roughly every four minutes when they pause typing, and retrying usually works. At the 08:30 ramp a subset of users see 'Cannot connect to desktop' for a few minutes and then succeed on retry. ADC logs show the Gateway virtual server healthy throughout, with SNAT enabled and 1,100 simultaneous sessions during the ramp.
1. Diagnose the four-minute reconnect pattern and state the fix, naming the specific mechanism.
Read the worked answer
Diagnosis. A disconnect at a regular interval that matches user idle time points to an idle flow timeout being enforced in the path, not to an authentication or certificate problem. The Azure Load Balancer keeps a default idle timeout of four minutes for flows it fronts; when the HDX session has no traffic, the load balancer silently drops the mapping. The ADC still reports the Gateway virtual server healthy because the virtual server is fine - the flow no longer traverses a valid path. Retrying works because a fresh flow is created.
Fixes, in order
- Raise the load balancer idle timeout towards its maximum (30 minutes) on the rule that fronts the Gateway. This alone usually moves the symptom from four minutes to thirty, which is not a cure.
- Enable keepalives so the flow is never idle: TCP keepalive on the ADC service and on the client, and HDX keep-alive on the session. For Citrix Gateway, connection keep-alive to the VDA is also worth setting if the drop correlates with idle inside the session.
- Note the trade-off: a long idle timeout holds entries for abandoned flows. A short timeout with keepalives is generally better than a long timeout with none.
Why not just tell users to move the mouse: the interval is a network property, and it will affect any task where the user pauses - reading a chart, filling a form, waiting on a batch job. Fix it in the path.
2. What explains the 08:30 'Cannot connect to desktop' failures that succeed on retry, and how do you confirm and fix it?
Read the worked answer
Leading hypothesis: SNAT port exhaustion on the ADC. With SNAT enabled, each client-to-VDA session consumes a source port as the ADC proxies to the back end. At 1,100 simultaneous sessions during a short ramp, the reusable port pool per destination IP can be depleted, so new connections fail until existing ones are reclaimed by time wait or reuse. Retry succeeding a few minutes later is the signature: the pool refilled.
Confirmation
- Take ADC counters for SNAT port allocation during the ramp window and compare against the configured pool per destination address.
- Sweep ADC and back-end logs for the same window; look for the connection failure reason rather than the user-facing message.
- Check whether failures cluster on users routed to one back-end subnet, which points at a per-destination limit rather than a global one.
Fixes
- Add source IP addresses for SNAT so the port pool is multiplied, and shorten port reuse timeouts where the platform allows it.
- If the design permits it, avoid SNAT where source IP preservation is possible, and re-validate that the Azure load balancer and the VDA subnet both tolerate it.
- Reduce the number of proxied connections per user session; some HDX and authentication flows create more connections than teams expect.
Do not simply add a second public IP to the Azure load balancer and declare victory - that may move the limit without confirming it was the limit. Measure first.
3. Critique the HA and zone design: one ADC per zone, both in the same subnet, fronted by an Azure Standard Load Balancer. What would you change and why?
Read the worked answer
What is sound: a Standard SKU load balancer is zone redundant, so a zone failure does not remove the front door, and one ADC per zone gives you an instance on each side of the failure. That is a reasonable starting shape.
What is fragile
- Both ADCs in the same subnet means a subnet-level change - an NSG edit, a route change, a UDR applied for a security review - affects both at once. The redundancy is zonal but not change-domain. Separate subnets do not fix everything, but they make accidental blast radius smaller.
- An active-passive HA pair across zones depends on the load balancer health probe and on the pair's own failover behaviour. If the probe is a bare TCP check against a port that stays open while the node is functionally degraded, the load balancer keeps sending users to a node that cannot serve them. Use an application-aware probe against a real HTTPS path.
- HA across zones introduces a subtlety regarding client IP preservation: features that depend on seeing the true client address may not work the same way behind the load balancer. Verify the specific deployment pattern in the current Citrix ADC on Azure guide rather than assuming a classic on-premises HA design carries over.
Alternative worth evaluating: two standalone ADCs, one per zone, each with its own public IP and published through DNS with health-checked name resolution (or a global load balancer). This removes the cross-zone state-sharing question entirely and makes each node independently replaceable, at the cost of managing two public endpoints.
Recommendation: keep zone redundancy, separate the subnets, upgrade the probe to an application-layer check, and document which failure each layer actually covers.