Citrix NetScalers provide a feature called AppFlow. AppFlow allows Netscaler devices to export flow data to collection tools, often to be used for network/security analysis. Citrix offers a UI for AppFlow configuration, but if you are not familiar with it, the UI can be strange to navigate, causing mistakes. After helping a customer with an AppFlow configuration using the UI, I decided to look for another way and I’ve found one! Buried in some of Citrix’s documentation, there is a guide to configure AppFlow from the CLI. Today I’m going to walk you through that process.
What is AppFlow?
AppFlow is Citrix’s version of NetFlow. You’ve probably noticed by now that most vendors support NetFlow, but make it their own. This often leads to some device-specific fields and reports. Juniper has J-Flow, Cisco has NetFlow and Citrix has AppFlow.
AppFlow is closer to what you would expect from IPFIX. It includes fields like HTTP URLs, HTTP request and response status, response time, latency, and all standard fields.
What NetScaler devices are capable of AppFlow?
According to this Citrix doc, any NetScaler device using version 9.3 or higher with an nCore build can export AppFlow data.
Configure AppFlow
From the NetScaler CLI, run the below command to enable the feature:
enable ns feature AppFlow
Now specify the collector:
add appflow collector <name> -IPAddress <ipaddress> -port <port_number> -netprofile <netprofile_name>
Run the show command to confirm the collector is correct:
show appflow collector <name>
NOTE: According to Citrix documentation, you can add more than one collector by using the below commands:
add appflow collector <collector1> -IPAddress <IP> add appflow collector <collector2> -IPAddress <IP> add appflow action <action> -collectors <collector1> <collector2> add appflow policy <policy> true <action> bind lbvserver <lbvserver> -policy <policy> -priority <priority>
AppFlow Action
AppFlow action is used to send flow records to the collector(s) based on matching AppFlow policies.
Use the AppFlow action to tell the exporter to send flow data to the collectors of your choosing:
add appflow action <name> --collectors <string> ... [-clientSideMeasurements (Enabled|Disabled) ] [-comment <string>]
(Ex: add appflow action apfl-act-collector-1-and-3 -collectors collector-1 collecter-3).
Run the show command to ensure the action is set properly:
show appflow action
AppFlow Policy
*Keep in mind AppFlow actions must be configured before AppFlow policies.*
AppFlow policies are rules containing one or more expressions.
add appflow policy <name> <rule> <action>
(Ex: add appflow policy apfl-pol-tcp-dsprt client.TCP.DSTPORT.EQ(22) apfl-act-collector-1-and-3)
show appflow policy <name>
Do not forget the Bind!
There are two standard options for binding AppFlow policies. One is to create the bind globally so that it applies to all traffic. The second is to bind to specific virtual servers so that the policy applies only to the virtual server.
How to globally bind an AppFlow policy
To apply a policy globally run the following:
bind appflow global <policyName> <priority> [<gotoPriorityExpression [-type <type>] [-invoke (<labelType> <labelName>)] (Ex: bind appflow global af_policy_lb1_10.102.71.190 1 NEXT -type REQ_OVERRIDE -invoke vserver google).
Run the show command to ensure the policy is configured properly.
show appflow global
How to bind an AppFlow policy to a specific virtual server
Use the below command to bind to a specific virtual server:
bind lb vserver <name> -policyname <policy_name> -priority <priority> (Ex: bind lb vserver google -policyname af_policy_google_10.102.19.179 -priority 251).
For more on enabling AppFlow for virtual servers or AppFlow for a service, please follow Citrix’s AppFlow Guide (the section on virtual servers and AppFlow as a service can be found towards the end of the page).
I’ve got all this data; now what do I do with it?
Now that the data from your NetScaler exporters are making it to your collector, you can review all your new flow data to help you make decisions on network security and bandwidth usage.
Let’s take a look at some of the NetScaler-specific reports in Scrutinizer.
As you can see, AppFlow now appears in our report menu, offering even further insight into our network.
Here I’ve chosen to review AppFlow >> Connections to check RTT.
Looking through most of the reports supplied by AppFlow, we’ll find that they are largely network-based reports, like the one below showing requested URLs.
But since AppFlow sends IPFIX data, Scrutinizer can still use our native reports to filter and be proactive about potential security risk. Using our Flow Analytics algorithms for things like DDoS detection and creating our own thresholds and alerts for things like SSH connections to our servers, we’re able to reduce our Mean Time To Know.
For more information on how Scrutinizer can use the data exported by your Citrix NetScaler devices for network security and monitoring, reach out to our team or give Scrutinizer a go here.