Citrix NetScaler Gateway, the basics!

I don’t want to spend to much time talking about the different kinds of editions and or licenses available, if you want to know about those I suggest you check out one of my previous articles here, or just give citrix.com a visit. Throughout this article I’d like to briefly focus on some of the basic terminology and traffic flow that comes with the NetScaler Gateway edition providing our users with secure remote access. This (the Gateway edition) is probably one of the most popular NetScaler implementations today, although, and as you might know, the NetScalers ADC edition also has the Gateway functionality build-in and can provide us with a bunch of additional features as well. Let’s have a look shall we?!

Other (related) articles include:

1. Citrix NetScaler (10.5) licensing. What’s new with Access Gateway!
2. Citrix NetScaler… The basics continued, part one. VIP’s, Monitors and other objects!
3. Citrix NetScaler… The basics continued, part two. Static routes, SNIP and MIP!
4. Citrix NetScaler… The basics continued, part three. High availability!
5. Citrix NetScaler… The basics continued, part four. What about SSL?
6. Citrix NetScaler… The basics continued, part five. Global Server Load Balancing!
7. Citrix NetScaler… The basics continued, Part six. Content Switching!
8. Citrix NetScaler… The basics continued, part seven. Split Tunneling!

Make sure to check out my book: Inside Citrix – The FlexCast Management Architecture! It includes information from this blogpost and a (whole) lot more! Click here

NetScaler ADC and Gateway

Before we continue, first a short word on the two NetScaler editions available today. Most of the confusion starts with the terms; Citrix NetScaler and Citrix NetScaler Gateway, although they sound very similar, and they do have a overlap, there are some distinct differences depending on the licenses used.

Citrix NetScaler refers to their Application Delivery Controller, or ADC, line of products, while the NetScaler Gateway, formerly know as the Citrix Access Gateway, or CAG, is primarily used for secure remote access. You basically buy a ‘normal’ NetScaler but with limited functionality due to the NetScaler Gateway License you upload. NetScaler ADC’s are capable of doing much more than ‘just’ remote access, they can be used for load balancing and HA, content switching, application (SSL) offloading, application firewalling, cloud connectivity, hybrid cloud solutions and (a lot) more. 

General use

As mentioned, the NetScaler Gateway is used and configured to provide our users with secure remote access into our secure corporate network. As such it is physically placed within our DMZ, or Demilitarized Zone in full, where it sits in between the Internet and our secure corporate LAN fronted by at least one or two firewalls as shown in the overview below (got this from Citrix.com).

Some terminology first

Before I show you how traffic flows and what actually happens when a external user connects up to the NetScaler Gateway, I first want to spend a few minutes explaining some of the terminology you need to know and understand before we continue.

The NetScaler uses vServers (virtual servers) to deliver different kinds of services, in this case the vServer will be configured as a gateway server. Just remember that you can configure multiple independent vServers on the same NetScaler serving different purposes, like a load balancing or SSL offload vServer for example.

The NSIP address (NetScaler IP Address) is the IP address which is used by the Administrator to manage and configure the NetScaler. It is mandatory when setting up and configuring the NetScaler for the first time, there can only be one NSIP address, it can not be removed and when it’s changed you will have to reboot the NetScaler.

A SNIP (Subnet IP Address) is used for server side connections, meaning that this address will be used to route traffic from, or through, the NetScaler to a subnet directly connected to the NetScaler. The NetScaler has a mode named USNIP (Use SNIP), which is enabled by default, this causes the SNIP address to be used as the source address when sending packets from the NetScaler to the internal network. When a SNIP address is configured, a corresponding route is added to the NetScalers routing table, which is used to determine the optimal route from the NetScaler to the internal network. If it detects the SNIP address to be part of the route it will use it to pass-through the network traffic using the SNIP address as its source. A SNIP address is not mandatory. In a multiple subnet scenario you will have to configure a SNIP (or MIP, I’ll discuss this in a minute) address for each subnet separately. Also, when multiple SNIP addresses are configured on the same subnet, they will be used in a Round Robin fashion.

