Jump to content
Welcome to our new Citrix community!

Content Switching multiple ICA Proxy Gateways using 2x VPX in series: desktop does not launch

Recommended Posts

Hello all,

We have a configuration as follows:

Client -> Internet -> Public IP on firewall, destination NAT to private CS VIP on 1st Netscaler -> CS SSL VIP checking HTTP.REQ.HOSTNAME for a match --> If match: forward to unnumbered SSL LB VIP on same Netscaler --> SSL LB forwards to a single private IP on next Netscaler which is a ICA Proxy VPN vServer. There are multiple ICA Proxy VPN vServers configured on the 2nd Netscaler.


We do get to see the login page of the ICA Proxy VPN vServer on the 2nd Netscaler (in series with the 1st Netscaler) and are able to login. Storefront shows up with shortcut to desktop.
When trying to launch the desktop, nothing happens...


I could see that EDT is used first (UDP traffic hitting the 1st Netscaler on the outside private VIP) but no traffic is forwarded to the 2nd Netscaler. Even if fallback to TCP occurs, no traffic send to the 2nd Netscaler. 


Does anyone have experience with a similar setup?


The endgoal is to have this also working with HDX/EDT, but I can imagine the Content Switch vServer will not be able to handle the UDP/EDT traffic.


We are running firmware NetScaler NS12.1: Build 50.28.nc, Date: Nov 28 2018, 01:54:26   (64-bit), platinum license.


I  have attached a picture of the situation (I left out the Citrix backend systems on the right side of the drawing like StoreFront, DDC, VDA)


If we completely bypass the 1st Content Switching Netscaler, it works so the integration with Citrix Backend is correct on the 2nd Netscaler.


Link to comment
Share on other sites

Unfortunately, content switching is only intended to frontend a single vpn vserver and not multiples.  Your config is obviously more complicated than that.

Partly it has to do with the way the vpn url is identified as eq to "/" so there isn't a way to distinguish multiples from each other.


Now, you are trying to use CS to sort to a LB vservers as proxies fro the next tier gateway. If this might work, your LB vservers would have to be ssl bridge mode and not SSL termination; but again, that probably won't work with content switching.  The problem you have is that you can't have ssl termination at the LB vserver in the middle of the gateway flow.


I think you're trying to solve a couple of issues at once: 1 public VIP, a double-hop DMZ, and continued use of EDT.  But I'm not sure there's going to be a way to get all three things.


First a Gateway in a  Double-hop DMZ config generally requires you to have two NSG's in a specific configuration:

1) External facing gateway (VPN vserver) hosts the vpn vserver with all the authentication/session policies/sta's.  Authentication is enabled, double-hop is off and VPN2 is designated as the next hop gateway server.  This outer facing gateway does the actual authentication and communication to storefront normally; but the it forwards sta requests and all VDA (hdx) communication in SSL to the second hop gateway.

2) Internal facing gateway (VPN2 vserver on 2nd netscaler), is configured with authentication off and double-hop ON.   This gateway receives the encrypted STA and VDA communication and proxies it to the actual destinations.


This allows limited port crossings between components in the first and second dmz's while maintaining the proper encryption and traffic flow.  However, it does not support full vpn capabilities or EDT; traffic is limited to TCP only.


Second:  If you want to lb a vpn vserver, typically the front NS can't termnate the traffic as the gateway needs to see this, so if a lb tier runs in front of the gateway, it is most likely in ssl_bridge mode.


Finally, your trying to use content switching presumably to reduce public IPs and then you are using the LB tiers to try to circumvent the fact that CS won't let you put multiple gateways behind one cs vserver AND to help your double hop dmz without doing an actual double hop gateway config.





Link to comment
Share on other sites

  • 3 weeks later...

Hello all,


Thanks Rhonda for the extensive reply. You are right that there are too many requirements which we cannot meet all.


We have decided to make use of URL responder policy and use gateway on separate port to solve the challenge for now without the need to inform endusers about the usage of a specific port.





Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...