Implementing NetScaler VPX (2014)
Chapter 2. NetScaler Gateway
NetScaler Gateway is one of the most commonly used features of NetScaler. In earlier versions, Citrix had products such as Secure Gateway or Access Gateway, but with the 10.1 release of NetScaler, it was renamed NetScaler Gateway. This feature does the same task as it did before; it grants users remote access through a gateway to the corporate network. It has multiple features and ways in which it can give end users access to the corporate network, which we will cover throughout this chapter. So here is a quick overview of what we will be covering in this chapter:
· Basics of NetScaler Gateway
· Different connection methods and settings
· Sample setup scenarios
· Integrating with XenDesktop/XenApp and XenMobile
· Configuring StoreFront
A brief history
The NetScaler Gateway feature has been available in many different forms. The first release of the Gateway feature came with Citrix Secure Gateway, which was first released in 2001. This was a Windows-based software, which gave users remote access to their Citrix solutions. Later on, Citrix released Access Gateway, which gave us more features such as SSL VPN, Endpoint analysis, and VPN. It is has now been named NetScaler Gateway and it is available in two different forms, either as a subfeature of NetScaler, or as its own appliance, which further comes in two editions, either a VPX or an MPX edition. This appliance only has the NetScaler Gateway feature and nothing more. More information about these two editions and what their specifications are can be found in the NetScaler Gateway datasheet located at http://bit.ly/1kGLZS0.
Many companies use the NetScaler Gateway feature on a regular NetScaler appliance as it gives the benefit of incorporating many features on the same appliance, instead of having scattered features on many different appliances.
Understanding the features
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:
1. User 1 accesses the solution through https://login.company.com, which is accessible via the VIP on NetScaler.
2. User 1 authenticates on the site with his/her credentials.
3. 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.
4. The user is validated and the credentials are forwarded to the StoreFront Authentication service using the SNIP of NetScaler.
5. 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.
6. The XML service from XenApp contacts StoreFront and delivers a secure ticket and information regarding available resources.
7. 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:
1. 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.
2. StoreFront connects using the XML service to the XenApp farm.
3. The STA service queries the IMA service for a resource that can launch Application 1.
4. The STA service returns a server that has available resources with its IP address to StoreFront.
5. 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.
6. 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.
Deploying ICA Proxy
First of all, we need to enable the NetScaler Gateway feature. This can be done either in the GUI by navigating to System | Settings | Configure Basic Modes and choosing Access Gateway or by using the following CLI command:
enable ns feature SSLVPN
Note
After build 10.118 was released, Citrix introduced a quick configuration wizard that makes it easy to set up and configure the NetScaler Gateway feature. In the steps covered in this book, we do not make use of the wizard, but we are going for the same configuration. This wizard can be started from within the GUI by navigating to NetScaler Gateway Pane | NetScaler Gateway Wizard.
Then, we go into the NetScaler Gateway feature of the GUI. Here, we choose Virtual Servers, and right-click and choose Add Server. This will open a menu that allows us to create a virtual server, which the clients are going to access.
There are multiple configuration items that are required in order to create a fully functional vServer. Remember that first we need to configure the default settings such as NSIP, SNIP, and a functional license. Following are some of the settings we need to set:
· Name of the server: This is purely for description purposes.
· Protocol: This is always SSL.
· IP Address: This is going to be the VIP address.
· Port: The default port is port 443.
· Basic mode / SmartAccess mode: For configuration of ICA Proxy, we need to set this to Basic mode. If we need a SSL VPN-based vServer, we should create another vServer and set it to SmartAccess mode.
· Certificate: A trusted certificate is required by the clients and the StoreFront server. It should be issued by a public certificate provider, such as GlobalSign or Go Daddy. This certificate is added under the certificate pane.
· Authentication Policy: This defines the connection strings to the Active Directory for authentication and, for example, to the RADIUS two-factor authentication method.
· Session Policy: This defines where and how to contact the StoreFront server, and how credentials are forwarded to the StoreFront server.
· STA: This is the Secure Ticket Authority server.
We enter the information in the window, such as Name and IP Address and set the vServer to Basic mode, and leave the rest at default for now, as shown in the following screenshot:
Note
This section assumes that you are familiar with how a digital certificate works, and what the prerequisites are to create one. In order to create a certificate, we first need a private key and a Certificate Signing Request (CSR), which is sent to a third-party certificate issuer such as Go Daddy. In NetScaler, go to the SSL pane under Traffic Management in the GUI. This menu also allows us to import the certificate itself, and the intermediate and root certificates. It also has an option to import PFX certificates, which often bundle the private key, the intermediate certificate, and the PFX certificate itself in one file. You can also use OpenSSL from NetScaler to convert a CRT certificate to a PFX certificate using the guide located at http://bit.ly/1lzMvEq.
Next, we need to add a digital certificate for the vServer. The typical way is by going to the Certificate pane, choosing Install, and adding a certificate. Now, depending on how the public certificate provider issues certificates, the steps may vary. Following are the cases:
· If we have a PFX certificate, it usually contains the private key, the intermediate certificate, and the PFX certificate itself. In this case, we need to choose PFX as the certificate filename and the private key filename. If the intermediate certificate is part of the file, we should also choose the certificate bundle.
· If we have a CER certificate, it usually contains a single certificate file and a key file, which contains the private key we need to add to it. If we have an additional intermediate certificate that we need to add to the vServer, we first have to import the certificate and choose Add as CA. In many cases, you would need to link the main certificate to an intermediate certificate to validate the chain. You can see how to configure it at http://support.citrix.com/article/CTX114146.
There is an excellent blog written by Derek Seaman describing how to add a certificate to NetScaler, which can be viewed at http://www.derekseaman.com/2013/05/import-iis-ssl-certificate-to-citrix-netscaler.html. Also, I have written a post on how to use OpenSSL to convert a CRT file to a PFX file. This can be viewed at http://msandbu.wordpress.com/2012/10/15/convert-from-crt-to-pfx-with-openssl/.
After we have added a certificate, we need to add an authentication policy. There are two types of authentication policies that we need to think about, primary and secondary. The primary authentication type is typical LDAP (Active Directory), and the secondary might be a RADIUS solution. When the users try to log in, they will be presented with an interface that requires them to enter a username and password for the Active Directory, and a second password for the secondary authentication solution.
Now, this is very dependent on how the RADIUS provider delivers the authentication process. An example is SafeNet, which we just need to add as a secondary RADIUS authentication provider. There are also others that completely replace the LDAP authentication process. I have added links to different vendors and their setup for a two-factor authentication. For RSA SecurEnvoy, the link is https://www.securenvoy.com/integrationguides/citrix%20net%20scaler%20with%20ipad.pdf. For SafeNet, the link is http://www2.safenet-inc.com/cryptocard/implementation-guides/Citrix/Citrix_Access_Gateway_Implementation_Guide_1111.pdf.
For mobile devices, such as an iPad, we need to enter the RADIUS solution as the primary authentication. In order to sort the different authentication policies, based upon which device is connecting, we need to use the appropriate expression. We are going to cover this later in the chapter. You can also read more about this at http://support.citrix.com/article/CTX125364.
As this scenario focuses only on a single Active Directory authentication, we only need to create a single primary authentication policy. Click on the Authentication pane under vServer Settings | Primary. Go to Insert Policy | Policy Name, and choose New. This will open a policy window. First, we need to enter a name for this policy and then choose LDAP as the authentication type.
Note
If we want, it is also possible to allow users to change their Active Directory password. This requires that the domain controllers are responding on LDAPS, and that the authentication policy is configured with the option to allow for password change.
It is also important that we understand how policies work in NetScaler, as this not only applies to authentication, but to other features in NetScaler as well. When we create a policy, we define an expression. That expression defines what must happen to the policy it is bound to for it to run. There are multiple options that we can choose here. If we click on the Add button, we get numerous options that allow us to granularly define who this policy should apply to.
In the following scenario, we want a policy to apply to all users who want to access this solution. Therefore, we are going to add the ns_true expression. This can either be typed directly into the Expression field or found through the GUI under General | True Value Expression | Add Expression. This expression now states that this authentication policy should apply to all users that are connecting via NetScaler.
Note
You can read more about expressions and how to create sample expressions in the Citrix article at http://support.citrix.com/proddocs/topic/ns-main-appexpert-10-map/ns-pi-config-classic-expr-tsk.html.
After we have added the expression, we need to define a server that NetScaler can contact to verify the credentials. Under the Server pane, choose New. Here, we need to enter information about the Active Directory server, such as the following:
· IP Address: This is the IP address.
· Base DN: This defines the organizational unit in Active Directory where the users are located. For example, a base DN for an organizational unit called users in the domain test.com would look like CN = users, DC = test, DC = com.
· Administrator Bind DN: This is the username for an AD user that is allowed to query the domain. The username can be written in the domain\username form.
· Administrator Password: This is the password for the account and needs to be written twice.
· Server Log on Name Attribute: This should be set to samAccountName. It is also possible to use UserPrincipleName. This allows users to log in with their e-mail addresses.
After this is done, you can check the connection to the domain controller, and verify that the user has the correct rights by clicking on the Retrieve Attributes button.
Note
Using the retrieve attributes action does not initiate a connection from NetScaler itself to AD, but from the IP address of the machine that runs the browser that is connected to the NetScaler GUI.
Also, you might encounter a case where you would need the user to choose from different AD domains, for example, in a migration situation, or if you have multiple domains from which the users need to choose a domain to log in to. By default, there is no built-in feature that allows users to choose from different domains. We can add multiple authentication policies that point to different domains, or we can use expressions to filter domains based upon different criteria, such as the IP address. We could also add a drop-down menu on the login portal that allows the users to choose from different domains. Citrix has published an article that covers how you can create a drop-down menu to choose a domain. You can read it at http://support.citrix.com/article/CTX118657.
If you are having issues with authentication from NetScaler to Active Directory, there is a built-in tool that can be run from the CLI. Start by typing shell, and then change the directory to tmp cd /tmp. Then run the following command:
cat aaad.debug
This will automatically generate events in the console for every authentication attempt. The task can be killed by pressing Ctrl + Z.
After we have finished adding an Active Directory server, adding an expression, and naming the policy, we can click on Create. This will then add the Active Directory policy to the vServer. Notice that the policy has a priority of 100. If we have multiple policies here, the one with the lowest priority will win as long as the expression is the same. Therefore, if we have three primary authentication policies, all with the same configuration, but with different priorities of 80, 90, and 100, and all try to connect to the service, they would be bound to the policy that has the priority of 80.
Let us look at another example of how policies work. Suppose we have three authentication policies bound to a vServer, each with different priorities, and each of them has an expression that requires the client to have a particular IP address such as the following:
· Policy 1: In this policy, the priority is 80. The expression is REQ.IP.SOURCEIP == 200.0.0.0 -net mask 255.0.0.0.
· Policy 2: In this policy, the priority is 90. The expression is REQ.IP.SOURCEIP == 210.0.0.0 -net mask 255.0.0.0.
· Policy 3: In this policy, the priority is 100. The expression is REQ.IP.SOURCEIP == 220.0.0.0 -net mask 255.0.0.0.
When a client connects, NetScaler will look at the list of policies starting with the one having the lowest priority and see if the clients match the criteria in the expression. If they do not match, it will go down the list until it gets a match. This is also the case if we have multiple RADIUS servers listed under secondary authentication.
Now, the most important part that is needed to finish the configuration is the session policy. This can be found under Policies | Session on the vServer. Click on Insert Policy, and then choose New Policy. We are presented with a policy window. As we want all users to be bound to this policy, we use the same general expression ns_true as shown in the following screenshot:
We give this session policy a name, and then we add a request profile to the policy. The request profile stores information about where the StoreFront server is located, how it should forward credentials to the StoreFront server, whether ICA Proxy should be used, and so on.
Click on New under Request Profile, and we are taken to another window. Here, there are multiple configurations that we need to take a closer look at. They are shown in the following screenshot:
Note
Notice that we have the option to choose Override Global for every item. Instead of defining settings at the vServer level, we can also define settings at a global level. These settings would then be default for all vServers created in NetScaler. If we have settings set at a global level, and we wish to override these, we need to choose Override Global.
The Network Configuration pane is used for regular VPN profiles, so we will skip that for now. Under the Client Experience pane, we have multiple settings that we can define. We are going to cover all of these as some are used for ICA Proxy and some are used for SSL VPN or VPN. Following are the settings:
· Home Page: This is mostly used for XenMobile deployments and when you want to define a homepage for an SSL VPN session.
· URL for Web-Based Email: This is used for logging in to web-based e-mail solutions, such as Exchange OWA.
· Split Tunnel: This is used to define whether all client traffic or only traffic meant for destined servers in the network should go through the gateway in a VPN connection.
· Session Time-out (mins): This defines how long NetScaler waits before it disconnects the session when there is no network traffic. This applies to all type of clients.
· Client Idle Time-out (mins): This defines how long NetScaler waits before it disconnects the session when there is no user activity. This applies only to NetScaler plugins.
· Clientless Access: This defines whether the SSL-based VPN should be enabled or disabled.
· Clientless Access URL Encoding: This defines if the URLs of internal web applications are obscured, or are in clear text and visible to the users.
· Clientless Access Persistent Cookie: This is needed for access to certain features in SharePoint, such as opening and editing documents.
· Plug-in Type: This defines what kind of plugin is offered to the user, whether it is Windows/Mac-based or Java-based.
· Single Sign-on to Web Applications: This allows NetScaler to do SSO either for the web interface/StoreFront or for a custom homepage that is set to be the SharePoint site.
· Credential Index: This defines which authentication credentials are forwarded to the web application. Here, we can choose from the primary or the secondary authentication set.
· Single Sign-on with Windows: This allows the Gateway plugin to authenticate to NetScaler using the Windows credentials.
· Client Cleanup Prompt: This is used to control the display of the client cleanup prompt after exiting an SSL VPN session. This feature is available for regular Windows/Mac-based clients, but not for mobile devices.
All we need to do in the Network Configuration pane is check the Single Sign-on to Web Applications option, and set the Credential Index field to PRIMARY. This allows NetScaler Gateway to forward LDAP credentials (which are defined as the primary authentication) to the StoreFront server. We should also define the plugin type to be Windows/Mac, as we want users to connect using the Windows plugin.
Note
The credential index and plugin type are by default set to PRIMARY and Windows/Mac plugin respectively at the global level, so we do not need to define these values. In case of multiple vServers, it is better to define these settings at the vServer level instead of the global level.
The plugin will be offered to users after they log in to the site, if they do not have it installed.
In the Security pane, all we need to do is make sure that the Default Authorization Action option is set to Allow. This ensures that the users are actually allowed to log in and access the resources.
Next, we have the Published Applications pane. This is where we enter the information needed to access our Citrix environment. Following are the settings:
· ICA Proxy: Here, we define if NetScaler should tunnel ICA traffic through port 443.
· Web Interface Address: Here, we define the URL to StoreFront Citrix web receiver.
· Web Interface Portal Mode: This defines if the web interface should appear with full graphical experience or use the compact view.
· Single Sign-on Domain: This defines which AD domain should be used for single sign-on.
· Citrix Receiver Homepage: This is used to define the URL for clients connecting to a Citrix receiver that does not support StoreFront.
· Account Services Address: This is used for e-mail based account discovery for Citrix Receiver. The URL must be in the form of https://<StoreFront/AppController URL>/Citrix/Roaming/Accounts. This requires that the DNS is properly configured. More information can be found at http://blogs.citrix.com/2013/04/01/configuring-email-based-account-discovery-for-citrix-receiver/.
Here, we need to set ICA Proxy to On, and define the URL to the StoreFront address. We can also define a single sign-on domain. The domain name entered here has to match the one set in StoreFront. After this is set, we are done with the session policy and we can click on Create. Now, the final part that is remaining is to add the STA servers. In the vServer Creation window, go to the Published Applications pane and click on Secure Ticket Authority to add the servers. Also, if we need to add the StoreFront server to the session policy using HTTPS, we need to import the trusted root certificate of the StoreFront server to NetScaler or else the call back authentication will not function properly. This can be done under Traffic Management | SSL | Import PKCS #12 with the root certificate from the StoreFront server.
Note
It is recommended that the STA servers are added by IP addresses instead of hostnames. The STA servers that are added here should be identical to the ones that are used in StoreFront.
After this is done, we have now fully configured the Gateway function on NetScaler. Now, we have to configure StoreFront to allow remote connections to pass through authentication.
StoreFront integration
These steps require an existing StoreFront and XenApp/XenDesktop deployment in place. First, we need to add a gateway to StoreFront. This can be done from the GUI by navigating to StoreFront Administration Console | Gateways. On the right-hand side here, click on Add Gateway Server and then add the information as shown in the following screenshot:
Enter the relevant information. The Callback URL field needs to point to the VIP address of NetScaler Gateway. This is needed so that StoreFront can send validation back to the Gateway authentication service. The Subnet IP address is used by StoreFront to identify if a user is connecting from NetScaler. This field is optional for newer releases of NetScaler Gateway. This can also cause an issue if we are using NetScaler to load balance StoreFront, so it is advisable not to do so if not necessary.
Now, there are some issues that might occur when communicating back to the callback URL via the external VIP in DMZ. Here, the problem might be twofold. One of the problems we face here is certificate mismatch. First, open a web browser on the StoreFront server and verify the certificate chain by connecting to the VIP. If it is unsuccessful, we need to add the root or intermediate certificate to the StoreFront server to verify the chain. Also, if DNS is pointing you to the external VIP, you can add an entry to the location in the local hosts file on the StoreFront server, where we enter the FQDN of the VIP server and the internal VIP. The second problem that might occur is a firewall issue. For example, if StoreFront is located in the intranet zone and is not allowed to communicate back to the VIP, which is located in DMZ.
If we are unable to communicate back to the internal VIP because of network restrictions, we can add a dummy VIP to NetScaler, which resides on the internal network with the SNIP. All we need to do to create a new vServer is add STAs and a certificate, and alter the StoreFront hosts file to point to the dummy VIP instead of the external VIP, which resides in DMZ.
Now for the final part, we need to go to the Stores node, and on the right-hand side of the console click on the Enable Remote Access option of the store we want to have remote access enabled for. Here, we have to specify how and when resources will be available. Following are the settings:
· None: This option means only local users on the internal network will be able to access the store.
· No VPN Tunnel: This option makes resources available directly to NetScaler Gateway and does not require the use of the NetScaler Gateway plugin.
· Full VPN Tunnel: This option makes resources only available through an SSL VPN. This requires a NetScaler Gateway plugin.
As ICA Proxy requires only Citrix Receiver, we choose No VPN Tunnel, and we mark the NetScaler appliance we added earlier. Lastly, we need to enable pass-through authentication from the Authentication pane in StoreFront. This is needed as users are entering their credentials in NetScaler Gateway, and we want them to automatically sign-on to the StoreFront site. This is shown in the following screenshot:
One last thing we need to configure in StoreFront are beacons. Beacons are used to identify if a user is coming externally or internally. You can read the Citrix article on how to set up beacons at http://support.citrix.com/proddocs/topic/dws-storefront-21/dws-configure-beacon.html. Now, we have successfully set up and configured ICA Proxy.
One thing that is important to note is that ICA Proxy allows for client-initiated renegotiation by default after establishing an SSL connection. This applies to every virtual server that uses SSL and is created in NetScaler. Because of a security vulnerability in the SSL and TLS protocols, this would allow an attacker to inject a custom packet inside a secure session when it starts. There is a free tool available on https://www.ssllabs.com, which we can use to find out if our service is vulnerable to such an attack. In the following screenshot, we can see that our solution is vulnerable to a client renegotiation attack.
There is a workaround that we can deploy in NetScaler to disable this attack. We can do this by using the following CLI command:
Set ssl parameter –denySSLrenegNONSECURE
Deploying VPN
Deploying a full VPN solution might, in some cases, be needed for some users, as it allows a client to become a part of the internal network using the NetScaler Gateway plugin. With the use of the NetScaler Gateway plugin, we also have Endpoint analysis that allows us to scan a client for specific processes or, for example, to find out if antivirus software is running. Endpoint analysis is not covered as part of this book. For more information about Endpoint analysis, I suggest reading the Citrix article located athttp://support.citrix.com/article/CTX135136.
Configuring the use of regular VPN with NetScaler Gateway is not so much different from ICA Proxy. We need the following:
· A NetScaler Gateway vServer with a name, a port, and an IP address
· A vServer set to SmartAccess
· A trusted certificate
· An authentication policy
· A session policy
The only difference here is that we need to set the vServer to SmartAccess, and we need to change the session policy.
When we are creating the session policy, there are attributes that should be configured in the Client Experience pane. There are multiple settings that define how a VPN tunnel should behave, so it is important to note what each feature does. Following are the settings:
· Split Tunnel: This is used to define if all client traffic or only traffic for destined servers in the network should go through the gateway in a CVPN connection.
· Client Idle Time-out (mins): This defines how long NetScaler waits before it disconnects the session when there is no user activity. This only applies to NetScaler plugins.
· Plug-in Type: This defines what kind of plugin is offered to the user, either Windows/Mac-based or Java-based.
· Single Sign-on to Web Applications: This allows NetScaler to do SSO either for the web interface/StoreFront or if we have set a custom homepage to be the SharePoint site.
· Credential Index: This defines which authentication credentials are forwarded to the web application. Here, we can choose from the primary or the secondary authentication set.
· Single Sign-on with Windows: This allows the Gateway plugin to authenticate to NetScaler using Windows credentials.
There are some exceptions here. If the Split Tunnel option is disabled, it means that all Endpoint traffic is routed through NetScaler. If it is enabled, it means the only traffic that is destined for the internal network is routed through NetScaler. This also means that we need to define which IP address or range of addresses the gateway should intercept. This is done using something called an intranet application, which is available in the vServer. Here, we can define a range of IP addresses or a single IP address that the gateway will intercept for the client. There are some differences here. For example, for Java-based clients, we need to define intranet applications as proxy-based, and for regular Windows/Mac clients we need to define the intranet applications as transparent. We cannot combine these two types of intranet applications.
Also, should we require giving a connected client a dedicated IP address, we need to define intranet IPs that will act like a DHCP server. Here, we can define a range of IP addresses that can be given to users. These intranet IPs can be bound to an AAA user, an AAA group, a vServer, or at a global level. IP addresses that are bound to a user take priority over the other options.
Now, under the Published Applications pane, we need to define the following:
· ICA Proxy: This should be set to Off as the client will have a full VPN connection and does not need the gateway to proxy traffic.
· Web Interface Address: This should be defined to allow clients to connect to the StoreFront site.
· Single Sign-on Domain: This defines which AD domain can be used for single sign-on.
When users connect to this vServer now, they will be presented with a download option that allows them to download the NetScaler Gateway plugin and they will be redirected to the StoreFront site.
Now, even though this uses the NetScaler Gateway plugin to establish a connection, we still need Citrix Receiver to establish a connection to the Citrix environment. It is possible to integrate these two clients. If a user has Citrix Receiver installed previously, and then installs the NetScaler Gateway plugin, they will get a new option under Citrix Receiver Applet | About | Advanced | Access Gateway Settings. From here, users can start a full VPN session directly using Citrix Receiver when they are connected by clicking on Login from the Access Gateway Settings option.
So after these settings are configured, we will have successfully configured a VPN solution on our Gateway. An important point to note is that in some cases you might get issues with building a VPN tunnel. In that case, you might consider using MAC-based forwarding. This issue happens with some firewalls.
Deploying clientless access
Clientless access is a basic browser-based VPN solution, where users are presented with a homepage when they log in and from there they can access file shares, web applications, and other settings depending on what is defined in the session policy.
In order to allow clientless access, we need to define some settings in the session policy part of the Client Experience pane. Following are the settings:
· URL for Web-Based Email: This is used for logging into web-based e-mail solutions, such as Exchange OWA. This will appear as a pane within the clientless access session policy window.
· Session Time-out (mins): This defines how long NetScaler waits before it disconnects the session when there is no network traffic.
· Clientless Access: This defines if the SSL-based VPN should be enabled or disabled.
· Clientless Access URL Encoding: This defines whether the URL of internal web applications are obscured or are in clear text and visible to the users.
· Clientless Access Persistent Cookie: This is needed for accessing certain features in SharePoint such as opening and editing documents.
· Client Cleanup Prompt: This is used to control the display of the client cleanup prompt after exiting a SSL VPN session.
· Single Sign-on to Web Applications: This allows NetScaler to do SSO either for the web interface/StoreFront or if we have set a custom homepage to be the SharePoint site.
· Credential Index: This defines which authentication credentials are forwarded to the web application. Here, we can choose from the primary or the secondary authentication set.
In the Published Applications pane, we define the following settings in the request profile:
· Web Interface Address: Here, we define the URL to the StoreFront receiver.
· Web Interface Portal Mode: This defines if the web interface should appear with full graphical experience or use the compact view.
· Single Sign-on Domain: This defines which AD domain should be used for single sign-on.
Now, in order to activate clientless access, we only need to set the vServer to SmartAccess and set clientless access to ON under the session policy, but there are other settings as well that can affect this feature. For example, if we add a URL for web-based e-mail, users will have an e-mail pane after they log in, which is going to be proxied via NetScaler. This allows them to log in to their e-mail. URL encoding determines if the URL should be masked so that the users will never see the real URL when they are browsing on a web application. Persistent cookie is needed for some cases, such as using SharePoint. Also, adding the web interface address and defining single sign-on allows NetScaler to display the user's applications within the same clientless access session. If a user clicks on an application here, it will start a Citrix Receiver session. We also have the option to add file shares and web applications to the portal. This can be done either within the vServer under the Bookmarks pane or as a user-based policy. Note that when you add a bookmark and bind it to a user or a vServer, it will appear under the Enterprise pane of the portal. Users also have the option to add their own bookmarks. We will go through how to add settings to a specific user or group later in this chapter.
When we add a bookmark, we also have the option to use NetScaler Gateway as a reverse proxy. If this is enabled, it means that when a user clicks on the bookmark, the connection will go from the user to NetScaler, and from there to the application. If this is not enabled, the connection will go from the user to the specified address in the bookmark.
Binding the features together
We have three different features that we have gone through, and each of them gives us some functionality. For example, if we want all of the different features to be available to the user at the same time, and give the users the option to choose between different features.
Note
An important point to note is that using all these features on the same vServer requires universal licenses for all the users connecting to it. So, in some cases, it might be more beneficial to create three vServers, where you have one for each service.
If we want to have a single web portal where we want to give the users the ability to choose the kind of resource they need, we need to make a change to the default session policy that they use. Under the session policy, go to the request profile that is bound to it and then click on the Client Experience pane. Here, click on the Advanced button. In the menu, we have an option called Client Choices. By enabling this, the users will get an option to choose what type of feature they need when logging in to the web portal.
The options that are presented here are dependent on what is configured in the session policy. For example, if clientless access is not defined, it will not show up as an option here. If we have not entered a web interface address, Citrix XenApp will not show up as an option. Lastly, if we have set the vServer to basic mode, it will automatically go to the StoreFront server. Another option we have is to use expressions. We can use expressions to filter sessions based on user agents, IP addresses, and so on. For example, suppose we want to create a dedicated session policy to be applied only to Android devices, and the default session policy to be applied to all other devices that are connecting. For Android devices, the following CLI expression declares that the connecting client must have a user agent string, which contains Citrix Receiver and Android:
REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver&&REQ.HTTP.HEADER User-Agent CONTAINS Android/
Note
A list of different expressions that can be used for different client types can be found at http://support.citrix.com/proddocs/topic/access-gateway-10/agee-clg-session-policies-overview-con.html.
Then, we create a custom session policy that is bound to that expression containing the specific configuration for our Android devices. We then use the general ns_true expression to apply to the rest and bind a session policy for the rest of the devices. Also, remember that the Android policy needs to have a lower priority than the other one, as ns_true applies to all clients that are connecting to the vServer, as shown in the following screenshot:
One last feature that we can use is the ability to filter based upon the Active Directory group. For example, suppose we want users who are part of the executives group to gain access to everything in the corporate network, and the regular users to gain access to some of the network. The way this operates is that when a user connects to the web portal, we can use NetScaler to get the list of the AD groups that the user is a member of from Active Directory, and find the first policy that is bound to one of the AD groups. It is important to note that user policies are processed before vServer and global policies. Therefore, if we have two session policies, one bound for the vServer and another for a user group, the user group policy will win.
In order to use this feature, we must first enable the authentication policy to get the list of the AD groups that the user who is connecting is a part of. This can be done by making sure that the memberOf attribute is entered in the authentication policy in the Group Attribute field. This is shown in the following screenshot:
After that is done, we need to go into the policy manager to create the AD groups. This can be found in the NetScaler Gateway pane. Here, we must first create an AAA group under Groups. The group name must be identical to the group name in the Active Directory. Now, we can start binding policies to the group by dragging them from the Available Policies/Resources pane to the Configured Policies/Resources pane. We can also create new custom policies as shown in the following screenshot and bind them accordingly:
Tuning
Now that we have gone through some of the different deployment types available in NetScaler Gateway, we should also take a closer look at fine-tuning the deployment setup with some simple changes.
Redirection
First, let us take a closer look at redirection, as by default NetScaler Gateway answers only on port 443, which uses HTTPS. Many users, most likely, forget to type https when accessing the portal, and therefore are not able to locate it. The NetScaler Gateway wizard has the option to set up redirection from http to https automatically.
By default, a vServer consists of an IP address and a port. The Gateway vServer responds to port 443. So in order to perform a redirect, we need to set up a vServer using port 80, as it has the option to redirect.
This can be done with the help of the following steps:
1. Go to Traffic Management | Load Balancing | Virtual Servers, and click on Add.
2. Here, we enter the same IP address as the regular Gateway vServer, and choose the regular HTTP in the Port field.
3. Next, go to the Advanced pane. There, we have an option called Redirect URL, where we enter the FQDN of the vServer with HTTPS in the front.
When this is done, we can click on OK. You will notice that the service is listed as DOWN. This is because no services are attached to the vServer; therefore, any connections made to the IP address will be forwarded to the Redirect URL. An important point to note is that if you have a regular NetScaler Gateway VPX, you cannot run this setup manually. You would need to run the remote access wizard.
Note
Make sure that the redirect URL has the full prefix as https://url.com/, with the forward slash at the end, or else some security scanners might see it as an XSS vulnerability.
Profiles
NetScaler can optimize connections using different TCP parameters, HTTP parameters, and net profiles. Many of the optimization parameters are set in different types of TCP profiles, and these can be viewed under System | Profiles | TCP Profiles.
Different profiles are useful in different scenarios and have different advantages depending on the network they are used in. By default, all vServers that are created in NetScaler use nstcp_default_profile. This profile makes sure that it works properly in all networks. Let us take a look at some of the different profiles.
· nstcp_default_tcp_lfp: This profile is best suited for high-bandwidth WAN and low packet loss environments.
· nstcp_default_tcp_lnp: This profile is best suited for low-bandwidth WAN and high packet loss environments.
· nstcp_default_tcp_lan: This profile is best suited for internal networks that are connected using LAN.
· nstcp_internal_apps: This profile should only be used for internal services on NetScaler, and should not be used on any other network services.
· nstcp_default_XA_XD_profile: This profile is best suited for ICA Proxy solutions.
Now, for a NetScaler Gateway vServer using ICA Proxy, it is highly recommended to use nstcp_default_xa_xd_profile. You can add this setting in NetScaler Gateway through the vServer, by going into the Advanced pane and clicking on TCP Profiles. When using a TCP profile, which is not the general one, you should test it properly before implementing it.
Another option where we can use profiles is if we are in a situation where we have different internal zones and different VIPs for our end users, and we need to make sure that a particular VIP uses a particular SNIP address. There is no direct relation between a VIP and an SNIP. If a NetScaler Gateway server was to connect to a StoreFront server, it would use the SNIP closest to it. If we have multiple internal zones, this would not work properly. This is where net profiles come in.
The network profile feature allows us to define the use of a specific source IP address or multiple addresses. In order to use network profiles, we must first create a network profile that contains the source IP address we wish NetScaler to use when initiating a connection to the backend servers. This can be done under System | Network | Net Profiles; then click on Add. Now we can enter a name for the profile, choose an IP address or multiple addresses (IP set), and then click on Create.
After we have created a network profile, we have to attach it to the different features that use an SNIP for backend connectivity. They are as follows:
· Virtual Server
· Service
· Service Groups
· Monitor
So, if we need to bind a specific network profile to a NetScaler Gateway vServer, we need to go to vServer | Advanced | Net Profile, and choose the network profile we created earlier.
Testing
Now, we are done with the setup and configuration of NetScaler Gateway. Before putting it into production, make sure that you have tested it properly. A quick checklist that we should go through is as follows:
· Different clients
· Different features such as clientless access, VPN, and ICA Proxy
· Trusted certificates on different devices
· Authentication
Summary
We have now gone through many of the different deployment types of the NetScaler Gateway function. We went through ICA Proxy, VPN using the NetScaler Gateway plugin, SSL-based VPN, and the different scenarios based on them.
There are many deployments that require the use of NetScaler Gateway, not just in XenDesktop but also in the newly released XenMobile. We cannot cover all of the different deployment types, so I recommend heading over to eDocs on Citrix for more information about the different deployment types. This eDoc is located at http://support.citrix.com/proddocs/topic/netscaler-gateway-101/ng-deployment-wrapper-con.html.
In the next chapter, we will explore load balancing, and how we can use load balancing for different technologies such as the roles feature in Citrix, and other products such as Exchange, SharePoint, and other generic web services.