We are experiencing performance issues with Netscaler 14.1.66.59 with Netscaler Gateway with EDT. We've discovered that users connecting via the Citrix Gateway Service have a lower MTU size compared to users via Netscaler Gateway that uses the default size of 1500. Anyone has any experience in setting the right MTU manually or configuring the PMTUD discovery?

The reason you are seeing a lower MTU (typically 1380) through the Citrix Gateway Service is by design. When EDT MTU Discovery fails or isn't supported by the client endpoint, the Gateway Service automatically drops the MTU to 1380 to prevent packet fragmentation. Your on-premises NetScaler Gateway is likely defaulting to 1500. On complex network paths (like VPNs, 4G/5G, or asymmetric routes), an MTU of 1500 causes UDP packet fragmentation, which translates directly to the performance degradation and session failures you are experiencing.  To resolve this on your 14.1, you have two paths: optimizing PMTUD or hardcoding the MSS/MTU. Source: https://docs.citrix.com/en-us/citrix-gateway-service/hdx-edt-support-for-gateway-service.html#edt-mtu-discovery

Thanks Arthur. I'll look into it.

This is a classic PMTUD black hole. Type 3 Code 4 is the only signal that tells the sender to lower its MTU, so without it the Gateway keeps emitting at 1500, oversized EDT packets are silently dropped, and since UDP has no retransmit the loss stays invisible and the step down to ~1380 never happens. The Gateway Service path is not the problem: it starts from a conservative MTU, which is why it does not black-hole. It is the on-prem path that optimistically starts at 1500 and never learns to reduce. For the firewall change: scope the rule to Type 3 Code 4 inbound to the SNIP/VIP, not all ICMP. You cannot source-filter it, since the message is generated by an arbitrary router along the path, so use a rate-limit instead. If you have IPv6/DS-Lite, also allow ICMPv6 Type 2. After deploying, verify with

ctxsession.exe -v

on a VDA behind the on-prem Gateway: the EDT MTU should settle at the real path value and the loss counters should stop climbing.

Just a note to add: Rendezvous is also working fine (and supported, too) without EDT, just TCP