NetScaler Gateway: ICA Launch Failures with Upstream WAF/CDN

book

Article ID: CTX696180

calendar_today

Updated On:

Description

In a Citrix Virtual Apps and Desktops (CVAD) environment using NetScaler Gateway ICA Proxy, you may encounter session launch failures when a Web Application Firewall (WAF) or Content Delivery Network (CDN) is deployed in front of the NetScaler Gateway. 
Note: "WAF" is used throughout the remainder of this document as a general term; these concepts apply identically to CDN environments as well. 

The NetScaler Gateway Virtual IP (VIP) uses Port 443 to handle two types of traffic:

  • HTTPS: For Authentication and App/Desktop enumeration (browsing the StoreFront store).
  • ICA over TLS: For App/Desktop launch. HDX flow.

But most WAF are designed for standard web traffic (HTTP/HTTPS) only, they cannot understand the ICA protocol. When the Citrix Workspace app (CWA) attempts to establish the ICA connection through the WAF to the NetScaler Gateway, the WAF may flag the traffic as non-standard and block it. Depending on the specific behavior of the WAF, users may observe different symptoms on CWA, including: Timeout, error code 2095.10054, etc. 

image.png

Cause

WAF cannot inspect ICA protocol and blocks the traffic. 

Resolution

There are three ways to resolve this issue. They are presented below in order from the simplest to the most complex configuration.

 

Solution 1: Enable "Bypass Non-Standard HTTPS Traffic" on WAF.

Some WAF may have this feature, because WAF is designed for HTTP/HTTPS protocol only. For non-HTTP[S] traffic, there is no need for it to inspect them. So, contact your WAF vendor for this. 

 

Solution 2: Assign a new non-443 port to ICA traffic. 

If your WAF doesn't have the setting. You can resolve the issue by separating the two protocols' traffic into different ports. This ensures that only standard HTTPS traffic (Authentication/Enumeration) passes through the WAF, while the ICA traffic bypasses it entirely. Use 9443 port for ICA as an example.

  • HTTPS(VIP:443): Go through WAF.
  • ICA over TLS(VIP:9443): Bypass WAF. 

image.png

1. To bypass the WAF for ICA traffic, you must create a direct path through your edge firewall or router. Open TCP port 9443 on your external firewall. And configure a NAT/Port Forwarding rule to route traffic from the public IP:9443 directly to the NetScaler Gateway VIP:9443. This ensures ICA traffic avoids the WAF entirely.

2. On NetScaler, create a new Gateway Virtual Server specifically on port 9443. Bind a valid SSL Certificate to bring the vServer "UP". Bind the same STA servers used by your primary Gateway to ensure the ICA launch tickets can be validated.

3. On StoreFront, in the StoreFront Management Console, click Manage Citrix Gateways. Update the Citrix Gateway URL (FQDN) to include the new port suffix (e.g., https://gateway.company.com:9443).

4. Security Hardening (Optional but Recommended). Since this new 9443 vServer is exposed to the Internet, it could be discovered by port scanners. To minimize the attack surface, you can restrict the vServer to ICA traffic only.

add responder policy Reject_all_HTTPS HTTP.REQ.IS_VALID RESET
bind vpn vserver Your_9443_vS -policy Reject_all_HTTPS -priority 100 -gotoPriorityExpression END -type REQUEST
bind vpn vserver Your_9443_vS -policy Reject_all_HTTPS -priority 100 -gotoPriorityExpression END -type AAA_REQUEST

 

Solution 3: Implement Optimal HDX Routing.

If your organization’s security policy prohibits opening non-standard ports (like 9443) on the edge firewall, you can use Optimal HDX Routing. This method separates traffic using two different FQDNs instead of different ports.

  • FQDN_Authn: HTTPS protocol, used for authentication and desktop/application enumeration. Go through WAF.
  • FQDN_ICA: ICA over TLS protocol, used for desktop/application launch. Bypass WAF. 

image.png

You have to add a new public DNS A record for ICA_FQDN. If your edge Firewall/NAT device supports SNI-based routing (inspecting the `CLIENT_HELLO`), you can use one public IP and route traffic to the appropriate backend based on the hostname. Otherwise, you have to assign a second public IP address.

On NetScaler, Install a SAN Certificate that includes both FQDNs. Bind this to both Gateway vServers. And on the Gw_ICA vServer, also bind STA servers. Since this vServer only handles the ICA traffic, you do not need to bind authentication policies or session policies here.

On StoreFront. You have to configure Optimal HDX Routing. The following is an example. 

1. Create 2 gateways on StoreFront: 
a. Gateway for FQDN_Authn: 
image.png
b. Gateway for FQDN_ICA:
image.png

2. Select the Store, click Configure Remote Access Setting. Enable remote access and select the gateway you created in step 1.a.
image.png

3. Select the Store, click Configure Store Settings > Optimal HDX Routing. Select the gateway you created in step 1.b. Click Manager Delivery Controllers. Select the DDCs for the Store. 
Note: Manage Zones can be checked too if you have Zones set in DDC. 
image.png

Lastly, same as Solution 2. For security purpose, you can block all HTTPS traffic on the second ICA gateway vServer on NetScaler. 

add responder policy Reject_all_HTTPS HTTP.REQ.IS_VALID RESET
bind vpn vserver Your_Gw_ICA_vS -policy Reject_all_HTTPS -priority 100 -gotoPriorityExpression END -type REQUEST
bind vpn vserver Your_Gw_ICA_vS -policy Reject_all_HTTPS -priority 100 -gotoPriorityExpression END -type AAA_REQUEST

Issue/Introduction

This article introduces a typical issue when NetScaler Gateway vServer is integrated with WAF/CDN

Powered by Wolken Software