Citrix – Netscaler – Rewrite – Force Secure and HttpOnly Cookies

Using the following article we stumbled upon a configuration where two cookies had been inserted in the response traffic from a web server.
This method instructs web browsers to only return the cookie value when the transmission is SSL-encrypted. This option can be used to prevent cookie theft through connection eavesdropping.
http://support.citrix.com/article/CTX138055
The configuration below ensures both actions are executed

ns-nsroot:11:30> sh ns runningConfig | grep -i secure_cookie
add rewrite action act_secure_cookie-upcaseP replace_all http.RES.full_Header “\”Path=/; Secure; HttpOnly\”” -search “regex(re!(Path=/\\; Secure; HttpOnly)|(Path=/\\; Secure)|(Path=/\\; HttpOnly)|(Path=/)!)” -bypassSafetyCheck YES
add rewrite action act_secure_cookie_lowcasep replace_all http.RES.full_Header “\”path=/; secure; httponly\”” -search “regex(re!(path=/\\; secure; httponly)|(path=/\\; secure)|(path=/\\; httponly)|(path=/)!)” -bypassSafetyCheck YES
add rewrite policy pol_secure_cookie-lowcasep “http.RES.HEADER(\”Set-Cookie\”).EXISTS” act_secure_cookie_lowcasep
add rewrite policy pol_secure_cookie-upcaseP “http.RES.HEADER(\”Set-Cookie\”).EXISTS” act_secure_cookie-upcaseP
bind cs vserver csw_extranet.example.co.za_80 -policyName pol_secure_cookie-lowcasep -priority 100 -gotoPriorityExpression NEXT -type RESPONSE
bind cs vserver csw_extranet-.example.co.za_80 -policyName pol_secure_cookie-upcaseP -priority 110 -gotoPriorityExpression END -type RESPONSE

Citrix – Netscaler – HA Pair Design

Attached is a basic design of a multi tenanted high available application delivery controller environment, using Citrix Netscaler as the chosen technology provider accelerating and optimizing different application frameworks.

Citrix NetScaler makes apps and cloud-based services run five times better by offloading application and database servers, accelerating app and service performance, and integrating security.

When deployed in front of web servers and database servers, The NetScaler combines high-speed load balancing and content switching, data compression, content caching, SSL acceleration, network optimization and application security on a single, comprehensive platform.

 

 

Citrix – Netscaler – Weblogging overview

You might find yourself in a situation where Edgesight isn’t able to provide performance metrics on certain applications due to its design. Example a non-browser based application; submitting HTTP/HTTPS traffic to and from backend servers.

The following diagram should assist providing a basic understanding of the components involved when configuring web logging.

Web logging is a mechanism used for making transaction data (performance metrics + events) available in a buffer for review.

Citrix – Netscaler – EdgeSight 2.1 overview

You might find the attached diagram very useful in providing a basic understanding of how Netscaler and Edgesight interact with end users, by showing browser level “web application” performance monitoring, helping to identify issues from any location and providing visibility into the origination of a problem.

Citrix – Netscaler – Trace that packet

There’s going to be a time when you’ll need to dig a little deeper into the flow of communication traversed through the Netscaler. I found the following commands and tools very helpful which I’m going to walkthrough a wee bit.

1# Show connectiontable,

Similar to getting directions from your Grandmother.

If you want to ensure that clients are establishing connection to your Virtual IP’s in quick and easy way, you can view the connection table on the Netscaler example below.

Figure 1.

Note: if you don’t want to use a expression filter you can simply use grep –i “” like the following

Command: show connectiontable | grep -i “10.7.?.113” |grep -i “HTTP”

2# nstcpdump,

Similar to Google maps it’ll get you there, but you might miss that off ramp.

A good way to view the network activity of a particular host you can use nstcpdump.sh which can be very helpful for low level troubleshooting.

– The benefit using this command is that it has the ability to send packet capture data directly live to standard output.

Note: The following Citrix KB will equip you with all you need to know

http://support.citrix.com/article/CTX118185

We found ourselves using nstcpdump when we needed to verify if any arp packets where being submitted via a particular gateway / route.

Figure 2. Remember to you’ll need to shell in 1st, -X option displays the content of each packet.

3# nstrace,

