Tag Archives: NetScaler

How-To: Citrix NetScaler GeoIP Restrictions

I had a request from a Hosting Client this week to look at options around blocking malicious users from causing trouble on a local Auction site. As the site was only for Australian and New Zealand users we needed to come up with a solution to block the whole world except AU and NZ visitors. Obviously I know there are mechanisms in existence that have annoyed me in the past while trying to source overseas content and getting the message telling you that you can’t access this site in your region.

I’ve never personally had to act on a request like this, and thought about options relating to some sort of code based filtering or filtering at the gateway level. I’ve known that in real terms I haven’t even scratched the surface of what our Citrix NetScaler VPX’s can do, and with that I searched for some guidelines on getting up GeoIP Responder rules at the Load Balancer’s Virtual Server level. Not being able to find anything definitive end to end, here are the steps I took to achieve the end result.

Citirx NetScaler ArticleHow to Block Access to a Site by Country using a Location Database

First step is to enable the Responder Feature is it’s not already enabled. Citrix suggest you disable any feature not in use to save on system resources.


In order for the NetScaler to work our what location a visitor is coming from it needs to reference a GeoIP database. MaxMind offer a free database from here: These are updated on the first Tuesday of everymonth, so a little upkeep is required moving forward. There are IPv4/6 versions as well as an extended database City version which lets you get very granular in terms of allowing city access. For this exercise we will use the GeoIPCountryWhois CSV database.

Jump into the shell of the NetScaler and create a new directory. Note that if you have a HA setup, you need to do this on each NetScaler node.

Use SCP to upload the CSV database to that location just created on the NetScaler and then run the following command to import the location parameters. Once done you can query the location database to ensure you have  imported the CSV line items.

Now that you have the GeoIP location locked and loaded, you can created the Responder Policy. I had a little trouble trying to work out how to structure the rule to work correctly limiting visitors to only .AU and .NZ. I’ll be honest here and admit that trial and error was the winner here, but eventually I came up with the following that works.

Reading through the policy it’s easy enough to see what’s going on…this page references the Location Database General Information and formats, however it’s confusing at best..my advice is for Country Based GeoIP use the above as a template and simply change the country codes to suit.

Back to the GUI of the NetScaler and under Load Balancing settings of the Virtual Server(s) in question, open the Virtual Server for editing and go to the Policies Tab -> Click on the Responder sub tab and right click to Insert Policy and the end result will be similar to what’s shown below.


I was able to use Twitter contacts with servers in global locations to test out the rule which was behaving exactly as expected. If you go back to the Policy menu item under Responder and check the Responder Policies you will be able to see if the rule is active and how many hits the rule has triggered.


The default action of the policy is to DROP or RESET the connection. You do have the option of creating a custom REDIRECT rule that will allow you to make the end user a little nicer in terms of presenting the user with a HTML page letting them know the page is restricted ..with the DROP and REST the browser simply shows a page not found or connection reset. I’ll update this post once i’ve created the REDIRECT rule.

Update: Turns out that if you apply the above rule it’s not that great for Google Analytics and the bots that hit your site. If you want to get the GoogleBot User Agent through the rule, create a rule similar to below

Looking at that additional condition  you are looking in the HTTP Request Header, ignoring case and matching Googlebot.

vCloud Director and Citrix NetScaler How-To

Ive come across a couple of how-to’s on configuring vCloud Cells in a highly available Load Balanced environment. There is a good overview here by @hany_michael with the always excellent @ccolotti referenced throughout. Ive come across specific posts such as this one from @DuncanYB for F5 Load Balancers…but nothing on Citrixs NetScalers. It must be said that I had help during my initial configuration and troubleshooting from Chris Colotti over a few Twitter DM’s that helped me nut out the Console Proxy setup.


Citrix acquired NetScaler in 2005 and in 2009 released the NetScaler VPX Appliances, which allowed the platform to go virtual. Read more about the NetScalers here This guide is based on the 9.3 VPX platform, but will be good for previous versions and the just released 10x platform. As a side note, Ive worked with Cisco 4840 and Juniper DX Load Balancers and I have to say that the NetScalers are far and away the best platform Ive come across. Feature packed for more than just Load Balancing, Ive found the interface intuitive and performance (even in a Virtual Appliance) has been rock solid and they offer Service Provider Licensing!

Environment Overview:

I wont go too deep into the specifics of the vCloud setup, but in a nutshell we are talking about a generic two cell setup connected to a typical vCenter design as governed by the vCat 2.0 Both cells are in a private VLAN fronted by the NetScaler which in turn is fronted by a border gateway that handles the public to private IP NATing and Firewalling. The NetScaler Visualiser below shows the basic layout from the Virtual Server IP’s and Service Names, through to the Web UI and Console Proxy Services on both cells.


