Would you like to deploy Insight Center within your network and gather data about the ICA traffic that doesn’t go via NetScaler Gateway?

How about having the ability to direct only certain servers or clients via Insight? In this post I’m going to explain how.

What is “Routing” and How Does it Work?

The “IP” portion of TCP/IP is a layer 3 protocol that is sent over a network encapsulated, much as a letter is encapsulated within an envelope, within a layer 2 frame. Continuing the analogy, the sender and destination address on an envelope need not match the letter contained within.

An IP packet contains a source and destination IP address, this packet travels within a frame containing a source and destination MAC address.

If we consider communication between the XenApp and Insight server in Fig.1 a packet sourced from 192.168.0.2 and destined for 192.160.0.10 would be encapsulated within a frame sourced from the XenApp server’s MAC address and destined for the Insight server’s MAC address, the Insight server’s MAC address having been resolved via ARP.

To send to a destination outside of the local network the XenApp server would need to forward the packet to a gateway. This would be achieved by resolving the gateway’s MAC address via ARP and placing the original packet into a frame destined to the gateway’s interface. On receipt the gateway would take some action to forward the unmodified packet, within a new frame, onward towards its final destination.

This forwarding of packets between different networks or network segment, and perhaps more specifically the rules controlling that forwarding is routing.

Policy Based Routing

Policy Based Routing, as the name suggests, is a set of policies that if matched can override the usual next hop.

To illustrate the above imagine that we configured a policy on router R1 in Fig.2 to match all packets sourced or destined for ICA port 1494 and to set the next hop to the NetScaler at 192.168.2.2

The flow for an ICA packet sent from the End User computer at 192.168.1.2 to the XenApp server at 192.168.0.2 would now be, the end user computer placing the packet into a frame destined for R1’s MAC address, R1 matching the policy and placing the unmodified packet into a new frame destined for NetScaler’s MAC address, and finally the frame arriving at the NetScaler.

The configuration on R1 would look something like this:

access-list 100 permit tcp any any eq 1494

access-list 100 permit tcp any any eq 2598

route-map NetScaler-Insight permit 10

match ip address 100

set ip next-hop 192.168.2.2

interface FastEthernet0/0

ip policy route-map NetScaler-Insight

Of course at this point the NetScaler would somewhat confused having received a packet destined for an IP address it knew nothing about and would drop the packet, so this alone isn’t very much use but it demonstrates we can change the data flow using PBR.

NetScaler Layer 3 Routing Configuration

The NetScaler can also perform Layer 3 routing, actually it has a release of ZebOS running and can do some pretty awesome routing functions, but for this project the simple capability just to do L3 routing is enough.

As we now have incoming frames arriving at the NetScaler that contain packets addressed to another host, we need to tell NetScaler to act as a router and  forward these packets to the next hop within a new frame. We can do this by enabling L3 routing with the command “enable ns mode l3”.

Lets also set the IP address for R1’s interface f0/2 as the default gateway (and therefor next hop) on the NetScaler.

“add route 0.0.0.0 0.0.0.0 192.168.2.1”

The config above will create a Router-on-a-stick style deployment with frames coming into NS sourced from R1 f0/2 and leaving destined straight back to R1 f0/2 (fig 3.) – it’s called a Router-on-a-stick because it looks a like a lollipop and what’s life without whimsy?

 

This setup will give us a traffic flow that looks like this (fig. 4.).  Traffic will flow from the client to the XenApp server but will pass through the NetScaler when doing so.  AppFlow can now be enabled and the ICA traffic logged.

 

Configuring AppFlow

In my lab NetScaler Insight is already installed on 192.168.0.10, before performing the configuration below (on NetScaler) you should ensure you also have Insight installed and linked to NetScaler.

Enable Appflow

en ns fe AppFlow

Specify the TCP ports on which to listen for ICA traffic

set ns param –icaPorts 2598 1494

Define an Insight server to send AppFlow data to

add appflow collector MyInsight -IPAddress 192.168.0.10

Define an action causing AppFlow data to be sent to the collector

add appflow action act -collectors MyInsight

Always send the data to the collector

add appflow policy pol true act

Apply the above configuration to ICA traffic

bind appflow global pol 1 -type ICA_REQ_DEFAULT

Set the interval at which flow records are sent to the configured collector (in seconds)

set appflow param -flowRecordInterval 60


That’s It

With the configuration above you now have ICA traffic that doesn’t go via NetScaler Gateway routed through a NetScaler instance and reported on.

To log only certain clients or servers we can change the Policy Based Routing rules, rather than matching any source and any destination we could perhaps match only a client on 192.168.1.2 or a server on 192.168.0.2

access-list 100 permit tcp 192.168.1.2 any eq 1494

access-list 100 permit tcp 192.168.1.2 any eq 2598

access-list 100 permit tcp any 192.168.0.2 eq 1494

access-list 100 permit tcp any 192.168.0.2 eq 2598