A MIP (Mapped IP Address) is similar to the SNIP address mentioned above. MIP addresses are used when a SNIP address isn’t not available or when USNIP (Use SNIP) is disabled. In that case it will also be used as the source IP address. Only when the configured MIP address is the first in the subnet it (the NetScaler) will add a route entry to its routing table.

A VIP address (Virtual IP Address) is the IP address of a vServer that the end users will connect to, and through which they will eventually be authenticated etc. For now just remember that the VIP address is never used as the source IP and thus isn’t involved in back-end server communication, instead this will always be handled by a SNIP and or MIP address, where, more often than not, SNIP addresses are used over MIP’s, but they can be mixed and used to connect to the same IP subnet even, again, Round Robin will than be used to determine the most optimal route.

Traffic flow

Now that we know what terminology is involved let’s have a look and see how traffic and communications actually flow through the NetScaler and how users get authenticated. Hopefully the overview below will help in clarifying some of the concepts mentioned throughout this article. I didn’t had Visio at hand so I decided to take another route, I hope you can appreciate my (free) drawing skills, I thought it was kind of cool to be honest :-)

Up close and personal

Ok, so what happens? Lets take it step by step. Due note that I’m primarily focussing on the NetScaler interaction here, as such I left out both the application enumeration process (XML querying, XML and STA file generation etc.) as well as the application launch sequence (which system can provide the resource, least load, .ICA file generation etc.) for now. Near the end I’ll provide you with an excellent recourse where you will find some more (detailed) information on the steps left out.

An external user will contact the NetScaler Gateway over port 80 or 443 (preferred). It will connect up to the externally accessible virtual IP (VIP) address of the NetScalers (Gateway) vServer. This is indicated as the VIP followed by the 1 vServer. Once a connection is established you have a few options, for example, using a SNIP address the (unauthenticated) user could be connected to the StoreFront server residing on the corporate (internal) network where authentication needs to take place (not displayed). A valid option but not as secure as we would like it to be right? Instead, we would like user authentication to take place on the NetScaler within our DMZ.

Let’s assume authentication takes place on the NetScaler. The users credentials are forwarded using the NetScalers IP address, or NSIP, indicated as 2 NSIP, to your internal authentication services, Active Directory in most cases, where they will be validated (or not). But wait, let’s do one better. Once validated, and still part of step 2 NSIP, we throw in something called two factor authentication, using SMS passcode tokens for example. This way every user will have to fill in his or her username and password plus an additional auto generated token code which will expire every few minutes (configurable), extremely secure.

Once the user is authenticated, the authentication services will pass through the user credentials to the StoreFront server. In step 3 SNIP, the already authenticated user will connect up to our internal StoreFront server where it will enumerate the users applications and or desktops.

Next, this information will travel back into the NetScaler and through the Gateway vServer onto the users screen. As indicated in step 4 vServer.

Finally, when the user starts an application, I left this part out as well, the StoreFront server will eventually generate a so called .ICA file which is send back to the users device and is used to connect the user directly to the requested resource on one of the XenDesktop / XenApp application servers. During the last phase of setting up this connection the Gateway server will check up on the earlier generated STA file to validate the session, after that the application or Desktop will be launched as indicated in step 5 app launch.

Wrap up.

Well that’s about it from a birds eye view so to speak, if you would like to read more on some of the details involved with regards to application enumeration process, XML and STA file generation etc. have a look here. It’s written by Ingmar Verheij, one of Citrix’s Senior Engineers. It’s a bit outdated but still (very) relevant! Note some of the port numbers and protocols used in the process, keep these in mind from a firewall and security perspective. Also, where port 80 is possible, use 443 instead :-)

Reference materials used: Citrix.com and the E-Docs website.

Bas van Kaam

Field CTO EMEA by day, author by night @ Nerdio

Father of three, EMEA Field CTO @ Nerdio, Author of the book Van de Basis tot aan Meester in de Cloud, Co-author of the book Project Byte-Sized and Yuthor of the book: Inside Citrix – The FlexCast Management Architecture, over 500 blog posts and multiple (ultimate) cheat sheets/e-books. Public speaker, sport enthusiast­­­­­­­­: above-average runner, 3 x burpee-mile finisher and a former semiprofessional snooker player. IT community participant and initiator of the AVD User group Community world wide.