CISCO ASA Configuration:

There is nothing special here as the ASA sits in front of the NetScaler and handles the NAT’ing of the Public IP to the Private Virtual IP on the NetScalers and also acts as the Firewall.


NetScaler Config – Server Setup:

Once logged into the Web UI of the NetScaler the first thing you want to do is add both vCloud Cells as Server Objects. Expand the Load Balancing Tree Root and select Servers. From there Right Click in the center pane and select Add. What you want to do here is create two entries per Cell…one for the main Web Portal Interface IP, and one for the Console Proxy Interface IP.

There isn’t a lot of detail to enter, Just the Server Name and the IP Address as shown below


In my setup with two cells I have four server entries in the central pane as shown below.


TIP: With the NetScaler if you click Add on a previously created object you will be presented with the settings of the selected object. From there its potentially a quick edit for the new element.

NetScaler Config – Service Setup:

There are a couple of ways to configure services and it comes down to whether you want to group like services into Service Groups, or configure individual services per Server instance.  In this example I have used individual Services as selected under the Load Balancing Tree root shown on the right. These options come together when configuring the Virtual Servers and boil down to being able to control weightings on specific Services on a per server basis, or grouping a farm of services together in the group. In either example you can take the underlying server in and out of production at will via the Servers section.

The Web Portal vCloud Cell interface is setup as shown below. 


Enter in the Service Name and select the Server from the dropdown. Protocol for this interface is SSL and the Port is 443.


TIP: Under the Advanced tab you should see the Client IP Header as a globally set value similar to the above. This allows us to have the vCloud logs report back the originating client IP instead of the IP of the load balancers…handy for advanced logging and troubleshooting.

For the vCloud Cell Console Proxy Interface the single biggest Gotchya is if you configure the protocol as SSL. @ccolotti guided me through my initial problems with this setup and got me to configure the protocol as TCP. Once that was configured as show below, I was able to view to console.


For me, this is one of the real features that makes a Hosted/Cloud Server truly functional. Having the console available via the management layer is a must and is pretty much standard with most Management Layers out there…along with the ability to stop/start/reset VM’s. At this point I would mention that one of my biggest gripes with vCloud is that there is no real time resource graphs or usage stats…hopefully this is added for future relases – Take that to be Feature Request VMware 🙂

At the end of this process you should see the following in your central window pane:


NetScaler Config – Virtual Server Setup:

Once you have configured your Servers and Service Groups, the final part is to put it all together and configure the Virtual Servers. The IP that you allocate (the VIP) is what you NAT your public IP to.  Right-Click on Add to get the Configure Virtual Server window as shown below. Enter in a Name, you IP Address and select SSL or TCP (depending on if setting up the Web Portal or Console Proxy) as the Protocal. The Port remains as 443On the Services Tab bind the Service Name’s of the Services we created in the steps above.


Click on the Method and Persistence Tab and here you want to set your LB Method Algorithm and your Persistence Method. There are a few to choose from in this list provided by the NetScaler, but I tend to always choose Least Connections which will send the next connection request to the server with the least number of active connections. One thing you don’t want in a load balanced setup for the Web Portal or Console Proxy is have sessions bouncing between Cells without stickiness which leads to session state loss. The Persistence method can be IP based or Cookie based for the Web Portal, but the Console Proxy needs to be IP Based as Cookies isn’t an option with TCP set as the protocol. Time-out can be set to any value you see fit, but I like setting this to 120 minutes to ensure a long stick.


The final step in setting up the Virtual Server is to bind an SSL certificate. Click on the SSL Settings tab. Assuming you have imported your SSL certificate into the NetScaler prior to setup, select the certificate from the left pane and click Add.

At the end of this process you should see the following in your central window pane:


vCloud SSL and WildCards:

Early on in my vCloud testing, I spent a huge amount of time trying to import a wildcard SSL certificate into the KeyStore without much luck. From what I could find on-line there wasn’t a lot of good how-to’s on getting this process down-pack with vCloud…let alone with any JAVA based KeyStore setup. My workaround was to put a Load Balancer in front of the cells. This was, the clients connect in over SSL to the NetScaler (with a legit wildcard SSL) and the NetScaler can connect to the cells over SSL/TCP (with with default vCloud certificate) ignoring the certificate warning, which no one like to see on a production system.


For a robust, redundant and highly available vCloud Cell design, a solid Load Balancer fronting the platform is a must. The Citrix NetScalers are  impressive appliances and are an excellent addition to any vCloud implementation.