in NetScaler Gateway

HTTP Proxy Redirection for XenMobile WorxWeb

XenMobile has a secure web browser called WorxWeb that allows you to browse web pages on the internet and on your private intranet, but how to selectively redirect this web traffic to a proxy server?

In this blog we will be discussing how to create a redirect to a HTTP proxy for XenMobile WorxWeb. For this we will be configuring a traffic policy on Netscaler based on this Citrix Blogs article. This blog describes two ways of configuring a redirect to a proxy server on NetScaler;

  1. Global policy that applies to all NetScaler Gateway (NSGW) traffic
  2. Traffic Policy based approach that applies to selected traffic

We have picked option 2 and wrote this down a bit different than the before mentioned blog, just because we can and because technology changed a bit.

Versions Used

For this setup I used a test lab with the following versions:

  • NetScaler 10.1.128.e (tested on 10.5.52 too)
  • XenMobile Enterprise 9
  • Apple iPad with WorxWeb for testing
  • CCProxy (just the first super easy windows proxy I came across).

Background Info / Explanation

We would like to selectively redirect traffic to a proxy server. Reasons for redirection to a proxy server can be:

  • NetScaler does not have access to the internet directly
  • Webtraffic from XM needs to be logged / filtered / scanned / etc.
  • You want to limit who can access internet and who can not.
  • etc.

The trick in this blog is not the proxy setting, it is the selective redirection. As per the example in this blog;

We want to redirect web traffic (80 and 443 ONLY), if originated from WorxWeb ONLY, and when NOT going to the intranet (lcoal web servers).

For this we can look into http and / or TCP headers to select the traffic that we will send to the proxy server.

  • The selection of the traffic is called a traffic POLICY
  • The action to forward the traffic to the proxy is called an traffic ACTION or PROFILE
  • To apply the traffic policy to a specific vServer we need a BINDING

The intelligence when to proxy the traffic is in the policies. A couple of examples:

Proxy WorxWeb traffic

Let’s assume you want to send all HTTP traffic from WorxWeb to the proxy server. To achieve this we will be identifying the traffic based on the HTTP headers. Let’s take a look at a network trace of a WorxWeb 9 browser to a website:

Screen Shot 2014-10-31 at 15.21.28

The User-Agent header contains the following information:

So all traffic from the WorxWeb browser can be identified by looking into the User-Agent header. To do so you can create a traffic policy:

This policy hits all traffic from WorxWeb on all ports. If you need to tag http and https to different proxy server ports you need to add the port number as per example:

Replace the pointer_...  to with the Traffic Action that specifies your proxy (please see below for example). 

Proxy WorxMail traffic

The previous example proxies all WorxWeb traffic. But what happens to the HTML content in your WorxMail session? (think newsletters, etc.). WorxMail does not use the same HTTP header as WorxWeb thus the previous rule does not tag this traffic.

NOTE: the code below probably hits on all http traffic coming from wrapped apps, but I have not been able to validate this yet.

In the traffic from WorxMail we see the following HTTP headers:

Screen Shot 2014-10-31 at 15.31.08

We tagged traffic by looking at another HTTP header called “ MDXSecureBrowserIOS “. To hit the policy based on this info and select HTTP port 80 only:

NOTE; obviously this hits IOS devices ONLY as the header includes IOS. For android et al you would need to capture the Android WorxMail HTTP header (please share!)

Exclude Traffic to Intranet

When you have intranet sites that you do not want to traverse through your proxy server you can exclude those. In general I believe there are two ways to do so, based on requested domain name or based on IP address.

Based on domain name:

Based on IP address:

How to

In the “How to” Below is have written down a complete config that can be used based on the above examples. The below is based on:

  • Redirect ONLY HTTP and HTTPS Traffic from WorxWeb
  • Do NOT redirect HTTP(S) traffic send to http://*mydomain.local*

We created traffic policies and actions on the Netscaler to redirect the http and https traffic to a proxy server. As stated before we do this only for traffic that originated from a WorxWeb browser session. You can create additional policies and actions to make this fit your needs.

If you think all traffic should be proxied, please go this the Citrix blog and scroll down a bit to use “Scenario 2”.

Traffic Action

First create an action to define what Proxy Server to use when a policy is hit. We need to create a policy for both HTTP and HTTPS as we want to proxy those two protocols and a NOPROXY policy for traffic to local servers we do not want to proxy.

Replace with your proxy IP and Port.

Traffic Policies

Create Traffic Profiles to select HTTP, HTTPS and non-proxy traffic so we select whether to proxy or not proxy the traffic. The policy looks at the traffic and decides to not proxy, send to http proxy, send to https proxy or let is pass untouched (implicit; no match against policy).

The first policy will NOT proxy traffic with destination URL in the intranet.

The second and third policy will redirect traffic that is send by a WorxWeb browser (found in the user agent HTTP header) and send to port 80 or 443 to a proxy server. In my example the port for http and https traffic on the proxy server is the same, however this can be different in your setup, that’s why this is configured in 2 separate lines (can be done in one if the port is the same).

Binding the traffic policies

Before the config becomes active you need to bind the configure policies to a vServer. This would typically be your NSGW where you terminate the Micro VPN tunnels. Make sure that the most specific polices have the highest priority (lowest value), so no-proxy policies (exclude host / subnet) before proxy all http traffic policies.

Replace NetScaler_Gateway_name with you NSGW name (lookup with show vpn vserver )

In your GUI this should show something like:

Screen Shot 2014-10-30 at 16.34.36

XenMobile Settings

Before testing if the traffic flows through the proxy we need to make sure we send all the traffic to the NetScaler; we can’t redirect what we can’t see. So make sure that you set your WorxWeb settings in XenMobile to “Tunneled to the Internet” and “Full VPN Tunnel”.

Screen Shot 2014-10-30 at 16.17.22


Checking the setup

First of all you would like to test if you can browse internet and intranet pages. That should work, right? Next you probably would like to troubleshoot why it isn’t working or validate the work you have done. To do so you can choose from a couple of options:

  • Check if your policies are hit
    to do this you can run a command in the NetScaler Shell. This will show a line mentioning the policy if it is hit by traffic:
  • Look at the proxy log
    Look at the logs and see of your requests are arriving in the proxy server. The CCProxy I mentioned as a live log window that shows the traffic.
  • If all else fails…
    TCP dumps / Network trace. Run a trace while generating traffic and see what happens.


What do you think?



  • Configure XenMobile Secure Web to utilize HTTP Web Proxy for Outbound Internet Access - AppDelivery November 3, 2014

    Thanks for posting this great blog!