Category 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 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.

Load Balancer Internal IP’s Appearing in IIS/Apache Logs: Quick Fix

If you are NAT’ing public to private addresses with a load balancer in between your web server and your Gateway/FireWall device you might come across the situation where the IIS/Apache logs report the IP of the Load Balancer, when what you really want, is the client IP.

It’s obvious that the biggest issue with this is that any Log Parser/Analytic’s you do against the site will all be relative to the IP of the load balancer. All useful client and geographical information is lost.

Most Load Balancer’s get around this by inserting a Header into the packet that relates to Client IP. In most cases that I have seen, both Juniper and NetScalers the Header is set to rlnclientipaddr.

What needs to be done at the web server configuration level to help pick up on and translate the header info so it can be used to translate the correct client IP into the log files. There are obviously different way to achieve this in Apache, compared to IIS and Apache has a much simply solution than IIS.


In your apache.conf go to the LogFormat sections and modify the default format as shown below (Replace the Red text with the green text) and restart the Apache Service.


The IIS 5/6/7/8 solution is a little more involved, but still just as efficient and not overly complicated at the end of the day…in fact for me the hardest part was actually chasing up the DLL’s linked below. It must be noted that while this has worked perfectly for me against both a Juniper DX and NetScaler VPX load balancer I would suggest testing the solution before putting it into production. Reason being is that the ISAPI filters are specifically sourced for the Juniper DX series, but in my testing I found that they worked for the NetScalers as well. Sourcing the x64 DLL’s was a mission, so in this I am saving you a great deal of time by provided the files below.


Download and extract those files into your Windows root. Go to the Features View -> ISAPI Filters and Click on Add. Enter in the Name and Executable Location and click ok. Note that it’s handy to add both 32 and 64 bit version to a 64bit IIS Web Server just in case you are dealing with legacy Application that are required to run in 32bit mode. Adding the ISAPI Filter at the root config of the Web Server so it propagates down to all existing sites and any newly created sites.