Pinpoint navigation the Tom, Tom of the Netscaler packet analysis world

At times, you might need the complete output of the nstrace.sh script for a full analysis of a particular issue.

– It allows capturing packets in the native trace format, which provides NIC device information including device number and whether the packet was transmitted or received.

– It provides connection link information, allowing for the identification of links between client to vserver and SNIP/MIP to server tcp connections.

Note: The following Citrix KB will equip you with all you need to know

http://support.citrix.com/article/CTX122294

And if ever in the situation where you’ll need to manually stop a trace process quick read the following

http://support.citrix.com/article/CTX128889

Figure 3. To stop a trace press Ctrl + C will kill the process within your putty session.

If your requirement is to see communication from all Netscaler owned IP addresses it’s properly better to execute the trace without any filters and within your packet analyzer perform the necessary filtering. You’ll need to download the trace file by using the GUI simply enough see the following.

Figure 5.

Note: Once you have downloaded that trace file, its packet analyzing time goto http://www.wireshark.org/

There are great video’s to get you started in understanding the utility some screens I have provided demonstrating this great tool.

Figure 6. Press Ctrl + F The following will assist you finding the source IP of your client requesting a particular service.

Figure 7. The following screen shot demonstrates the flow of communication from the client request to the backend servers. For easy of viewing you’ll be able to apply filters and even follow the TCP Stream.

I hope this has proven helpful.

Citrix – XenApp 6.5 – Installation Guide for Administrators

Welcome to our XenApp 6.5 Installation Guide for Administrators

1.0 XENAPP 6.5 DEPLOYMENT

This post is a configuration guide for an administrator to assist in joining a 2008 R2 server to a XenApp 6.5 Citrix Farm.

1.1 FARM DESIGN – OVERVIEW

Citrix – Netscaler – HA heartbeat traffic not seen on tagged/channeled network interfaces

If you optimizing traffic on a multi tenanted server network with numerous VLANs, while isolating management traffic, you might encounter a problem where heartbeat packets are not visible on all interfaces.

This is common on NetScaler high availability pairs, using Link Aggregation on ether-channel switch ports “in this example Cisco Switches”, the below demonstrates this issue intercepting these packets.

> force ha failover
[WARNING]:Force Failover may cause configuration loss, peer health not optimum. Reason(s):
– HA heartbeats not seen on some interfaces
Please confirm whether you want force-failover (Y/N)? [N]:N
: User requested abort
>

> show node
1) Node ID: 0
IP: 10.187.125.21 (ns01)
Node State: UP
Master State: Primary
Fail-Safe Mode: OFF
INC State: DISABLED
Sync State: ENABLED
Propagation: ENABLED
Enabled Interfaces : 0/1 LA/1
Disabled Interfaces : 1/8 1/7 1/6 1/4 1/3 1/2 0/2
HA MON ON Interfaces : 1/8 1/7 1/6 1/4 1/3 1/2 0/1 0/2 LA/1
Interfaces on which heartbeats are not seen : LA/1
Interfaces causing Partial Failure: None
SSL Card Status: UP
Hello Interval: 200 msecs
Dead Interval: 3 secs
Node in this Master State for: 0:21:42:50 (days:hrs:min:sec)
2) Node ID: 1
IP: 10.187.125.22
Node State: UP
Master State: Secondary
Fail-Safe Mode: OFF
INC State: DISABLED
Sync State: SUCCESS
Propagation: ENABLED
Enabled Interfaces : 0/1 LA/1
Disabled Interfaces : 1/8 1/7 1/6 1/4 1/3 1/2 0/2
HA MON ON Interfaces : 1/8 1/7 1/6 1/4 1/3 1/2 0/1 0/2 LA/1
Interfaces on which heartbeats are not seen : LA/1
Interfaces causing Partial Failure: None
SSL Card Status: UP
Local node information:
Critical Interfaces: 0/1 LA/1
Done

Heartbeat packets are being stopped by switches due to a vlan tagging mismatch, which is described in more detail in the following knowledge base article http://support.citrix.com/article/CTX109843

To overcome this issue you need to introduce an additional VLAN for HA heartbeat packets only on the LA/1 switch port side and not on the device interfaces, without this configuration VLAN 1 untagged HA traffic will be discarded, with other tagged frames.

