Redirecting AGEE URL – NetScaler 9.3 52.3nc

While working with a new AGEE site for a client (, I was given the challenge to ensure that only a specific subnet is redirected to the new site while still connecting to the original url (, and ensure no one else is impacted by the redirector.

Luckily this can be achieved by setting up Responder Policies via the NetScaler


  • MPX 7500 NetScaler 9.3 52.3nc
  • AGEE


Redirect an AGEE site based on a specific clients subnet

1. All users that go to AGEE1 site simply get redirected to AGEE1 site with SSL

2. All users from the subnet that go to AGEE1 site get redirected to AGEE2 site


1. First make sure the Responder feature is turned on by right clicking “Responder” and selecting “enable responder feature”

Once it is enabled, it will look like this


2.  Now lets create Actions.  This will tell policies what to do.

Lets create a redirect action for ALL users to be redirected to AGEE1 SSL site


Now lets create a redirect action for a specific subnet and redirect to AGEE2 SSL site


Now that we have the actions defined, lets create the policies that will be assigned to your VIP

3. Create Responder polcies – The actions you created above will need to be binded to your Responder polcies

Create a policy to to match the URL (in this case then bind your previous action to redirect them to




Now create a policy that will match the url and will redirect users from the to




4. Now lets assign these Responder policies to your AGEE1 site

Notice on the screenshot below, I simply created a service name “Dummy” and gave it the NetSacalers localhost IP, this is simply to make sure the TCP 80 VIP is able to come up under the AGEE IP (Since AGEE ONLY runs under TCP 443).  Note that Responder actions will not work under down VIPs.


Head over to the “Polcies” tab, then click on”Responder” and assign the polcies you previously created.  A reminder that the lower the priority number, the higher the priority actually is.  In the case below “subnetet_users_pol” wins


Hope this helps! 🙂


NetScaler AGEE 9.3 – Customize logon page via NetScaler rewrite policies

While working on a new project at a new company, we made the decision of utilizing the Access Gateway on the NetScaler to host a new client’s site as the XenApp entry point. Although it is clear on the benefits that AGEE brings, we can agree that it also brings a bit of complexity when customizing the log on page.

While this can be done with some HTML customizations, Citrix does not provide support for an AGEE customized site, so I figure this time I would look into NetScaler rewrite policies to accomplish the same.


  • MPX 7500 NetScaler 9.3 52.3nc
  • Web Interface 5.3 (I know :P)


When two factor authentication is configured on Access Gateway Enterprise Edition, the user is prompted for User name, Password 1, and Password 2.



1. Create the following actions under “Rewrite/Actions”

add rewrite action AD_replace_rewrite_action replace_all “http.RES.BODY(120000).SET_TEXT_MODE(ignorecase)” “\”AD Password\’\”” -pattern “\”Password\”” -bypassSafetyCheck YES -refineSearch q/extend(50,50).REGEX_SELECT(re![ ]*\'[ ]*\+[ ]*_\(\”Password\”\)[ ]*!)/


add rewrite action RSA_replace_rewrite_action replace_all “http.RES.BODY(120000).SET_TEXT_MODE(ignorecase)” “\”RSA Password:\”” -pattern “\”Password2\”” -bypassSafetyCheck YES -refineSearch q/extend(20,50).REGEX_SELECT(re![ ]*\'[ ]*\+[ ]*\_\(\”Password2\”\)[ ]*\+[ ]*\’!)/


add rewrite action AD_delete_rewrite_action delete_all “http.RES.BODY(120000).SET_TEXT_MODE(ignorecase)” -pattern “document.write(\’ 1\’);” -bypassSafetyCheck YES


2. Create the following policies under “Rewrite/Policies”

add rewrite policy AD_rewrite_pol “http.req.url.path.endswith(\”vpn/login.js\”)” AD_replace_rewrite_action


add rewrite policy RSA_rewrite_pol “http.req.url.path.endswith(\”vpn/login.js\”)” RSA_replace_rewrite_action


add rewrite policy AD_delete_pol “http.req.url.path.endswith(\”vpn/login.js\”)” AD_delete_rewrite_action


3. Enable/Bind the policies

bind rewrite global AD_rewrite_pol 80 NEXT -type RES_OVERRIDE

bind rewrite global RSA_rewrite_pol 90 NEXT -type RES_OVERRIDE

bind rewrite global AD_delete_pol 100 NEXT -type RES_OVERRIDE




For the logo… head over to this CTX article , note that you can copy the customized version of the logon page to a new directory of the appliance, however you will need to edit the rc.netscaler script to copy the required files to the /netscaler/ns_gui/vpn/ directory every time the appliance restarts, if not the changes are gone.

The rc.netscaler script would look something like this…, however a reminder that Citrix does not support this with version 9.3, and with version 10 71.6014.e, they added templates

cp /flash/nsconfig/mod_cag/index.html /netscaler/ns_gui/vpn/index.html
cp /flash/nsconfig/mod_cag/login.js /netscaler/ns_gui/vpn/login.js
cp /flash/nsconfig/mod_cag/images/ctxHeader01.gif /netscaler/ns_gui/vpn/images/ctxHeader01.gif

Renew Citrix Access Gateway SSL certificate

Ahhh… the time has come to replace those SSL certs on your CAGs.  Well most of the time we forget that the CAGs actually act as your CSG (Old School Citrix Secure Gateway) and your external sites are most liketly set up as “Gateway Direct” and pointing your return traffic to your CAG.  Meaning if your SSL cert expires, you can kiss those XenApp/XenDesktop connections good bye.

Keep one thing in mind… your SSL certs do not need to be on your Web Interface boxes (common misunderstanding that I hear all the time).  If you have NetScalers you can do SSL Offloading, but will not get into that now.

Luckly the process is really simple, if you google this, you may get confused with the OPENSSL conversion process, etc.  Here is what you need to do.

    • Generate the CSR on any IIS server via the IIS Certificate Wizard (not the CAG)
    • Send the CSR to your CA (Thawte, Verisign, GoDaddy, etc),
    • Import the certificate received from your CA via the certificate wizard to the same IIS box you used.
    • Export the certificate (including the private key! ) via the MMC Certificate Snap-in into a .pfx file and password protected if needed.
    • Convert the .pfx file to .pem format using OPENSSL – You can follow these steps (good luck!)
    • Or use a a tool developed by the OpenSSL Project called PFX2PEM which will simply allow you to drop the .pfx file into a .wds script which will convert it to PEM. Follow this link to get the tool and also read a bit on the the process (really simple)
    • Once you extract the file to .pem, import the file onto your CAG.
    • In addition, depending on the CA, you may need to upload their intermediate certificates as well.

The pem and root certs are managed on the Administration tab of your CAG

Access Gateway 5.0.4 Fail-over configuration

Since it seems the Access Gateway (CAG) will stick around (5.0.5 in the works), I decided it is worth investing the time to fully understand how the new CAGs handle failover.  There is a good deep dive article by Citrix on this, if you are still CAGing, I suggest you read it, as many things have changed since the 4.6.x (black screen) days.

The best feature (I think) is that sessions stay in sync, meaning users don’t get disconnected when fail-over occurs!

To test fail-over on this config, I’m using the default network interface for the appliance fail-over, if you run a VPX, you can simply add virtual interfaces as needed.  If you have physical appliances, you can deploy the CAGs with a single interface, which frees up a port and dedicate it for fail-over which it is recommended by Citrix.

When you’re setting up Failover on the CAGs, both appliances must run the same version of the firmware, in addtion, the admin account must match on both appliances since that part of the config is not replicated.

With two appliances joined as a failover pair, you can NAT your external IP or internal traffic to a shared virtual IP (VIP) instead of the real eth0 or eth1 IP address.  (If you have NetScalers, I would disregard this and run AGEE, however you can also load balance CAGs, but then you may run into some SourceIP fun and will add complexity to your deployment).

You need to define one virtual IP address that users will connect to and another virtual IP address which CAGs use when communicating with back-end resources. The internal and external virtual IP address can both be the same as in the example below which is using VPX appliances which are very inexpensive.

Primary VPX :

Log in to your Primary VPX, under Management Node select Networking and check Application Failover.

Primary CAG

Application Fail-over node will be available and here you’ll need to provide some information.

Appliance Failover Role : Primary
Shared key : Your Private Shared Key
Peer IP Address : The address on you secondary VPX
Internal virtual IP : Internal and External can be the same address (this can be the same depending on your environment)
External virtual IP : Internal and External can be the same address (this can be the same depending on your environment)

CAG Failover config

Click Save then on Start, then restart the appliance. You’ll now be able to access your CAG from the external virutal IP address you configured.

Secondary VPX :

Head over to your secondary CAG and click on Appliance Failover.  Enter the Shared Key, the Peer IP address (the Primary VPX), click Join Primary and reboot the appliance when the button turns red.

Secondary CAG Failover

On the secondary appliance most of the configuration pages will become unavaiable, since it inherits configuration settings from the primary VPX. This includes host name, certificates, authentication profiles and so on.

Secondary CAG failover

The easiest way to test the configuration is add a host address (C:\Windows\System32\drivers\etc\hosts) with the internal/external virtual IP address to your  and then shut down the Primay VPX. If you get the following error 401 – Unauthorized: Access is denied due to invalid credentials you’ll need to change the host file on you Web Interface server to point to the new external virtual IP address.