This is an update to a previous article that I wrote about adding a pull-down menu with connection type choices on the logon page for Access Gateway Enterprise Edition. By default Access Gateway Enterprise Edition uses group extraction and EPA scans to determine what kind of connection a user can make. Access Gateway Enterprise also has a client choices screen after authentication that can provide end user selections. These policies may not always offer the best solution for your organization. Therefore configuring a pre-logon client choice may be the best option.
Background
The following are some reasons why you would give users a selection box before authentication:
1. Give users a choice to access their appliacations, desktops, or VPN sessions
2. Allow users to access Sharepoint, OWA, and other clientless web applications using the same url.
3. Allows users to have more control, reducing support calls.
4. Get more out of Access Gateway Enterprise. I created this video to give you an idea on how this can be used:
Procedure
NOTE: The index.html file mentioned on this article is found under /netscaler/ns_gui/vpn
First create a cookie on the user's workstation
This procedure creates a cookie on the user's workstation which will be evaluated by the session policy. The name of the cookie is NSCookie
1. Download index.html to your workstation.
2. Open the file for editing with your preferred document editor software.
3. Locate the following section:
4. Add the following on the next available line
5. The next line should read:
6. Add storeValues(this);" so that it reads:
Next create the actual pull-down menu
1. On the same index.html page locate the line that reads:
2. Add the following code.
(Note: you can add as many OPTIONS as you wish. The Value’s m(x) will be used to match up against a session policy)
3. Save the changes and copy the file to the /netscaler/ns_gui/vpn directory
Note: make sure to backup the original file.
Create a procedure to allow the custom page to survive a reboot
1. Connect to the appliance using an SSH client such as PuTTY.
2. Type shell.
3. Make a directory on the hard drive to hold the custom file.
mkdir /var/customizations
4. Copy the modified page to the new directory.
5. Create a startup script file called rc.netscaler under /nsconfig (if one is not already present).
cd /nsconfig
touch rc.netscaler
6. Copy the copy command into rc.netscaler.
echo cp /var/customizations/index.html /netscaler/ns_gui/vpn/index.html >> /nsconfig/rc.netscaler
Next you must modify the session policies to be based on the presence of the cookie instead of the default "true value".
The expression syntax would look similar to that shown in the screen shot below:
The user will then be given a drop down menu on the default logon page. The cookie will be placed on their workstation and evaluated by the session policies. MyDT is the default which should always match the users Default connection while others will match other session policies.
Question: Does NetScalers XML Broker health monitoring and load balancing protect intra-zone IMA communication?
Protection for Web Interface
When a user launches web applications from a XenApp Web Interface (WI) server, the WI connects to a member server in order to retrieve a list of available applications and to find the least loaded server for the user to use. It uses an XML Broker query for this communication. Getting this information is critical for application launch success and if the member server has a process failure of the XML or IMA service, this communication will fail. Since the WI can be given a list of member servers to try to reach (and it can move to other servers if no response is received) a member server process failure may result in just a delayed WI response as it tries to communication with another member server. Which could take several seconds or minutes depending on how many servers are afflicted. And in the worst cases, where just the IMA service fails, a null list of information is returned to WI and the application launch process fails completely. This is the dreaded "black hole" which is nasty because it's so hard to diagnose. Users may experience any of 3 different symptoms, most of which make administrators think they're dealing with a permissions issue.
If the “black hole” occurs on the first server (or the only server listed in the WI’s list of Brokers) the application availability will be 0.0%. This problem gets particularly nasty when it occurs on another server and results in intermittent failures which can be almost impossible to diagnose. Or when a process monitor is constantly restarting the IMA service. (out of desperation, administrators who experience this tend to resort to rebooting every server in the zone) These are the reasons we need the NetScaler; which acts as a 3rd party manager (“traffic cop”) of this communication. By using the built-in XenApp monitors, the NetScaler can detect XML and IMA process failures, alert administrators, and automatically direct the WI servers to working member servers.
Protection for the Zone Data Collector
The XenApp server which receives the WI’s request will contact the Zone Data Collector (ZDC). It does this because only the ZDC knows which member servers in the zone has the least resource utilization and can support the next application launch request. This intra-zone communication also needs to be protected, and it is, through heartbeats and scheduled events which occur on the ZDC. If a ZDC does not receive an IMA based update from a member server every 1 minute (tunable) it becomes concerned and sends a ping (IMAPing) to the member server in question. Should the ping fail, the “lost” member server will not be ping’d again for 5 minutes (tunable) and will not be included in the load distribution response sent to the XenApp server that posed the question on behalf of the WI. Likewise, the ZDC’s communication itself is protected though an election process which operates based on the same mechanism as the member server reporting.
Summary
Both the NetScaler and ZDC health monitoring are needed to achieve five nines (99.999%) uptime for XenApp delivery. With these monitors in place, XML and IMA process failures can be detected, alerted on, and automatically healed around within 60 seconds.
In the short of it, Netscaler can be placed in many different kind of Network Scenarios. There's One arm and Two arm, Public/Private, MBF, USIP, VLAN's, Aggregated Interfaces, ACL's, Layer 2 and Layer 3, or both... Huh... I could write a book on the many different ways to configure a Netscaler (and I would get about 10 buyers / of those buyers none of them would agree with me), so in light of saving me a few months of my life for a measley 400$ before taxes and lawyer fees, I think I'll start with the simple explanation on 1 and 2 arms. What are the advantages of each and which is right for your organisation?
Overview
First, I want to explain the differences between the two (Or three as you will find out). Fundamental difference between one arm and two arms are related to layer 3 networking, not how many interfaces are hanging out of your Netscaler. One arm mode is a Netscaler connected to one network and consists of one IP subnet on the Netscaler. This mode has a single route (The default gateway). Two arm mode actually has multiple Networks configured on the Netscaler. In this mode, there is usually a default route but sometimes (But not always) you will have additional routes that point to the next hop to access backend resources.
Don't confuse one and two arm modes with how many interfaces are plugged into the switch. For instance, a Netscaler can have one interface plugged into the network, but have VLAN trunking configured so that multiple networks are attached to the NS, this is referred to as two arm mode. At the same time, a Netscaler can have up to four interfaces connected to a single switch and aggregated together to form a network bond, this is referred to as one arm mode. Now lets go deep into the different modes...
One Arm Mode
One arm mode is by far the simplest configuration. But don't confuse simple with the only way to do it. In this mode, the Netscaler is generally sitting in a DMZ on the same subnet as the web servers that it is serving content.
The Advantages of this is that it is easy. One arm mode is typically the way that most engineers prefer to implement Netscaler, because you only have to worry about a single route (The all zeros to the Firewall), and they don't have to make any configuration changes on the application servers themselves.
There are a few things to understand before choosing this method. First of all, since the Application Servers are on the same subnet as your VIP, you will use additional IP's on that subnet for non Internet facing recources. This is generally not a problem, but if the subnet happens to be a public subnet (with public IP's), your application servers will have public IP's bound to their NIC's. Obviously the workaround here is to NAT the entire subnet at the firewall.
Another common issue with one arm mode is if you are configuring the Netscaler in a DMZ and expect to load balance internal resource (or you are using the Netscaler for SSLVPN access into your private LAN). In this scenario, you will have to open rules on your inbound leg of the firewall. While this is usually no problem for setting up a public facing Sharepoint site or Web interface, it does pose an issue with full SSLVPN.
Security folks will generally look at this configuration and think that the Web Servers can be compromised because they are not behind the Netscaler... Well,,, yes and NO! Your Firewall should be your first level of defense against attackers, therefore, a security administrator can easily mitigate this risk by locking down public access to only the VIP's and not the individual machines. This being said, of course placing the application servers behind the Netscaler in a two arm mode configuration will add a bit more security (even if it is only security through obscurity). The Netscaler is going to perform the same security related functions (App Firewall, Filtering, Surge Protection, HTTP DoS, etc.) reguardless if the App Servers are in front, behind, or 10 routes past the Netscaler in another city. So i really don't buy it, but I am willing to argue that point....
Two Arm Mode (Traditional)
If you are familiar with the old load balancing products, you might remember that we had to configure the load balance devices "in line" with the web servers. Although not required on the Netscaler (Unless USIP mode is being used in some scenarios), Two arm mode allows an admin to place the Web Apps on a network behind the Netscalers. This configuration is generally not preferred any more and generally requires the Web Apps to change their addresses and default gateway pointed to the Netscalers SNIP or MIP address.
Some admins might say that this is the best way to do it because it hides the web servers from the Public Internet and it saves the amount of public IP's that are needed.... While these are not valid reasons to consider when choosing the way the Netscaler is implemented (Simply look at my earlier conversation about one arm mode and twist it around a bit), there are some especially important reasons for implementing two arm mode.
The first, of course, is that you are replacing a legacy load balancer and you want the migration to be quick and painless. Most legacy load balancers were implemented in a two arm mode so a config and drop will be your quickest turn around.
If you would like all hosts to appear as if their Internet Communications are coming from the Netscaler and not the actual hosts, then you should place the NS's in a two arm mode with RNAT enabled on the Netscalers for those specific hosts. Note that this is usually done when the hosts source Internet Comminications such as Credit Card Transactions and/or SMTP relay where the hosts IP address must match the DNS record. Please note that RNAT can also be done at the firewall in most scenarios.
Alternativly, if you have multiple DMZ's and you want to use "one pair" of Netscalers for all of the DMZ's, this scenario might be the right choice for you. In this scenario, you can perform VLAN tagging from the firewall to the Netscaler and the Netscaler to the backend switches. The Netscaler is then configured with Mac Based Forwarding and each VLAN is basically configured as it's own virtual Netscaler. This is a great configuration for Cloud Hosting providors because they can seperate their customers on their own VLAN's while only having to purchase a single pair of Netscalers to host all of their customers' content.
NOTE: When using two armed mode, you should consider implementing VLANS to separate the two arms. This is very important when configuring HA in two arm mode because in some scenario's the Netscaler can send sync/heartbeat packets out the wrong interface which may result in both Netscalers becoming the primary. This is Generally BAD!
There is one gotcha when configuring the Netscaler in Two arm mode... If you configure the NS in Two Arm mode and you decide to use the Netscaler as the default gateway of the load balancing hosts, the Netscaler will perform "ALL" routing decisions on behalf of the hosts. While this may not seem to be a big issue, it does, however alter your ability to make future design changes such as drop in a leg into your private Network, etc...
Two Arm Mode (Public / Private)
Two arm mode (Public/Private) is configured no differently than two arm (Traditional) with the exception that the second arm actually hooks into your private network. Why would you do this you might ask???
By extending an Interface to the internal Network, you can use the same Netscaler hardware for load balancing external apps as well as internal apps. It also allows you to perform functions such as SSL VPN without having to open a bunch of holes in the firewall when using one arm mode. This mode saves money, but it does add some complexity.
First of all, in a Two Arm (Public / Private) mode, you have to pay attention to routing... You will most likely have an external route (Same as always all zeros to the Firewall) but you will also have to add internal routes to internal resources.
Second, you may have to pay attention to routing loops. If connections from internal hosts are accessing VIPS on the external Interface, the Netscaler may try to send packets back to the internal host using the internal connection, hence a routing loop is born. This can easily be fixed by either adding duplicate internal VIPS, NATTING at the DMZ, or by turning on Mac Based Forwarding on the Netscaler.
Many security folks seem to bark at this as being an "in-secure" way of deploying the Netscaler. True, this specific mode does raise some security concerns. But all of these concerns can be addressed by features built into the Netscaler. First of all, you should ALWAYS assign VLANS to the internal and external interfaces to ensure that there is some layer 2 separation between the two networks (Remember, it is called an Application Switch). Second, make sure the device is only in Layer 3 mode and Layer 2 is disabled. Third, you can always configure ACL's to further lock down the environment. Finally. if you are worried about SSLVPN traversing your network, you really should take a look at the SMART ACCESS features of the Netscaler. Inbound access with SSLVPN is not only controlled at the Network layer, but also at the user, group, device, and individual scenario layer such as the presence of Anti-Virus or a specific Service Pack!
I really do like configuring Two Arm mode (Public / Private) because it basically turns your Netscaler into a buy one get one free deal. Of course, it usually goes beyond just the price. Simple management, easy administration, and easy provisioning of new VServers on the inside and out! Now if you ask me, it's worth it!
What about all the other modes?
I know, there are many other ways of configuring the Netscaler. USIP, Layer 2, Layer 3, HA, MBF... Well, I'm not going to cover them all.... I guess you will just have to wait for that book, or maybe you can sit in one of my classes. In either case, you should get to know the product before making rash decisions on how it should be placed in your Network. the Netscaler is an amazing product that can do more than you could ever guess, but you could easily back yourself into a corner and make it very difficult to add functionality if the wrong mode has been chosen.
Now let's hear the roars!!!
In all the years of working with Citrix products, I can assure you that one of the biggest thorns in my side has been related to client delivery. The process of getting a XENApp, or Access Gateway Client installed on an end users’ machine not knowing anything about the end users’ operating system was a subject that I would easily avoid if given the chance. Until Now... It’s no surprise that Microsoft wants to use this technology to deliver its own Application Streaming client.
Citrix Receiver is a lightweight, auto-updating client that enables easy, secure access to applications and desktops from any device. Yes, any device! PCs, Macs, smartphones and thin clients. It provides a client framework, with a plug-in architecture that transparently controls the management of functional plug-ins, including updates and user notifications.
The user experience is simple; the end user just visits the Citrix Receiver home page hosted in your corporate office, agree to the terms, download and install the receiver. Once the receiver is installed, an administrator can control all the available plug-ins that will be downloaded to that user. The Administration is provided by Citrix Merchandising Server, an easy to use virtual appliance that provides centralized management of plug-ins while also keeping them up to date. Since Merchandising Server is a virtual appliance, it’s easy to provision in any environment. Merchandising Server also includes tools for migrating existing Citrix customers from legacy implementations of Citrix software clients such as Citrix Program Neighborhood, PN Agent, and Web Interface.
XenApp, XenDesktop, CitrixAccess Gateway and Branch Repeater plugins are all available to the Citrix Receiver right now. Citrix Receiver is free and is available for any Windows-based device, including PCs, laptops, netbooks and even thin clients. Citrix Receiver forApple`s iPhone is also available as a free download from the AppleApp Store. Citrix Merchandising Server is also available free charge.
If you've experienced the pain like I have, it's worth your time to take a look. You will be glad you did.
Gaining High availability for XENAPP across geographically separated sites has always been a challenge, especially when you are talking about connecting over the Internet and you have little control. Citrix Netscaler offers the GSLB option which helps overcome these challenges.
Overview Daniel Feller from Citrix has written a great article explaining the differences between the different physical and logical site layouts in a XENAPP Environment. I encourage you to read it if you are considering deploying XENAPP or AGEE with Multiple Site redundancy. Click here to read the article. I wanted to take just a minute to point out some things you shoud consider in a multi-site configuration.
Active/Passive GSLB with ICA Proxy An Active/Passive ica proxy configuration is very straight forward. All users are directed at one site, while the other site sits and waits until the primary site goes down. This is by far the easiest configuration to go with. You should still consider having dedicated Web Interface Servers at each site and if possible, have a XENAPP Site configured for both locations.
Active/Active GSLB with ICA Proxy
Active/Active is the second option. This configuration makes both sites hot and relies on DNS queries to equally load users to both sites. Once the user is connected, the source IP persistence is used to keep the connection stuck to the site the user first came in on.
While Active/Active GSLB is desired, there are some challenges. For instance, when we discuss typical GSLB, we are usually talking about Web Browsers. Web Browsers have the tendency to cache the DNS names which really makes GSLB persistency a piece of cake (And failover a night mare). The ICA protocol and most every other application in the world honors DNS, so if the IP address changes mid stream, then the protocol will automatically begin connections to the new IP address. In many scenarios this breaks the ICA connection and really ticks off end users.
To work around this, consider using Wild Card certificates with a user FQDN and two site based FQDN's all matching the wildcard certificate.
example:
Certificate = *.GSLB.com
AGEE Site = AGEE.GSLB.com / IP = balanced between 1.1.1.1 or 1.2.1.1
SiteA = siteA.GSLB.com / IP = 1.1.1.1
SiteB = siteB.GSLB.com / IP = 1.2.1.1
While the Browser access the main site AGEE.GSLB.com, each web interface in their respective site should be configured with ICA proxy settings to their respective site. This ensures that ica proxy always stays connected to the same site even if the client resolves a different AGEE IP address.
Site Dedicated Web Interface Servers for AAC mode
Each site needs to have it's own Web Interface servers if you are using Access Gateway Enterprise Edition with Advanced Access Control Authentication. This is because the Web Interface server must "Always" communicate back to the same AGEE Vserver that the user first came in on. I generally control this by configuring hosts files on the WI servers to always resolve the local site AGEE VServer.
Use Netscaler Monitors Netscaler and AGEE come with default monitors that can monitor your XENAPP, XENDESKTOP, or Web Interface servers. These monitors should be configured at the Load Balancing Service level and the GSLB Service level. Using real monitors allows your Netscaler configuration to be a little smarter and can determine a server outage, or even a site outage.
Use DNS Views
DNS views can be configured to provide the correct DNS answer for internal vs. external communication. DNS views are DNS policies that simply look at the source IP of the DNS server that is making the query. If the query is coming from the internal network, the Netscaler will answer with an Internal IP address. if it's coming from anything else, it answers with the external IP address. DNS views are a great way to allow for the XENAPP plugin to connect direct when laptops are local, but connect Gateway Direct when users are on the Internet.
Use Static Proximity
Static Proximity is a configuration in the Netscaler that looks at the source address of the client DNS server and forces the client to the appropriate site. This is great when you have multiple XENAPP sites and you would like to limit the distance from the client to the correct site.
Summary
In summary, GSLB is a great tool to add value and high availability to your XENAPP or XENDESKTOP farm. There is a lot of information out on the net that can help build a sound environment.
By: Rick RohneThis article describes how to add a pull-down menu with connection type choices on the logon page for Access Gateway Enterprise Edition. The selections are then analyzed by the session policy.
Example:
Background By default Access Gateway Enterprise Edition uses group extraction and EPA scans to determine what kind of connection a user can make. Access Gateway Enterprise also has a client choices screen after authentication that can provide end user selections. Client choices, however, does not always offer the best solution for some users.
The following are typical reasons why you would give users a selection box before authentication:
1. Some users can not install the Active X controls for EPA scans due to lack of administrative rights or using a browser other than Internet Explorer. 2. You may wish to offer up a SharePoint site or Outlook Web Access site as the clientless home page. Client Choices cannot give end users choices on their home page. 3. An organization may have different security policies on different VPN methods (such as split tunneling on or off, or different Authorisation policies.
Procedure The file mentioned on this article is found under /netscaler/ns_gui/vpn.
Create a cookie on the user's workstation This procedure creates a cookie on the user's workstation which will be evaluated by the session policy. The name of the cookie is NSCookie 1. Download index.html to your workstation. 2. Open the file for editing with your preferred document editor software. 3. Locate the following section:
</SCRIPT>
4. Add the following on the next available line
<script> function setCookieVal() { var selectBox = document.getElementById("myList"); var value = selectBox.options[selectBox.selectedIndex].value; setCookie("NSCookie", value); } function setCookie(c_name,value,expiredays) { var exdate=new Date(); exdate.setDate(exdate.getDate()+1); document.cookie=c_name+ "=" +value+";path=/;expires="+exdate.toGMTString(); } </script>
Create the actual pull-down menu: 1. On the same index,html choose an area in the body to create the drop down menu. 2. Add the following code.
<FORM NAME="myform"> <SELECT NAME="myList" id="myList" onchange="javascript:setCookieVal()"> <OPTION VALUE="m1">Connect using defaults <OPTION VALUE="m2">C onnect to my Computer <OPTION VALUE="m3">Connect to my Applications </SELECT> </FORM>
(Note: you can add as many OPTIONS as you wish. The Value’s m(x) will be used to match up against a session policy)
Next, we need to ensure that the form is evaluated when the page is loaded.
1. Find the line that begins the body: <BODY id=bodyTag onload="ns_fillName();">
2. Add setCookieVal() to the line. The line should read: <BODY id=bodyTag onload="ns_fillName();setCookieVal();">
3. Save the changes and copy the file to the /netscaler/ns_gui/vpn directory. Note: make sure to backup the original file.
Create a procedure to allow the custom page to survive a reboot: 1. Connect to the appliance using an SSH client such as PuTTY. 2. Type shell. 3. Make a directory on the hard drive to hold the custom file. mkdir /var/customizations 4. Copy the modified page to the new directory. cp /netscaler/ns_gui/vpn/index.html /var/customizations/ 5. Create a startup script file called rc.netscaler under /nsconfig (if one is not already present). cd /nsconfig touch rc.netscaler 6. Copy the copy command into rc.netscaler. echo cp /var/customizations/index.html /netscaler/ns_gui/vpn/index.html >> /nsconfig/rc.netscaler
Next you must modify the session policies to be based on the presence of the cookie instead of the default "true value". The expression syntax would look similar to that shown in the screen shot below: add vpn sessionPolicy POL_WI_Cookie "REQ.HTTP.HEADER Cookie CONTAINS m3" WI_ONLY_Profile
More Information The user will then be given a drop down menu on the default logon page. The cookie will be placed on their workstation and evaluated by the session policies. M1 is the default which should always match the users Default connection while m2, m3 etc. will match other session policies.
The views and opinions of this site and its contributors are the personal views of these individuals and in no way reflect the views, opinions, or recommendations from any organization.