HA heartbeats are always communicated on a native, untagged vlan (default VLAN 1 from Netscaler perspective). In our configuration, it is working fine for interface 0/1 because on the switch port side we have configured an access port vlan 115 (so the switch allows native packets as vlan 115).

LA/1 however has interfaces connect to trunked/tagged switch ports configured with vlan 100 allowed, LA/1 sends untagged HA heartbeat traffic as described above, but due to the switch’s configuration they are dropped.

You are required to have switch ports configured in a particular way to have native VLAN 115 visible in addition to tagged vlan 100 (the switchports will treat untagged HA heartbeats as vlan 115 and allow traffic to be submitted as seen in the Figure 1.).

Very important: After committing the attached actions, you need remove and recreate the HA pair “take note of the commands executed example -tagall OFF on all interfaces including the channel, disabling of all inactive interfaces etc”.

As mentioned in the knowledge base article provided earlier there are some switches which won’t work with this configuration, in this situation “which is less recommended by the vendor” review http://support.citrix.com/article/CTX110540 for more info.

Figure 1. HA pair Detailed Network View

Figure 2. HA pair Logical Network View

Citrix – Netscaler – Current Method Round Robin: LB Method is changed

If you’re not aware by design the Netscaler performs what is called a slow start to allow the backend services / servers to catch up under the following conditions.

• You configure a new metric-based load balancing method.
• You bind a service to the virtual server.
• The state of the server changes from DOWN to UP.

Read up the following article for more info which can offer some assistance http://support.citrix.com/article/CTX108886

Citrix – Netscaler – Clock Synchronization

Just a couple of tips when configuring time synchronization on a Citrix Netscaler ADC device, that isn’t too clear in the admin guides and seems to be tricky.

1. Log on to the NetScaler command line and execute the following.

“Ns command line”
add ntp server 10.7.100.17
enable ntp sync

2. Enter the shell command prompt and copy the ntp.conf file from /etc directory to /nsconfig directory “this file might already exist”, and verify the configuration.

“Shell command line”
cp /etc/ntp.conf /nsconfig
cat /nsconfig/ntp.conf

Figure 1. If the output is the following then refer to Figure 2. for assistance.

Figure 2. by making the below changes highlighted in yellow you are well on your way.

3. Important step: If the time difference between the NetScaler and the time server is more than 1000 sec, the ntpd service terminates. To avoid this, set the time manually on the device via the following command.

“Shell command line”
date +val YYMMDDHHMM

Where:
YY = Year
MM = Month
DD = Day
HH = Hour
MM = Minutes

4. Edit /nsconfig/rc.netscaler by adding the following entry highlighted in figure 4, just ensure this file exists.

Figure 3. using “vi” you’ll be able to make the below modifications. Don’t forget to press “i” for insert mode.

Figure 4. once you have entered the below entry, you might need to hit the return key before pressing “Esc” and “:wq!” to save your configuration.

5. And lastly, Reboot the NetScaler to enable clock synchronization.

If you want to query the time server to verfiy your configuration, shell into your netscaler once rebooted and type the following ntpdate -q <IP address or domain name of the NTP server>

Citrix – Netscaler – Creating a Custom HTTP Monitor with a Specific URL query string.

Just some basic points to take in consideration before binding that monitor to your service!

When Load balancing web servers or multiple instances of an application, you might require definition of the full URL path, query strings etc in order to generate an HTTP 200 response code.

Important Note: you need to have a clear understanding of what is being monitored. Most of this information can be obtained by viewing the URL Syntax used for a successful response.

If you’re unfamiliar with the structure and syntax of a Uniform Resource Locator you might find the following article useful

http://en.wikipedia.org/wiki/Uniform_Resource_Locator

Monitor Creation:
1. Command Line:
add lb monitor http-web1 HTTP -httpRequest “HEAD /callsomehting_v1wsdl”
# Some reason NS VPX appliance doesn’t accept “?” very odd.

2. GUI Interface > Load Balancing > Monitors

Once bound “using bind command” the monitor opens a connection to the service and periodically probes the HTTP services. If the server responds as expected within the configured time period, the monitor marks the service UP. If the service does not respond, or responds incorrectly, the monitor marks the service DOWN.