NetScaler Gateway has a set of features, which can be used to grant end users remote access, such as:
- ICA Proxy: This feature allows the gateway to proxy ICA traffic from the backend XenApp or XenDesktop solution to the user through the TCP 443 port.
- SSL VPN: This is a browser-based VPN solution also known as clientless access.
- VPN: This is a virtual private network feature that gives users access to the corporate network using the NetScaler Gateway plugin.
- Endpoint analysis: This is a network access control feature, which scans clients to see whether they fulfill corporate security policy before they are allowed to connect to the network.
- SmartAccess: SmartAccess allows us to control access to applications and desktops on a server through the use of NetScaler session policies. You can read more about SmartAccess at http://support.citrix.com/proddocs/topic/access-gateway-92/agee-smartaccess-how-it-works-c.html.
- MDX: It is basically an application-level-based VPN solution, used for integrating NetScaler with XenMobile application management.
There are more features of NetScaler Gateway, which we will cover as we go through the chapter. One important thing to note is that all of these features require that we have a legitimate license installed on our NetScaler. For the use of the regular ICA Proxy feature, we only need a regular platform license, which we have covered in the previous chapter. If we want to use any of the other features in the preceding list, we also need a license called the universal license.
When we purchase a regular NetScaler platform license, either for an MPX or a VPX, we are given five universal licenses. We can verify this from the GUI by navigating to System | Licenses.
We can also verify this through the CLI using the following command:
show license
These licenses are concurrent, which means that we can have five users using a VPN-based solution at any given time. If we need more concurrent users, we have to buy more universal licenses.
The most commonly used feature of NetScaler Gateway is ICA Proxy, which allows remote access for users to XenApp or XenDesktop solutions, and requires only that the users have Citrix Receiver installed. It requires no additional licenses. The solution is quite simple as it tunnels all ICA traffic through the gateway and back to the user via port 443. This port is commonly used for secure HTTP traffic, is open on most firewalls, and is allowed on remote locations such as hotels and airports.
Let us take a look at a sample scenario to see how ICA Proxy operates, and how a user can access their applications or desktops. This scenario describes an example, and might be different from deployment to deployment depending on the network layout and infrastructure.
We have a company that has the NetScaler Gateway feature set up to allow remote users to access their XenApp solution. The example gateway is available at https://login.company.com, and the NSIP and SNIP are set up according to the design shown in the following figure:
When a user tries to access the solution, for example, using the web portal, the following happens:
- User 1 accesses the solution through
https://login.company.com, which is accessible via the VIP on NetScaler. - User 1 authenticates on the site with his/her credentials.
- NetScaler uses its NSIP to contact the Active Directory (AD) to validate the user. If we have configured a load-balanced Active Directory service, then it would use the SNIP.
- The user is validated and the credentials are forwarded to the StoreFront Authentication service using the SNIP of NetScaler.
- The StoreFront Authentication service forwards the credentials to the Store service, which in turn contacts the XenApp farm using its XML service to validate the user against the STA and get a list of available resources.
- The XML service from XenApp contacts StoreFront and delivers a secure ticket and information regarding available resources.
- The user is validated and StoreFront contacts the callback URL to NetScaler using its FQDN and generates a list of resources available for the user.
Now, the user has a portal which shows all the resources that are available. If the user was to click on an application/desktop, the following would happen:
- When User 1 clicks on Application 1, NetScaler sends an HTTP or HTTPS request depending on the setup to the StoreFront server, which indicates what resource is being requested.
- StoreFront connects using the XML service to the XenApp farm.
- The STA service queries the IMA service for a resource that can launch Application 1.
- The STA service returns a server that has available resources with its IP address to StoreFront.
- StoreFront generates an ICA file, which contains the ticket issued by the STA and sends it to the client web browser. The ICA file that is generated contains the full FQDN name of the NetScaler Gateway VIP. The IP address of the backend server is never revealed as the resource is bound up by the STA ticket.
- Citrix Receiver launches a session with the FQDN and the STA ticket.
We have now seen how a sample scenario might look like and how the different Citrix components communicate and generate an ICA connection with an external user. Even though we looked at how ICA Proxy operates, the procedure is not so much different for a regular VPN connection.
Now, let us look closer at the configuration of the Gateway feature within NetScaler, and how we can set it up to reflect the sample scenario.