Netscaler vs VPN

[Muddasir Mughal]

Are their any articles that can explain the advantages, disadvantages of using Citrix over a VPN connection vs going through a Netscaler for Citrix?

[Rhonda Rowland1709152125]

I don't know about an article, but I can sum up for you. (Apologies for the excessive parentheticals to show both old and new names...it kind of got away from me:)

 

If you use the Citrix Gateway (NetScaler Gateway) in HDX Proxy mode to connect to a Citrix Virtual Apps/Desktops (aka XenDesktop) environment, then the benefits are:

• You provide a secure remote external access solution to Citrix-based Resources (apps/desktops) and potentially other Web/SAAS apps ONLY.  
• User devices only requires a Workspace App (former Citrix Receiver). And therefore almost all device types are supported.
• During the connection process users only ever communicate to the Gateway (vpn vserver FQDN) over SSL (or DTLS). And no internal names/ips are exposed client side.

Bottom line: the HDX Proxy connection allows you to get a wide range of users access to Citrix-based (and a few other resources) without needing vpn clients, vpn tunnels or having to worry about what else they can or can't connect to on the environment. So you avoid a lot of the considerations of a full vpn.

 

If you use decide to access the Citrix Virtual Apps/Desktops via a VPN (either the NS Gateway in full VPN mode or a separate 3rd party VPN solution), you can do this but now you have to deal with VPN considerations:

• One: clients will require a VPN client to make a full vpn connection. Depending on solution, you now need to know if you have a vpn client for all required devices types (hint: mobile is sometimes fun here.)
• Two:  The VPN therefore has the ability to connect the users to Citrix-based and other non-Citrix based resources, unless the vpn connection is restricted. So you have more potential to expose more parts of the environment or application access than you may have intended than in the ICA Proxy scenario. Example: users can run a local outlook client to connect to exchange via the vpn tunnel or RDP/SSH to something if not restricted.
  • As a result, the vpn config must identify split tunnel requirements to be on or off and networks to intercept.
  • VPN admins spend more time identifying the  networks/ports to allow or deny over the vpn tunnel than we have to do in the HDX Proxy configuration.
• Because the VPN connection basically extends the user onto the internal network, while the client-side communication is only from client to vpn over SSL, the user is still referencing internal resources names externally (via the tunnel) such as the internal storefront FQDN and every destination VDA.

That's kind of a quick-ish summary without the accompanying diagram.

 

Additional considerations:

In HDX Proxy, you know the user is constrained to only accessing certain type of resources AND the vpn side of the config doesn't have to be as controlled, because in HDX Proxy mode it is only allowing the citrix CVAD-dependent communication only.

Externally, users only communicate to the Gateway FQDN and access the Gateway (vpn) VIP over SSL/DTLS.  Only the Gateway will connect and reference Domain Controllers, SToreFront, the STA's, and the VDA destinations. But none of these names are ever communicated publically to the client. So I view it as less surface area exposure of your internal network to the outside world. Its limited function subset of the vpn capabilities.

** Also, this model will support the EDT protocol.

 

If you wanted to enable access to CVAD/XenDesktop resources via a VPN you can, but to the STorefront/CVAD environment it would *look* like an internal connection and not an HDX Proxy connection. But the user side would be tunnelled by the VPN.

So the client would need access via the VPN to the storefront fqdn/ips and all destination VDA's.   While the client to vpn communication would be to the vpn vip only over SSL; the internal names would be used by the client, resolved by dns via the VPN, and then the vpn would have to reach all these destinations.

And then the users could potentially use the same vpn connection to access other internal resources too.

** In this case, if your SSLVPN solution can't also handle DTLS (UDP) traffic, than you won't get to use the EDT protocol for your connections either.

 

So, bottom line, if your goal is to only do remote access to Citrix Stuff with minimal security considerations, then the GAteway/HDX Proxy config is probably best.

If you already have a vpn solution AND you require remote users to do Citrix and a large volume of NON-Citrix stuff, you have two options:  1) use Gateway for HDX Proxy for the Citrix stuff and the VPN for the non-citrix stuff or 2) you could use the vpn for everything.  Just there are still a lot of factors where the HDX Proxy is preferred.

 

 

[Muddasir Mughal]

Thank for for your quick response and detailed information Rhonda. Would you know if there are any performance advantages or disadvantages with going over Netscaler vs 3rd party VPN? We have an application that we publish over Citrix on XenApp 7.15 and certain sites who go through Netscaler for external access and some who are going through 3rd party VPN and then accessing storefront and launching that application that way.

[Rhonda Rowland1709152125]

There's not supposed to be a significant impact in either variance....there is a chance that your missing out on some protocol awareness in the vpn scenario, but since the gateway isn't actively doing anything to the ICA stream beyond wrapping it in SSL, this would be unlikely. But I'll let an engineer weigh in if they think it would be a consideration. The biggest thing is probably you wont get to use the DTLS/EDT protocol for the 3rd party vpn if it doesn't handle DTLS-based traffic.

And you would need to make sure the vpn connection doesn't prematurely terminate/disconnect idle ica sessions which is something we don't usually have to worry about in ica proxy.

 

 

[Paul Blitz]

One other advantage is that this is a single-sign-on solution: authenticate once to the Netscaler Gateway (perhaps using multi-factor authentication), and that's it, the NG will SSO you on to the Storefront. With a 3rd party VPN, you first connect the VPN, then you authenticate to the Storefront....

[Mark Dear]

This article does a fairly good job of simply explaining the different remote connectivity methods offered by Citrix Gateway
https://www.smali.net/ica-proxy-vs-cvpn/

Worth highlighting is the fact that ICA proxy uses cheaper NetScaler Gateway Platform Licenses (ICA license) but does NOT support smart access features with StoreFront and CVAD.
cVPN is the remote connectivity method that supports the most features including SmartAccess but requires a more expensive NetScaler Gateway Universal License (CCU license) per user session. 

Regards Mark