CNS 2

CNS-219-3i Citrix ADC 12.
x Traffic Management
Education
CNS-219-3i Citrix ADC 12.x Traffic Management
Lab Manual v1.4
1
Credits Page
Title Name
Architects Jesse Wilson
Product Managers Lissette Jimenez
Technical Solutions Developer Aman Sharma
Anton Mayers
Shruti V. Dhamale
Ravindra G. Hunashimarad
Rhonda Rowland
Offering Manager Jessica Hayner
Instructional Designer Jayshree Nair
Graphics Designer Ryan Flowers
Publication Services Rahul Mohandas
Special Thanks Layer8 Training
2
Contents
Credits Page ........................................................................................................................................................... 2
Lab Manual Overview ............................................................................................................................................. 5
Lab Environment Overview..................................................................................................................................... 6
Module 1: Classic Policies ....................................................................................................................................... 8
Exercise 1-1: Configuring Content Filtering with Classic Policies (GUI) ............................................................... 10
Exercise 1-1: Configuring Content Filtering with Classic Policies (CLI) ................................................................ 13
Module 2: Advanced Policies with HTTP callout and Rate limiting ......................................................................... 16
Exercise 2-1: Configuring HTTP Callout (GUI)..................................................................................................... 17
Exercise 2-2: Configuring Rate Limiting (GUI) .................................................................................................... 22
Exercise 2-1: Configuring HTTP Callout (CLI) ...................................................................................................... 26
Exercise 2-2: Configuring Rate Limiting (CLI) ..................................................................................................... 29
Module 3: Advanced Policies with Responder, Rewrite, and URL Transform .......................................................... 31
Exercise 3-1: Rewrite Policy - Modify a URL (GUI).............................................................................................. 33
Exercise 3-2: Rewrite Policy - Delete HTTP Headers (GUI).................................................................................. 37
Exercise 3-3: Rewrite Policy - Insert HTTP Headers (GUI) ................................................................................... 40
Exercise 3-4: Rewrite Policy - Convert URL Paths to Lowercase (GUI) ................................................................ 44
Exercise 3-5: Rewrite Policy – Modify the DNS Payload (GUI) ............................................................................ 48
Exercise 3-6: Rewrite Policy – Rewrite TCP header (GUI) ................................................................................... 52
Exercise 3-7: Responder Policy - Redirect to SSL (GUI)....................................................................................... 57
Exercise 3-8: Responder Policy - Redirect Using String Maps (GUI) .................................................................... 62
Exercise 3-9: Responder Policy - Redirect to Imported Maintenance Page (GUI) ................................................ 67
Exercise 3-10: Responder Policy- Respond to the DNS request (GUI) ................................................................. 74
Exercise 3-1: Rewrite Policy - Modify a URL (CLI) ............................................................................................... 77
Exercise 3-2: Rewrite Policy - Delete HTTP Headers (CLI) ................................................................................... 80
Exercise 3-3: Rewrite Policies - Insert HTTP Headers (CLI).................................................................................. 83
Exercise 3-4: Rewrite Policy - Convert URL Paths to Lowercase (CLI).................................................................. 85
Exercise 3-5: Rewrite Policy – Modify the DNS Response (CLI) ........................................................................... 88
Exercise 3-6: Rewrite Policy – Rewrite TCP header (CLI) .................................................................................... 91
Exercise 3-7: Responder Policies to Redirect to SSL (CLI) .................................................................................. 95
Exercise 3-8: Responder Policy - Redirect using String Maps (CLI) ...................................................................... 99
Exercise 3-9: Responder Policy to Redirect to Maintenance Page (CLI) ............................................................ 103
Exercise 3-10: Responder Policy- Respond to the DNS request (CLI) ................................................................ 108
Module 4: Content Switching.............................................................................................................................. 111
Exercise 4-1: Configure Content Switching by User Agent (GUI) ...................................................................... 112
3
Exercise 4-2: Configure Content Switching by Content Type (GUI) ................................................................... 118
Exercise 4-1: Configuring Content Switching by User Agent (CLI) ..................................................................... 123
Exercise 4-2: Configure Content Switching by Content Type (CLI) .................................................................... 127
Module 5: Optimization...................................................................................................................................... 131
Exercise 5-1: Configuring Compression Policies (GUI) ...................................................................................... 132
Exercise 5-1: Configuring Compression Policies (CLI) ....................................................................................... 137
Module 6: Global Server Load Balancing (GSLB) .................................................................................................. 142
Exercise 6-1: Configuring Active/Active GSLB (GUI) ......................................................................................... 145
Exercise 6-2: Testing GSLB with DNS Proxy Configuration (GUI)....................................................................... 155
Exercise 6-3: Configuring GSLB for Active/Passive Scenario (GUI) .................................................................... 158
Exercise 6-4: Configuring Active/Active GSLB (Using Wizard)........................................................................... 162
Exercise 6-1: Configuring Active/Active GSLB (CLI) .......................................................................................... 169
Exercise 6-2: Testing GSLB with DNS Proxy Configuration (CLI) ........................................................................ 177
Exercise 6-3: Configuring GSLB for Active/Passive Scenario (CLI) ..................................................................... 180
GSLB Troubleshooting Tips ............................................................................................................................. 183
APPENDIX A: Citrix ADC Counters ................................................................................................................... 184
APPENDIX B: Citrix Gateway Configuration ..................................................................................................... 185
Citrix Gateway (previously SWG)......................................................................................................................... 185
Exercise 1: Configuring Secure Web Gateway (Explicit Mode) (GUI) ................................................................ 186
Exercise 1: Configuring Secure Web Gateway (CLI).......................................................................................... 190
4
Lab Manual Overview

In this lab guide, you will get hands-on experience with Citrix ADC and its features.
This lab guide will enable you to work with product components and perform required and options configuration
steps for the AppExpert policy engine, Content Switching, Optimization, GSLB, and Citrix Gateway.
Before You Begin:
• This Lab Guide has been designed to explain you both the configuration modes, command line interface
(CLI) and Graphical User Interface (GUI). You are encouraged to explore both methods. However, we
recommend that you choose a method in the beginning of the exercise and continue with it throughout
the exercise for better understanding of the configuration.
• We have included optional exercises in this lab guide for extra practice. You are encouraged to explore
the exercises.
• Citrix ADC (Version 12) can be accessed using any browser. But for better demonstration of the use case
we suggest that you use Google Chrome for accessing Citrix ADC management page and Mozilla Firefox
for testing the configuration.
Tools Used:
• For SFTP access: WinSCP

• For Command Line Interface access: Putty
• For Packet Traces: Wireshark, Fiddler
5
Lab Environment Overview

LAB DIAGRAM:
SERVER LIST
Virtual Machine Name Domain FQDN IP Address Description
AD.training.lab ad.training.lab 192.168.30.11 Domain Controller (training.lab)

AD02.training.lab ad02.training.lab 192.168.30.12 Domain Controller 2 (training.lab)
LAMP_1 lamp1.training.lab 192.168.30.61 MYSQL Database server
LAMP_2 lamp2.training.lab 192.168.30.62 MYSQL Database server
WebRed webred.training.lab 192.168.30.51 Web Server
WebBlue webblue.training.lab 192.168.30.52 Web Server
WebGreen webgreen.training.lab 192.168.30.53 Web Server
WebRemote webremote.training.lab 172.22.15.41 Web Server
Http_Callout http_callout.training.lab 192.168.30.79 Web server
Student Desktop -- 192.168.10.10 Student lab workstation; landing
workstation. All labs performed
from this system.
6
CITRIX ADC LIST
Virtual NSIP Address Subnet IP (SNIP) Address Description

Machine Name
ADC_VPX_01 192.168.10.101 SNIP1: 192.168.10.111 (traffic) ADC_VPX_01 is the principal Citrix

SNIP2: 192.168.10.103 (mgmt.) ADC for most exercises. It will be in
an HA Pair with ADC_VPX_02, and
they will be managed via the shared
SNIP 192.168.10.103.
ADC_VPX_02 192.168.10.102 HA Pair: shared configuration Secondary member of HA Pair with
with ADC_VPX_01. ADC_VPX_01.
ADC_VPX_03 172.22.15.201 SNIP1: 172.22.15.211 Standalone Citrix ADC participating
in the remote-site network. It will be
used as the GSLB partner Citrix ADC
in Module 6.
CREDENTIALS LIST: Training Domain Users and Groups
User Name Groups Password Description
administrator Domain Admins Password1 Domain administrator account which can

be used to access domain controllers.
Otherwise, not needed in class.
trainNSAdmin Training_NSAdmins Password1 Domain account used in Citrix ADC
delegated administration exercise.
trainNSOperator Training_NSOperators Password1 Domain account used in Citrix ADC
delegated administration exercise.
trainADUser Domain Users Password1 Domain account used as LDAP BindDN
service account.
Contractor Contractors Password1 Domain account available for Citrix ADC
demonstrations.
CREDENTIALS LIST: Citrix ADC Local Accounts
User Name Delegated Admin Password Description

Role
nsroot superuser nsroot Built-in Citrix ADC account that will be

used for all exercises.
testuser custom Password1 Test account for delegated administration.
padmin1 Partition Admin Password1 Test account for Admin Partitions
exercise.
padmin2 Partition Admin Password1 Test account for Admin Partitions
exercise.
7
Module 1: Classic Policies

Introduction:
You are asked to temporarily implement a policy to drop unwanted requests to /red.php on the load balancing
virtual server for lb_vsrv_rbg. In this module, you will learn hands-on how to implement content filtering.
Content filtering allows you to prevent unwanted requests from reaching a protected server by comparing the
request against filters based on HTTP URLs or headers. Content filtering allows you to specify the action to take for
requests matching the filter rules. The content filter can be configured to DROP or RESET the request or to return
an error code in the response. You have control over which content to filter and how it is filtered.
The available qualifier options to configure the for content filter action are as follows:
ADD - Adds the specified HTTP header.
RESET - Terminates the connection, sending the appropriate termination notice to the user's browser.
FORWARD - Redirects the request to the designated service. You must specify either a service name or a page, but
not both.
DROP - Silently deletes the request, without sending a response to the user's browser.
CORRUPT - Modifies the designated HTTP header to prevent it from performing the function it was intended to
perform, then sends the request/response to the server/browser.
ERRORCODE. Returns the designated HTTP error code to the user's browser (for example, 404, the standard HTTP
code for a non-existent Web page).
In this module, you will perform hands-on exercises that will familiarize you with the core concepts of policy-based
features using the classic policy engine. In later exercises, you will work with the more advanced features of the
default policy engine.
After completing this lab module, you will be able to:
• Enable the Content Filtering feature.

• Create Classic Policy expressions using AppExpert and Expression Editor.
• Create Content Filtering policies.
• Bind the classic policies to a virtual server.
• Use Content Filtering to drop unwanted requests.
• Confirm that the implemented policy works.
This module contains the following exercise using the Citrix ADC Configuration Utility GUI and Citrix ADC CLI:
• Exercise: Configuring Content Filtering with Classic Policies.
Before you Begin:

Estimated time to complete this lab module: 15 minutes
8
Virtual Machines required for this module

For Module 1, connect to your assigned XenCenter console and verify that the following virtual machines are
running. If any of the virtual machines are not running, use XenCenter to turn them on. Otherwise, XenCenter will
not be needed for the rest of the module.
• ADC_VPX_01
• ADC_VPX_02
• WebBlue
• WebRed
• WebGreen
9
Exercise 1-1: Configuring Content Filtering with Classic Policies

(GUI)
Introduction:
In this exercise, you will configure a content filtering policy to drop traffic and to work with
policies and expressions using the classic policy engine. You will use the Configuration Utility to
perform this exercise.
The following are requirements that must be met by the end of this exercise:
• Requests for /red.php to the lb_vsrv_rbg (http://172.21.10.101) should be dropped.

• No other traffic should be affected by this policy on this virtual server.
• Requests for /red.php on other virtual servers will also not be affected.
In this exercise, you will perform the following task:
• Configure Content Filtering with Classic Policies.
Configuring Content Filtering with Classic Policies

Step Action
1. Open Google Chrome and Click on the bookmark for ADCMGMT SNIP to connect to the MGMT
SNIP at http://192.168.10.103.
Log on using the following credentials:
User Name: nsroot

Password: nsroot
2. Test connection to lb_vsrv_rbg first and verify that red.php loads:
• Open a web browser and find http://172.21.10.101/red.php

• Refresh a few times to verify that load balancing works.
3. Enable the Content Filter feature:
• Browse to System > Settings.

• Click Configure Basic Features.
• Verify if the Content Filter is enabled. If not, select content filter to enable the feature.
• Click OK.
4. Create a policy expression named red_url to identify URLs that contain /red.php using the classic
policy engine.
Create Classic Policy Expressions:
• Browse to AppExpert > Expressions > Classic Expressions.

• Click Add.
• Enter red_url in the Expression Name field.
• Click Expression Editor. The Add Expression dialog box opens.
10
5. Create the Expression using the Expression Editor (Classic syntax):

• Expression Type: General
• Flow Type: REQ
• Protocol: HTTP
• Qualifier: URL
• Operator: ==
• Value: /red.php
• Click Done and Create.
Final Expression:
REQ.HTTP.URL == /red.php
NOTE: Classic expressions can be written in the expression text box, but there is no interactive
syntax prompt like those in the default engine. Expressions can also be built using the Expression
Editor, which will use a structured approach to building the syntax based on drop-down list
boxes.
Basic structure for classic expressions are:

<flow>.<protocol>.<qualifier> [parameter] <OPERATOR> <value>
6. Create the content filter policy to drop requests to /red.php using the named expression:
• Browse to Security > Protection Features > Filter.

• Click the Filter Policies tab and click Add to create a new policy.
Configure the policy with the following settings:
• Enter cf_red_url in the Filter Name field.

• Select red_url from the Saved Policy Expressions drop-down list box.
• Select the Request Action radio button.
• Select DROP from the Request Action drop-down list box.
• Click Create.
• Click OK on the Warning.
11
7. Bind the policy cf_red_url to the virtual server lb_vsrv_rbg.
• Browse to Traffic Management > Load Balancing > Virtual Servers.

• Select lb_vsrv_rbg and click Edit.
• Click Policies under Advanced Settings to add the category to the left pane.
• Click "+" to create a new policy.
Choose Policy Type and Flow:
• Select Filter from the Choose Policy drop-down list box.

• Verify Request is selected as the Type.
• Click Continue.
Bind the policy to the virtual server:
• Click Click to Select Policy under select policy.

• Select cf_red_url and click Select.
• Let the priority be default, 100.
• Click Bind.
Click Done.
8. Test policy to drop /red.php content.
Open a Web browser and test the following URLs on lb_vsrv_rbg:
• Browse to http://172.21.10.101/home.php
Verify page and all content displays successfully.
• Browse to http://172.21.10.101/red.php
This page is not displayed; /red.php is dropped by Citrix ADC.
NOTE: Requests to /red.php are dropped from lb_vsrv_rbg.

9. View policy hits:
• Browse to Security > Protection Features > Filter.

• View the hits occurring for cf_red_url in the Policies pane.
NOTE: The policy hits will increase when the /red.php content is dropped. The policy does not
apply to other traffic.
10. Unbind the policy cf_red_url to the virtual server lb_vsrv_rbg.

• Click Filter Policies under the Policies category. The request-time filter policy bind point
for this load balancing virtual server is displayed.
• Select cf_red_url and click Unbind and Yes to confirm.
• Click Close.
• Click Done.
NOTE: The content filter policy is unbound so that it does not conflict with later exercises.
12
11. Save the Citrix ADC configuration and confirm.
• Click the Save icon (floppy disk) in the upper-right corner.
Key Takeaways:
• Content Filtering can be used to DROP or RESET connections. Content Filtering provides
basic traffic filtering capabilities. A few other actions are available, but these action
types can be replaced by Responder, Rewrite, or Content-Switching features.
• Classic policy expressions can be used with HTTP traffic to look at both REQUEST and
RESPONSE time flows.
• Classic policy expressions can be created at the time the policy is defined or created as
named expressions and reused.
• The policy scope is determined by both the bind point and the policy expression.
• Policies must be bound with the feature enabled, to be in effect.
Exercise 1-1: Configuring Content Filtering with Classic

Policies (CLI)
Introduction:
In this exercise, you will configure a content-filtering policy to drop traffic and to work with
policies and expressions using the classic policy engine. You will use the command-line interface
to perform this exercise.
Requirements for the scenario in this exercise:
• Requests for /red.php to the lb_vsrv_rbg (http://172.21.10.101) should be dropped.

• No other traffic should be affected by this policy on this virtual server.
• Requests for /red.php on other virtual servers will also not be affected.
In this exercise, you will perform the following tasks:
• Configure Content Filtering with Classic Policies
13
Configuring Content Filtering with Classic Policies

Step Action
1. Connect to Citrix ADC HA Pair using the ADCMGMT SNIP (192.168.10.103) using SSH (PuTTY).
• Use the PuTTY shortcut on the desktop of your Student Desktop OR

Start > Run > putty 192.168.10.103.
Log on to PuTTY using the following credentials:
User Name: nsroot

Password: nsroot
2. Test connection to lb_vsrv_rbg first and verify that red.php loads:
• Open a web browser and connect to http://172.21.10.101/red.php

• Refresh a few times to verify that load balancing works.
3. Enable Content Filtering feature:
enable ns feature cf
4. Create classic policy expression to identify /red.php:
add policy expression red_url "REQ.HTTP.URL == /red.php"

5. Create content filter policy to DROP traffic:
add filter policy cf_red_url -rule red_url -reqAction DROP

6. Bind policies to the load balancing virtual server lb_vsrv_rbg:
bind lb vserver lb_vsrv_rbg -policyName cf_red_url -priority 10

7. Test policies:
Open a Web browser and test the following URLs on lb_vsrv_rbg:
For the above URL, verify that the page and all content displays successfully.
• Browse to http://172.21.10.101/red.php
This page is not displayed; /red.php is dropped by Citrix ADC.
NOTE: Requests to /red.php are dropped from lb_vsrv_rbg.

8. View Policy Hits for the content filter policy:
show filter policy cf_red_url

9. Unbind the policy so that it does not affect later exercises:
unbind lb vserver lb_vsrv_rbg -policyName cf_red_url
NOTE: The content filter policy is unbound so that it does not conflict with later exercises.
14
10. Save the Citrix ADC configuration:
save ns config
Key Takeaways:
• Content Filtering can be used to DROP or RESET connections. Content Filtering provides
basic traffic filtering capabilities. A few other actions are available, but these action
types can be replaced by Responder, Rewrite, or Content Switching features.
• Classic policy expressions can be used with HTTP traffic to look at both REQUEST and
RESPONSE time flows.
• Classic policy expressions can be created at the time the policy is defined or created as
named expressions and reused.
• The policy scope is determined by both the bind point and the policy expression.
• Policies must be bound with the feature enabled to be in effect.
15
Module 2: Advanced Policies with HTTP callout and

Rate limiting
Introduction:
This module demonstrates the use of the default policy syntax, Advanced policy bind points
with HTTP call out and rate limiting.
Advanced Policies have following advantages over Classic policies:
• Perform fine-grained analyzes of network traffic from layers 2 through 7.
• Evaluate any part of the header or body of an HTTP or HTTPS request or response.
• Bind policies to the multiple bind points that the default syntax policy infrastructure
supports at the default, override, and virtual server levels.
• Use goto expressions to transfer control to other policies and bind points, as
determined by the result of expression evaluation.
• Use special tools such as pattern sets, policy labels, rate limit identifiers, and HTTP
callouts, which enable you to configure policies effectively for complex use cases.
Before you Begin:

Estimated time to complete this lab module: 30 minute

For Module 2, connect to your assigned XenCenter console and verify that the following virtual
machines are running. If any of the virtual machines are not running, use XenCenter to turn
them on. Otherwise, XenCenter will not be needed for the rest of the module.
• ADC_VPX_01 • WebBlue
• ADC_VPX_02 • WebRed
• HTTP_Callout • WebGreen
16
Exercise 2-1: Configuring HTTP Callout (GUI)
Overview:
This exercise demonstrates the configuration of an HTTP callout.
When the Citrix ADC appliance receives a client request, the appliance evaluates the request
against the policies bound to various bind points. During this evaluation, if the appliance
encounters the HTTP callout expression, SYS.HTTP_CALLOUT (<name>), it stalls policy
evaluation briefly and sends a request to the HTTP callout agent by using the parameters
configured for the specified HTTP callout.
Upon receiving the response, the appliance inspects the specified portion of the response, and
then either performs an action or evaluates the next policy, depending on whether the
evaluation of the response from the HTTP callout agent evaluates to TRUE or FALSE,
respectively.
Even though the Citrix ADC appliance does not check for the validity of the HTTP callout
request, it parses the request once before it sends the request to the HTTP callout agent.
However, during this parsing, the HTTP callout request can hit the same policy and therefore
invoke itself recursively. The appliance detects the recursive invocation and raises an undefined
(UNDEF) condition.
NOTE: In this exercise, we will be using the Responder feature to invoke HTTP callout, and
redirect the user to the error page. The Responder feature will be explained in detail in the next
module.
Diagram:
Scenario:
17
The ABC Company needs to implement a strict authorization policy for accessing the load
balancing virtual server. The database of the blacklisted clients is present on the HTTP callout
server (IP 192.168.30.79)
As a Citrix ADC Admin, you need to:
• Enable the Responder feature.

• Implement the HTTP Callout policy, so that the black listed clients will not be allowed to
access to the http://172.21.10.101.
• To avoid the issues due to HTTP recursion, insert the header Client IP.
Action
Step
1. View the default page ("/") on lb_vsrv_rbg:
• Open a web browser and find http://172.21.10.101/
NOTE: The default page displays serverindex, a Citrix logo, and Welcome.
2. Go to XenCenter check if the VM, HTTP_Callout is UP.
If the VM is Down, Right-click on the VM and Click Start.
3. Enable Responder Feature:
• Browse to AppExpert > Responder.

• If you observe a yellow icon (!) in front of the feature right-click Responder and select
Enable Feature.
• If not continue with the exercise, as the feature is already enabled.
18
4. Create an HTTP Callout to initiate a request to the blacklist server:
• Browse to AppExpert > HTTP Callouts.

• Click Add.
• In the Name field, enter Callout_Blacklist.
• Select the option next to IP Address and enter 192.168.30.79.
• In the Port field, enter 80.
• In the section Request to send to the server configure following:
• Confirm that Attribute-Based is selected under Request Type.
• Ensure that the Method drop-down box displays GET.
• In the Host Expression field, enter "http_callout.training.lab".
(**The quotes are required.)
• In the URL Stem Expression field, type "/cgi-bin/check_client.pl".
(**The quotes are required.)
Note: If you test this connection from the student desktop you will be blocked, but from the
ExternalClient you are allowed to access
• In the Headers section configure following:

• Click Insert.
• Enter callout in the Name field.
• Enter "negate" in the Value expression field.
• (**The quotes are required.)
• Click Insert.
• In the Parameters section, configure following:

• Click Insert.
• Enter cip in the Name field.
• Enter CLIENT.IP.SRC in the Value expression field.
• Click Insert.
• Keep the Scheme default, http.

• In the Server Response section, select TEXT from the Return Type drop-down list box.
• In the Expression to extract data from the response field, enter HTTP.RES.BODY(1000).
• Keep Cache Expiration Time (in secs) default.
NOTE: For improved performance while using callouts, we can use the integrated
caching feature to cache callout responses. The responses are stored in an integrated
caching content group named calloutContentGroup for a specified time duration.
• Click Create.
19
5. Import HTML Page
• Navigate to AppExpert > Responder > HTML Page imports

• Click Add
• In the Name field, enter Error_Page.
• In the Import From field, select File
• In the Local File field, click Choose File
• Browse to C:\Users\localuser\Desktop\Resources or This PC > Desktop > Resources.
• Select Error_Page.html, Click Open.
• Click Continue.
• Observe that the file contents have been imported to Citrix ADC.
• Click Done.
NOTE: If you get the Warning, “Command failed on secondary node, but succeeded on
primary node. Configuration will be synchronized to ensure secondary and primary have
same configuration.” Click OK.
6. Create Responder Action
• Navigate to AppExpert > Responder > Actions

• Click Add.
• In the Name field, enter blacklist_act.
• In the Type field, select Respond with HTML Page.
• In the HTML Page dropdown, select Error_Page.
Click Create.
7. Create Responder Policy:
• Browse to AppExpert > Responder > Policies.

• Click Add.
• In the Name field, enter blacklist_pol.
• In the Action field, select blacklist_act.
• In the Expression field, enter
HTTP.REQ.HEADER("host").CONTAINS("172.21.10.101")&&
SYS.HTTP_CALLOUT(Callout_Blacklist).CONTAINS("IP Matched").
• Click Create.
20
8. Bind Responder Policy:

• Click Responder Policy Manager.
• Click the drop-down below Bind Point and Select Load Balancing Virtual Server.
• Click the drop-down under Virtual Server and select lb_vsrv_rbg.
• Click Continue.
• Click in the field below Select Policy to select blacklist_pol.

• Click Select.
• Click Bind.
• Click Done.
9. Test HTTP Callout:
• Open Internet Explorer.

• Browse to http://172.21.10.101
• Verify you are redirected to the error page.
10. Unbind the Responder Policy:

• Click the drop-down below Bind Point and select Load Balancing Virtual Server.
• Click Continue.
• Select blacklist_pol and click Unbind.
• Click Yes to Confirm then click Close.
• Click Back icon to go to the main menu.
• Click Save on the upper-right menu bar to save the configuration. Click Yes to confirm.
Key Takeaways:
• HTTP Callouts can be used to make HTTP or HTTPS requests against a remote agent and
retrieve and parse the web response.
21
• While HTTP Callouts are often associated with filtering traffic as part of Responder or
Application Firewall policies, HTTP Callouts can be used with other default policy engine
features, including Rewrite and token-based load balancing.
• The HTTP Callout consists of three types of settings: the traffic destination by IP Address
or virtual server, the HTTP Request, and the output to evaluate in the HTTP Response.
• If the destination for the HTTP Callouts is down, the HTTP Callout does not get invoked
and returns an automatic "False" value. This could apply whether the callout points to a
direct IP Address destination or a virtual server. In most cases, this will result in the
policy where the Callout is referenced not being triggered. In most situations, it is
therefore recommended to point the HTTP Callout to a load balancing virtual server
with multiple bound services or a backup entity specified to avoid a single point of
failure.
Exercise 2-2: Configuring Rate Limiting (GUI)
Overview:
The Citrix ADC rate limiting feature provides the means to monitor the rate of traffic associated
with the entity and take preventive action, in real time, based on the traffic rate.
This feature is particularly useful when the network is under attack from a hostile client that is
sending the appliance a flood of requests. We can mitigate the risks that affect the availability
of resources to clients, and improve the reliability of the network and the resources that the
appliance manages.
Scenario:
The ABC Company needs to configure security policy to protect the load balancing virtual server
lb_vsrv_rbg from the flooding attack. Configure Citrix ADC Rate limiting feature to check, if
more than three requests from the same source IP for the same URL are seen within 15
seconds.
As a Citrix ADC Admin, you need to:
• Create a Limit Selector to identify the source IP address and the URL.
• Create a Limit Identifier to set a limit of 3 requests in a 15 second time slice.
• If the Rate Limit is reached, provide error page to the user using the Responder feature.
Step Action
22
• Open Internet explorer.

• Browse for http://172.21.10.101/home.php
• Reload the page in quick succession by hitting the reload button multiple times.
User Name: nsroot

Password: nsroot
3. Create a Limit Selector:
• Browse to AppExpert > Rate Limiting > Selectors.

• Click Add.
• In the Name field, Enter Limit_Sel.
• Click Insert.
• In the Expression field, Enter CLIENT.IP.SRC and click Insert.
• Click Insert.
• In the Expression field, Enter HTTP.REQ.URL.
• Click Insert.
• Click Create.
23
4. Create a Limit Identifier:
• Browse to AppExpert > Rate Limiting > Limit Identifiers.

• Click Add.
• In the Name field, Enter Limit_ID.
• In the Selector drop-down box, select Limit_Sel.
• In the Threshold field, Enter 3.
• In the Time Slice (msec) field, Enter 15000.
o
• Click Create.
5. Create Responder Action:
• Browse to AppExpert > Responder > Actions.

• Click Add.
• In the Name field, enter Limit_act.
• In the Type field, select Respond with HTML Page.
• In the HTML Page, select Error_Page.
• Keep Response code as 200.
• Click Create.

• Click Add.
• In the Name field, enter Limit_pol.
• In the Action field, select Limit_act.
HTTP.REQ.URL.EQ("/home.php")&& SYS.CHECK_LIMIT("Limit_ID")
• Click Create.
24

• Click the drop-down below Bind Point and Select Load Balancing Virtual Server.
• Click Continue.
• Click in the field below Select Policy to select Limit_pol.
• Click Select.
• Click Bind.
• Click Done.
8. Test Rate Limiting:

• Verify you are redirected to the error page, after every third Request.
9. Unbind the Responder Policy:

• Click the drop-down below Bind Point and select Load Balancing Virtual Server.
• Click Continue.
• Select Limit_pol and click Unbind.
• Click Yes to Confirm then click Close.
• Click Back icon.
• Click Save on the uppe- right menu bar to save the configuration.
• Click Yes to confirm.
Key Takeaways:
• The Rate Limiting feature is another protection feature of the Citrix ADC that can be
incorporated into default-policy engine features, like Responder, Application Firewall,
DNS, rewrite, and Integrated Caching. The feature is useful when filtering unwanted
traffic exceeding certain connection, request rate, or bandwidth thresholds during high-
volume traffic events associated with an attack.
• Selectors are optional filters that can be incorporated with Rate Limit Identifiers. The
Selectors provide a filter that can be used to categorize traffic. The Limit Identifier is
then used to specify the threshold of interest per category of traffic identified by the
selector.
• The Limit Identifier returns true when the threshold is exceeded. This allows the Limit
Identifier to trigger the required action in the policy it is associated with. Rate Limiting is
usually used to drop, reset, or redirect high threshold traffic exceeding the limit
identifier.
25
Exercise 2-1: Configuring HTTP Callout (CLI)
Overview
This exercise demonstrates the configuration of an HTTP callout.
When the Citrix ADC appliance receives a client request, the appliance evaluates the request
against the policies bound to various bind points. During this evaluation, if the appliance
encounters the HTTP callout expression, SYS.HTTP_CALLOUT(<name>), it stalls policy
evaluation briefly and sends a request to the HTTP callout agent by using the parameters
configured for the specified HTTP callout.
Upon receiving the response, the appliance inspects the specified portion of the response, and
then either performs an action or evaluates the next policy, depending on whether the
evaluation of the response from the HTTP callout agent evaluates to TRUE or FALSE,
respectively.
Even though the Citrix ADC appliance does not check for the validity of the HTTP callout
request, it parses the request once before it sends the request to the HTTP callout agent.
However, during this parsing, the HTTP callout request can hit the same policy and therefore
invoke itself recursively. The appliance detects the recursive invocation and raises an undefined
(UNDEF) condition.
NOTE: In this exercise, we will be using the Responder feature to invoke HTTP callout, and
redirect the user to the error page. The Responder feature will be explained in detail in the next
module.
Scenario:
The ABC Company has a strict authorization policy for accessing the lb vserver. The database of
the blacklisted clients is present on the HTTP callout server (IP 192.168.30.79).
26
As a Citrix ADC Admin, you need to
• Enable the Responder feature.

• Implement the HTTP Callout policy, so that the black listed clients will not be allowed to
access to the http://172.21.10.101.
• To avoid the issues due to HTTP recursion, insert the header Client IP.
Configure HTTP Callout

Step Action
• Open a web browser and find http://172.21.10.101/
NOTE: The default page displays "serverindex", a Citrix logo, and "Welcome".
2. Log on Citrix ADC Command Line Interface.
• Open PuTTY.exe from the student desktop.
• In the Saved session section, click ADC_HA_MGMTSNIP.
• Click Open.
• Log on with following credentials:
Login as: nsroot
Password: nsroot
3. Enable Responder Feature.
enable ns feature RESPONDER

Create the HTTP Callout policy.
4.
add policy httpCallout Callout_Blacklist
5. Set IP Address and Port of HTTPCallout server (hosting the blacklist).
Set policy httpCallout Callout_Blacklist -IPAddress 192.168.30.79 port 80

6. Set the expression to configure the HOST header in the request to the callout server using
the Callout Server IP.
set policy httpCallout Callout_Blacklist hostExpr "\"http_callout.training.lab\""

7. Set the expression to generate the URL stem for the literal string /check_client.asp.
set policy httpCallout Callout_Blacklist urlStemExpr "\“/check_client.pl\”"

8. Specify the Client-IP and callout headers to insert into the HTTP callout request. The Client-
IP header sends the client IP address to the HTTP Callout server to determine if the Client IP
matches the list of blacklisted IP addresses.
set policy httpCallout Callout_Blacklist headers callout("negate") -parameters

cip(CLIENT.IP.SRC)
9. Set the return type (return value) of the result from the HTTPCallout server.
set policy httpCallout Callout_Blacklist -returnType TEXT
27
10. Specify how the Citrix ADC should extract the response from the HTTP Callout server.
set policy httpCallout Callout_Blacklist resultExpr "HTTP.RES.BODY(1000)"

11. Import HTML Page
Please navigate to the GUI for this step only to import the HTML page
• Navigate to AppExpert > Responder > HTML Page imports

• Click Add.
• In the Name field, enter Error_Page.
• In the Import From field, select File.
• In the Local File field, click Choose File.
• Browse to C:\Users\localuser\Desktop\Resources or This PC > Desktop >
Resources.
• Select Error_Page.html, Click Open.
• Click Continue.
• Observe that the file contents have been imported to Citrix ADC.
• Click Done.
NOTE: If you get the Warning, “Command failed on secondary node, but succeeded on
primary node. Configuration will be synchronized to ensure secondary and primary have
same configuration.” Click OK.
add responder action Blacklist_redirect_Act respondwithhtmlpage Error_Page -

responseStatusCode 200
13. Create Responder Policy
add responder policy Blacklist_redirect_Pol

HTTP.REQ.HEADER("Host").CONTAINS("172.21.10.101") &&
SYS.HTTP_CALLOUT(Callout_Blacklist).CONTAINS("IP Matched")
14. Bind Responder Policy
bind lb vserver lb_vsrv_rbg -policyName Blacklist_redirect_Pol -priority 100

15. Test HTTP Callout

• Go to http://172.21.10.101/
• Verify that you are redirected to the error page.
16. Unbind the Responder Policy (We will be using the vserver lb_vsrv_rbg in the next exercises
so unbind the policy to avoid the confusion.)
unbind lb vserver lb_vsrv_rbg -policyName Blacklist_redirect_Pol
Key Takeaways:
• HTTP Callouts can be used to make HTTP or HTTPS requests against a remote agent and
retrieve and parse the web response.
28
• While HTTP Callouts are often associated with filtering traffic as part of Responder or
Application Firewall policies, HTTP Callouts can be used with other default policy engine
features, including Rewrite and token-based load balancing.
• The HTTP Callout consists of three types of settings: the traffic destination by IP Address
or virtual server, the HTTP Request, and the output to evaluate in the HTTP Response.
• If the destination for the HTTP Callouts is down, the HTTP Callout does not get invoked
and returns an automatic "False" value. This could apply whether the callout points to a
direct IP Address destination or a virtual server. In most cases, this will result in the
policy where the Callout is referenced not being triggered. In most situations, it is
therefore recommended to point the HTTP Callout to a load balancing virtual server
with multiple bound services or a backup entity specified to avoid a single point of
failure.
Exercise 2-2: Configuring Rate Limiting (CLI)
This exercise demonstrates the use of the Rate Limiting using Citrix ADC Command Line
Interface.
Overview
The Citrix ADC rate limiting feature provides the means to monitor the rate of traffic associated
with the entity and take preventive action, in real time, based on the traffic rate.
This feature is particularly useful when the network is under attack from a hostile client that is
sending the appliance a flood of requests. We can mitigate the risks that affect the availability
of resources to clients and improve the reliability of the network and the resources that the
appliance manages.
Scenario:
The ABC Company needs to configure security policy to protect the lb vserver
lb_vsrv_rbg from the flooding attack. Configure Citrix ADC Rate limiting feature to
check, if more than three requests from the same source IP for the same URL are
seen within 15 seconds.
29
As a Citrix ADC Admin you need to
• Create a Limit Selector to identify the source IP address and the URL.
• Create a Limit Identifier to set a limit of 3 requests in a 15 second time slice.
• If the Rate Limit is reached, provide error page to the user using the Responder feature.
Step Action
• Open Internet explorer.

• Browse for http://172.21.10.101/home.php

• In the Saved session section, click ADC_HA_MGMTSNIP.
• Click Open.
Login as: nsroot
Password: nsroot
3. Create a Limit Selector:
add stream selector Limit_Sel HTTP.REQ.URL CLIENT.IP.SRC

4. Create a Limit Identifier:
add ns limitIdentifier Limit_ID -threshold 3 -timeSlice 15000 selectorName Limit_Sel

add responder action Limit_act respondwithhtmlpage Error_Page -

responseStatusCode 200
add responder policy Limit_pol "http.req.url.eq(\"/home.php\") &&

sys.check_limit(\"Limit_ID\")" Limit_act
bind lb vserver lb_vsrv_rbg -policyName Limit_pol -priority 100

8. Test Rate Limiting

• Verify you are redirected to the error page, after every third Request.
9. Unbind the Responder Policy (We will be using the vserver lb_vsrv_rbg in the next exercises so
unbind the policy to avoid the conflicts.)
unbind lb vserver lb_vsrv_rbg -policyName Limit_pol
30
KeyTakeaways:
• The Rate Limiting feature is another protection feature of the Citrix ADC that can be
incorporated into default-policy engine features, like Responder, Application Firewall,
DNS, rewrite, and Integrated Caching. The feature is useful when filtering unwanted
traffic exceeding certain connection, request rate, or bandwidth thresholds during high-
volume traffic events associated with an attack.
• Selectors are optional filters that can be incorporated with Rate Limit Identifiers. The
Selectors provide a filter that can be used to categorize traffic. The Limit Identifier is
then used to specify the threshold of interest per category of traffic identified by the
selector.
• The Limit Identifier returns true when the threshold is exceeded. This allows the Limit
Identifier to trigger the required action in the policy it is associated with. Rate Limiting is
usually used to drop, reset, or redirect high threshold traffic exceeding the limit
identifier.
Module 3: Advanced Policies with Responder,

Rewrite, and URL Transform
Introduction:
This module demonstrates the use of the default policy syntax, default policy bind points, and
policy prioritization with the Responder and Rewrite features.
In this module, you will perform hands-on exercises to create a variety of Responder and
Rewrite policies that solve a number of problems encountered in production environments.
• Create and use a Rewrite policy to modify a URL.

• Create and use a Rewrite policy to insert and delete HTTP headers.
• Create and use a Rewrite policy to convert the case of URL paths.
• Create and use a Rewrite policy to modify the DNS response.
• Create and use a Rewrite policy to modify the TCP payload.
• Create and use a Responder policy to redirect to SSL.
• Create and use a Responder policy to redirect using String Maps.
• Create and use a Responder policy to redirect requests to a down virtual server to a
maintenance page.
• Create and use a Responder policy to respond to the DNS request.
31
This module contains the following exercises, using the Citrix ADC Configuration Utility GUI and
Citrix ADC CLI:
• Exercise: Rewrite Policy - Modify a URL

• Exercise: Rewrite Policy - Delete HTTP Headers
• Exercise: Rewrite Policy - Insert HTTP Headers
• Exercise: Rewrite Policy - Convert URL Paths to Lowercase
• Exercise: Rewrite Policy - Modify the DNS Response (Optional Exercise)
• Exercise: Rewrite Policy - Rewrite TCP payload (Optional Exercise)
• Exercise: Responder Policy - Redirect to SSL
• Exercise: Responder Policy - Redirect Using String Maps
• Exercise: Responder Policy - Redirect to Maintenance Page
• Exercise: Responder Policy- Respond to the DNS request (Optional Exercise)
Before you Begin:

Estimated time to complete this lab: 60-90 minutes
• Rewrite Exercises 3.1-3.4: 30-45 minutes

• Optional Rewrite Exercises 3.5-3.6 20-30 minutes
• Responder Exercises 3.7-3.7.9: 30-45 minutes
• Optional Responder Exercise 3.10 15-20 minutes

For Module 3, connect to your assigned XenCenter console and verify that the following virtual machines are
running. If any of the virtual machines are not running, use XenCenter to turn them on. Otherwise, XenCenter will
not be needed for the rest of the module.
• ADC_VPX_01 • WebGreen
• ADC_VPX_02 • Ad.training.lab
• WebBlue • AD02.training.lab
• WebRed
32
Exercise 3-1: Rewrite Policy - Modify a URL (GUI)
Introduction:
In this exercise, you will learn to use a rewrite policy to modify a URL. You will use the Configuration Utility to
perform this exercise.
Company ABC has noticed that the default page on the RBG virtual server is not the best landing page for their
users. They want you to implement a rewrite policy to direct default requests to /home.php without affecting
other traffic.
Rewrite policies can be used to insert, modify, or delete elements of a request or a response, which includes URLs,
Headers, and body content. In this scenario, the rewrite policy will be used to rewrite the path of the URL in the
original request from the client to a new destination path as the Citrix ADC submits the request to the server.
Requirements for this scenario:
• HTTP requests sent to the default page (/) should be modified to Browse to /home.php instead.
• The policy should not apply for any other requests.
• The policy will be used with the lb_vsrv_rbg only.
33
During this first exercise working with the default policy engine, take note of the following:
• How policies can be bound to global objects or virtual servers.

• Policy bind points must indicate the flow: request or response.
• Policy expressions based on HTTP elements must also indicate request (HTTP.REQ) or response
(HTTP.RES). It is easy to use the wrong expression or the wrong-bind point.
• Notice how the Rewrite feature can affect the request or response.
• View the Default Web Page.

• Use Rewrite to Modify a URL.
• Validate a Rewrite Policy.
Viewing the Default Web Page

Step Action
Open a web browser and find http://172.21.10.101/.
NOTE: The default page displays serverindex, a Citrix logo, and Welcome.
2. Compare to the home page ("/home.php") on lb_vsrv_rbg:
Open a web browser and find http://172.21.10.101/home.php.
NOTE: The home page displays the server color and home as the title with a corresponding home
graphic.
Using Rewrite to Modify a URL

Step Action
User Name: nsroot

Password: nsroot
34
2. Create a Rewrite action that will replace the URL path to the new value "/home.php".
• Browse to AppExpert > Rewrite > Actions.

• Click Add.
• Enter rw_act_sendtohome in the Name field.
• Select REPLACE in the Type field. This designates the type of rewrite action to perform.
Configure the target expression for the action. This identifies the element of the request to
replace. Enter the following in the Expression to choose target location:
HTTP.REQ.URL.PATH
Configure the value expression, which identifies what to replace the target with:
"/home.php"
• Click Create.
NOTE: Expression syntax entered in the GUI does not need to be quoted; the quotes will be
applied when the GUI executes the command. However, any values that are not expression
syntax must appear in quotes.
For assistance with creating expressions, you are encouraged to use the Expression Editor to
build expressions, instead of the inline editor.
3. Create a rewrite policy to replace the original URL only when users access the default path ("/").
• Browse to AppExpert > Rewrite > Policies.

• Click Add.
• Enter rw_pol_sendtohome in the Name field.
• Select rw_act_sendtohome in the Action field.
Configure the expression for the policy so that it only applies when the default path ("/") is
requested:
HTTP.REQ.URL.PATH.EQ("/")
Click Create.
35
4. Bind the rewrite policy to lb_vsrv_rbg:
• Click Policy Manager.
Select the bind point for lb_vsrv_rbg for HTTP Request-time traffic:
• Select Load Balancing Virtual Server from the Bind Point field.
• Select HTTP from the Protocol field.
• Select REQUEST from the Connection Type field.
• Select lb_vsrv_rbg from the Virtual Server field.
• Click Continue.
Bind the policy to this bind point:
• Click Click to Select under Select Policy.

• Select rw_pol_sendtohome and click Select.
• Enter 100 in the Priority field.
• Select Next in the GoTo Expression.
• Click Bind.
Click Done.
NOTE: The Policy Manager is accessible from the policy node for each feature (Responder,
Rewrite, Compression, and others). The Policy Manager can be used to access all the bind points
for the feature: Override global, Virtual Server-specific, and Default global. Policies can also be
bound to specific virtual servers from the virtual server properties.
Test Rewrite Policy: rw_pol_sendtohome

Step Action
1. Switch to Firefox and browse to http://172.21.10.101/
• Verify that content for /home.php is displayed, though only "/" appears in the browser
URL.
• Live HTTP Headers will display a 200 OK for the request to "/" and not indicate a
redirect (since one has not occurred).
NOTE: Using the rewrite policy, the client asks for "/" in the request to the virtual server. The
Citrix ADC then modifies the request sent to the server and fetches "/home.php". From the
client perspective, they receive the response associated with "/" and are not aware that a
different request was delivered. The rewrite is not visible to the end user.
2. Return to the AppExpert > Rewrite > Policies node and view the policy hits. Policy hits should
increase for each request to "/".
Click Refresh to update the display.

3. Switch to Firefox and confirm other URLs are not affected:
• Browse to http://172.21.10.101/blue.php
• Browse to http://172.21.10.101/media.php
4. Return to the AppExpert > Rewrite > Policies node and view the policy hits. Click Refresh.
No policy hits should occur for requests to other content.
36
Key Takeaways:
• Rewrite policies can be used to modify a request URL and rewrite the request between the Citrix ADC and
the Server. The modified URL is not returned to the user, so it does not display in the browser address bar
and it does not appear as a redirect. However, the content fetched by the modified request is displayed to
the user. Rewrite policies when use for this type of URL rewrite is somewhat transparent to the user.
• Multiple rewrite policies can apply to a single request or response transaction. When the policies are
bound, the GoTo expression must be set to NEXT to allow processing of additional policies.
• The rewrite was useful in this scenario to seamlessly change the requested URL to a new value. If you
need the user to be aware of the change in destination, then try using a Responder policy to redirect the
user.
Exercise 3-2: Rewrite Policy - Delete HTTP Headers (GUI)
Introduction:
In this exercise, you will learn to create a Rewrite policy to delete an HTTP header. You will use
the Configuration Utility to perform this exercise.
Company ABC has implemented a security policy that Web servers should not broadcast their
server platform and version in the returned HTTP responses. Some of the web application
owners have not yet updated their servers (or some servers were missed), so the company
would like you to get the Citrix ADC to remove these headers from the responses. Eventually,
this policy may be applied globally, but the company wants to test this on the lb_vsrv_rbg only
first.
The Rewrite policy configuration in this scenario should meet the following requirements:
• Remove the Server header from HTTP responses.

• Ensure that the policy only applies to lb_vsrv_rbg initially.
About Rewrite Policy Action Types:
There are many rewrite action types. The Insert and Replace action types need to be configured
with a target for where to begin the insert action or a target identifying what to replace. Then
these actions get a value for what to insert at the target location or a value for what to replace.
Delete actions are simpler. The delete actions need to identify the target for what to delete.
There is no replacement value.
This exercise demonstrates the use of the DELETE_HTTP_HEADER to delete an HTTP header
specifically. The Delete action type could also have been used; it can be used to delete headers
or other elements of a request or a response.
37
• View the Default Headers.

• Create a Rewrite Policy to Delete the Server Headers.
View the Default Headers

Step Action
1. Open the Firefox browser in the Student Desktop.
During this exercise, you will switch between the Citrix ADC CLI and Firefox.
2. Open Live HTTP Headers:
• In Firefox, Open Live HTTP Headers: Tools > Live HTTP Headers.
• Verify that Capture is enabled on the Headers tab.
• Click Clear to clear the capture windows as needed.
NOTE: The Add-on Live HTTP Headers will be used with Firefox during this exercise. For
convenience, Live HTTP Headers is also added to the Chrome browser in the lab; however, lab
steps will not reference this configuration explicitly.
3. Browse to http://172.21.10.101/home.php and view Request and Response headers in Live
HTTP Headers.
Use Live HTTP Headers to view the header information for the /home.php request (at top of list).
• The request contains the HTTP Method (Get); the target (/home.php); Host header; and
user-agent headers, among others.
• The response contains the response code and message (200 OK) and a Server header
indicating that content came from an Apache server.
Create a Rewrite Policy to Delete the Server Header

Step Action
1. Open Google Chrome and Click on the bookmark for ADCGMT SNIP to connect to the MGMT
User Name: nsroot

Password: nsroot
2. Create a Rewrite action to delete the response-time header "server":

• Click Add.
• Enter rw_act_removesrvid in the Name field.
• Select DELETE_HTTP_HEADER from the Type drop-down list box.
• Enter Server in the Header Name field.
Click Create.
38
3. Create a Rewrite policy that will run for all http responses:

• Click Add.
• Enter rw_pol_removesrvid in the Name field.
• Select rw_act_removesrvid from the Action drop-down list box.
Configure the expression for the policy so that it applies to any valid HTTP Response.
HTTP.RES.IS_VALID
Click Create.
4. View policy bindings from the load balancing virtual server properties for lb_vsrv_rbg:
In the previous exercise, the policy manager was used to bind the policy to the specific load
balancing virtual server. In this exercise, bind the policy from the lb vserver properties.

Access the policy bindings for the virtual server:
• View the Policies category. Verify that the summary view shows 1 Rewrite Policy bound
under Request Policies.
• If an additional policy needed to be bonded to the Request-time: Rewrite policies bind
point, then clicking the existing Rewrite Policy will allow you to bind additional Rewrite
policies to the request-time processing bank.
• However, for this exercise, the Rewrite policy must be bound to the response-time
bank. As a result, the new policies option must be used to access all policy types and
processing flows.
NOTE: Policies can also be bound to virtual servers using the Policy Manager for that feature,
which can also bind to Override Global and Default Global bind points. This exercise
demonstrates binding policies using the virtual server properties, as the process of selecting the
bind point requires selecting the correct feature and flow as well.
5. Bind the policy as a Rewrite: Response-time policy on this virtual server:
Select the type of policy to bind:
• Click the + next to Policies to add new policies of any type to the load balancing virtual
server.
• Select Rewrite from the Choose Policy drop-down list box.
• Select Response from the Choose Type.
• Click Continue.
Bind the policy to this bind point:

• Select rw_pol_removesrvid and click Select.
• Select NEXT in the GoTo Expression.
• Click Bind.
• Click Done.
39
6. Switch to Firefox and test the policy:
• Click Clear in Live HTTP Headers to clear the capture window. Keep it open.
• Browse to http://172.21.10.101/home.php and view Request and Response headers in
Live HTTP Headers.
Verify that the Server header no longer appears in the response for any object
7. View the policy hits:

• View the policy hits for the rw_pol_removesrvid policy.
Policy hits should increase for all web requests on lb_vsrv_rbg as each request generates a
response, which contains a Server header. The policy will ensure that it is removed and no longer
displays to the client.
Requests to other virtual servers (HTTP) will still result in Server headers being present as traffic
on the other virtual servers are not affected by this policy.
Key Takeaways:
• A Rewrite action that targets a response object must be bound to a response-time policy
bind point.
• The Delete_HTTP_Header action targets the entire HTTP header (name and value). The
Delete action targeting an HTTP Header will usually delete the value but leave the
header name behind.
• If a request or a response contains duplicate headers, the policy will only delete the first
instance of the header it finds.
Exercise 3-3: Rewrite Policy - Insert HTTP Headers (GUI)
Introduction:
In this exercise, you will learn to use a Rewrite policy to insert an HTTP header into a response.
You will use the Configuration Utility to perform this exercise.
Company ABC decided that a generic header should be used instead of deleting the server
header completely.
The Rewrite policy in this scenario should meet the following requirements:
• Insert a new HTTP response header named "Server" with a generic value of
"Unspecified" to obscure the server platforms in use.
40
• Ensure that this policy (rw_pol_newsrvid) and the previous policy (rw_pol_removesrvid)
both apply to the request. As a result, the insert header policy rw_pol_newsrvid must
run after the delete header policy.
IMPORTANT: Do not replace the server header or other response content with strings or
phrases such as "Hack this" or "Try to hack me now." Potential legal implications with such a
statement may exist because you could be granting permission to hackers to attempt to violate
your security. As always, consult the appropriate security experts within your organization for
guidelines and requirements for your environment.
This scenario could also have been done by using a single REPLACE action instead of a separate
DELETE_HTTP_HEADER and INSERT_HTTP_HEADER action.
• Create Rewrite Policy to Insert New Header.
Create Rewrite Policy to Insert New Header

Step Action
User Name: nsroot

Password: nsroot
2. Create a Rewrite action to insert a new response-time header "Server".

• Click Add.
• Enter rw_act_newsrvid in the Name field.
• Select INSERT_HTTP_HEADER from the Type drop-down list.
• Enter Server in the Header Name field as the target.
• Enter "Unspecified" in the expression field as the value to insert. Include the quotes.
• Click Create.
3. Create a Rewrite policy that will run for all HTTP responses and insert the new header:

• Click Add.
• Enter rw_pol_newsrvid in the Name field.
• Select rw_act_newsrvid from the Action drop-down list box.
Configure the expression for the policy so that it applies to any valid HTTP Response.
HTTP.RES.IS_VALID
• Click Create.
41
4. Use the Rewrite Policy manager to bind the policy to the lb_vsrv_rbg Response-time bind point.
Open the Policy Manager.
Select the bind point for lb_vsrv_rbg for HTTP Response-time traffic:
• Select RESPONSE from the Connection Type field.
• Click Continue.
5. Bind the policy to this bind point:
• Click Add Binding.

• Select rw_pol_newsrvid and click Select.
• Click Bind.
• Click Close.
• Click Done or the icon for Back.
• Click Clear in Live HTTP Headers to clear the capture window. Keep this open.
• Browse to http://172.21.10.101/home.php and view the Request and Response
headers in Live HTTP Headers.
Verify that a new header named Server with the value "Unspecified" appears at the end of the
response header section.
NOTE: Make sure that multiple Server headers or one with combined values (original value,
Unspecified) are not present. This could be an indicator that the policy processing order is
incorrect.
Key Takeaways:
• Rewrite policies are evaluated against the original unmodified request or response.
• When multiple Rewrite policies apply, they apply all at once.
• Output from one policy cannot be input to another on the same request or response.
• The same header cannot be modified by multiple policies in the same request or
response.
This does not exactly apply to the last two exercises because technically the delete
action and the insert action are working on two separate instances of the Server header.
This limitation impacts the replace action types more often.
42
43
Exercise 3-4: Rewrite Policy - Convert URL Paths to Lowercase

(GUI)
Introduction:
In this exercise, you will learn to use a Rewrite policy to convert URL paths to lowercase for
case-sensitive paths. You will use the Configuration Utility to perform this exercise.
Company ABC has received complaints from users that when they try to Browse the RBG web
site, sometimes it works and sometimes it does not. While investigating the issue, the senior
administrator realized that during the recent Web server migration, the web platform had
changed from IIS to Apache. As a result, users were requesting invalid URLs due to the fact that
the Apache URL paths are now case-sensitive. The Web server administrator has promised to
update the Apache configuration so that it does not treat paths as case-sensitive. However, the
administrator is on vacation for another week, so you have been asked to fix it now.
Users notice that requests to the following URLs are failing because the actual objects should
be lower case. Here are some examples:
Invalid Requests Required Value
/Home.php /home.php
/images/Red_home_top.JPG /images/red_home_top.jpg
/Dist_Red.php /dist_red.php
/MEDIA.php /media.php
The plan is to use a Rewrite policy to convert all URL paths to lowercase for this application. For
the RBG site, this will work because all of the paths and objects on the server are lowercase.
Therefore, the Rewrite policy in this scenario should meet the following requirements:
• Rewrite the original URL in the request to all lowercase.

• Apply the policy to lb_vsrv_rbg only.
• Use a policy expression to ensure that the policy runs only when needed, meaning when
the request contains uppercase letters. (Hint: This is going to require a regular
expression.)
This policy is actually quite similar to the first Rewrite policy in the send-to-home example
(rw_pol_sendtohome). The policy action needs to rewrite the URL path in the original HTTP
request. Therefore, this policy will use a replace action type and the action target should
identify the originating URL (or URL Path).
The main difference in this scenario and the earlier exercise is the criteria for when this policy
should apply. The policy will still be bound to the lb_vsrv_rbg. All requests sent to this virtual
44
server will be compared against this policy. To avoid running the policy for every request and
forcing the Citrix ADC to rewrite every URL, the expression for this policy will only run if
uppercase letters are present. If the request already contains the correct URL path, there is no
need for Rewrite to apply.
To detect whether a string like a URL contains any uppercase letters, a regular expression will
be used. The expression is provided in the exercise.
About Regular Expressions in Default Policy Syntax:
Citrix ADC uses PCRE syntax for its regular expressions. The raw regex to identify uppercase
letters in a string is:
[A-Z]+
This expression identifies if any character in the range Uppercase A-to-Uppercase Z Is present.
The "+" at the end means "one or more of the preceding". The expression will match if one or
more capital letters is present in the request.
When integrating a regular expression with a default policy expression, the Citrix ADC requires
that the regex is included within its own delimiter within the expression syntax.
Expression Example Details
http.req.url.contains("somestring") No regex in this example.
The operator contains takes a string value somestring in

quotes.
http.req.url.REGEX_MATCH(re/ /) Regex syntax example:

operator(re<delimiter><regexpattern><delimiter>
Regular Expressions in a policy operator always begins

with re.
The forward slash "/" is then used to mark the start and
end of the regular expression pattern as the delimiter.
45
http.req.url.REGEX_MATCH(re/[A-Z]+/) Example with actual regex included:
The regex: [A-Z+

is contained within the regex delimiter: re/ /
This expression will look to see if the request URL

contains a regex match for one or more uppercase
letters.
• If the match is true, the policy applies and we
can convert to lowercase.
• If the match is false, there are no uppercase
letters and the policy does not apply.
• Configure Rewrite to Transform URLs to All Lowercase.
Configure Rewrite to Transform URLs to all lowercase

Step Action
1. Verify original behavior.
• Open Firefox and find http://172.21.10.101/home.php

This should work as expected.
• Open Firefox and find http://172.21.10.101/Home.php (note case).

This should fail with a 404 Not Found error saying the content was not found on the
server.
The Apache Web server is case-sensitive, so /Home.php is a distinct object from /home.php. IIS
is not case-sensitive with regards to path and file names.
2. Create a Rewrite policy action to transform a URL path to all lowercase elements.

• Click Add.
• Enter rw_act_replacepath_lowerc in the Name field.
• Select REPLACE in the Type field. This designates the type of Rewrite action to perform.
The REPLACE action requires that a target for the replacement be identified and then the
replacement value is specified. Target and value are default policy syntax.
HTTP.REQ.URL
Configure the value with which to replace the target. Enter this expression in the Expression to
replace with field:
HTTP.REQ.URL.HTTP_URL_SAFE.TO_LOWER
• Click Create.
46
3. Create the Rewrite policy to perform transform only for URLs with path elements, only when
uppercase letters are present in the URL.

• Click Add.
• Enter rw_pol_replacepath_lowerc in the Name field.
• Select rw_act_replacepath_lowerc in the Action field.
Configure the policy expression so that it only applies to paths that contain uppercase letters.
This way the policy is only processed when required. This requires including a regular expression
value in the default policy syntax. Enter the following in the Expression field:
HTTP.REQ.URL.REGEX_MATCH(re/[A-Z]+/)
Click Create.
4. Use the Rewrite Policy manager to bind the policy to the lb_vsrv_rbg Request-time bind point.
Open the Policy Manager.
Select the bind point for lb_vsrv_rbg for HTTP Response-time traffic:
• Select REQUEST from the Connection Type field.
• Click Continue.
• Select rw_pol_replacepath_lowerc and click Select.
• Click Bind.
• Click Close.
• Click Done or click Back icon.
7. Test the policy:

• Open Firefox and find http://172.21.10.101/Home.php (note case).
This should now succeed without error.
Other URLs could include:
• http://172.21.10.101/Dist_Red.php (normally dist_red.php).

• http://172.21.10.101/mEDIa.PHP
All content should be properly displayed without issue.
47
Key Takeaways:
• Regular string comparison operators like contains(), eq(), before_str(), after_str() and
others can provide a lot of sophisticated string parsing with the default policy engine on
the Citrix ADC. When needed, though, the Citrix ADC can use regular expressions for
more complex string comparisons with regex operators like regex_match() and others.
• String comparison operators are quicker to evaluate than the regex operators, so only
use regex operators when necessary.
• Rewrite policies are useful for modifying requests and responses in situations in which
the correction can be made without having to explicitly convey the correction to the
user for the user to make a new request.
Exercise 3-5: Rewrite Policy – Modify the DNS Payload (GUI)

(Optional Exercise)
Introduction:
This exercise is optional; no class time will be allotted to complete it but you are encouraged to
utilize any free time during the course to complete it.
We can implement rewrite feature to manage the flow of DNS requests, and make necessary
modifications in the header, or in the answer section.
Rewrite Action Types for DNS:
• replace_dns_answer_section—This action replaces the DNS answers section with the

defined expression in the DNS policy.
• replace_dns_header_field—Checks the opcode type in the DNS request. Returns True or
False, indicating whether the opcode type in the DNS request matches the specified
opcode type. This action replaces the DNS header section with the defined expression in
the DNS policy.
Limitations:
• Rewrite policies are evaluated only if the Citrix ADC appliance is configured as a DNS
proxy server and there is a cache miss.
• If the Recursion Available (RA) flag in the header is set to YES, the RA flag will not be
modified in the rewrites.
• If the RA flag in the header is set to YES, the CD flag in the header is modified regardless
of any rewrite action.
48
Step Action
1. Connect to Citrix ADC HA Pair using the ADC_HA_MGMT SNIP (192.168.10.103) using SSH
(PuTTY). Log on using the following credentials:
User name: nsroot

Password: nsroot
2. Enter the shell prompt:
shell
3. Test the DNS resolution using dig:
dig yahoo.com @172.21.10.102
Observe that the DNS resolution is successful and the flags set are qr rd.
4. Exit the shell prompt:
exit
5. Connect to the Citrix ADC GUI at http://192.168.10.103 from Google chrome.
User Name: nsroot

Password: nsroot
6. Configure Rewrite Action to set AA bit of the DNS response:

• Click Add.
• Enter rw_set_aa_act in the Name field.
• Select REPLACE_DNS_HEADER_FIELD in the Type field. This designates the type of
Rewrite action to perform.
• In field Expression to choose the target location, enter
• dns.res.header.flags.set(aa) Click Create.
49
7. Configure Rewrite Policy:

• Click Add.
• Enter rw_set_aa_pol in the Name field.
• Select rw_set_aa_act in the Action field.
• Enter Expression as true.
• Click Create.
8. Bind Policy to the vserver lb_vsrv_dns:
• Browse to AppExpert > Rewrite > Policies

Select the bind point for lb_vsrv_dns for HTTP Response-time traffic:
• Select DNS from the Protocol field.
• Select lb_vsrv_dns from the Virtual Server field.
• Click Continue.

• Select rw_set_aa_pol and click Select.
• Click Bind.
• Click Done or Back icon.
10. View DNS Settings
• Browse to Traffic Management > DNS.

• In the settings section, click Change DNS settings.
• Observe that the default settings for the DNS Cache.
• Click OK.
NOTE: Rewrite policies are evaluated only if the Citrix ADC appliance is configured as a DNS
11. Switch to the Citrix ADC CLI connection and enter the shell prompt:
shell
50
dig yahoo.com @172.21.10.102
Observe that the DNS resolution is successful. and the flags set are : qr aa rd
exit
14. Unbind Policy to the vserver lb_vsrv_dns:

Select the bind point for lb_vsrv_dns for HTTP Response-time traffic:
• Click Continue.
15. Unbind the policy to this bind point:
• Select rw_set_aa_pol and click Unbind.

• Click Close.
Key Takeaways:
• The Rewrite Action Types available for DNS are replace_dns_answer_section and
replace_dns_header_field.
51
Exercise 3-6: Rewrite Policy – Rewrite TCP header (GUI)

(Optional Exercise)
Introduction:
In this exercise, you will learn to insert the client ip in the TCP header using rewrite policy.
For the protocols like HTTP, SIP, the protocol has headers available to insert the client
information. However, in case when the virtual servers are configured to implement using TCP
/SSL Bridge, Citrix ADC does not inspect/modify the application payload. Hence, in order to
maintain the transparent communication we need to use the TCP rewrite.
Scenario:
The company ABC has configured virtual server to load balance the LDAP servers.
They need to record the client ip address to the backend server.

As a Citrix ADC administrator, you need to:
• Create Rewrite policy to enter the client IP before the start of the data.
• Bind the policy to lb_vsrv_ldap.
Step Action
1. Connect to Citrix ADC HA Pair using the ADC_HA_MGMT SNIP (192.168.10.103) using SSH (PuTTY).
User name: nsroot

Password: nsroot
2. Configure Rewrite Action to insert the Client in the TCP header:

• Click Add.
• Enter rw_insert_tcp_act in the Name field.
• Select INSERT_BEFORE in the Type field. This designates the type of Rewrite action to
perform.
• In field Expression to choose the target location, enter client.TCP.PAYLOAD(1).
• In the Expression field, enter "From Client: "+client.IP.SRC
(The quotes are mandatory. Please do not use copy paste option to enter the expression as
word formatting may make the expression invalid.)
• Click Create.
52
3. Configure Rewrite Policy:

• Click Add.
• Enter rw_insert_tcp_pol in the Name field.
• Select rw_insert_tcp_act in the Action field.
• Enter Expression as true.
• Click Create.
4. Bind Policy to the vserver lb_vsrv_ldap:

Select the bind point for lb_vsrv_ldap for HTTP Response-time traffic:
• Select TCP from the Protocol field.
• Select Client from the Connection Type field.
• Select lb_vsrv_ldap from the Virtual Server field.
• Click Continue.

• Select rw_insert_tcp_pol and click Select.
• Click Bind.
6. Perform Test
Connect to the ADC_VPX_01 via PuTTY to run the trace
• Launch the PuTTY.exe icon from the student desktop.

• Select the ADC_VPX_01 and select Open.
• Use credentials nsroot/nsroot
Start Citrix ADC Trace
start nstrace -size 0 -traceFormat PCAP -filter

(connection.ip.eq(192.168.10.10)&&connection.port.eq(389)) -link ENABLED
• To Generate test traffic

o Open command prompt.
o Type telnet 172.21.10.103 389 and hit the Enter key to establish the connection.
o Hit any key from the keyboard.
o The telnet connection will be terminated
• Stop the Citrix ADC Trace

stop nstrace
53
7. Download Trace file:

• Open WinSCP and connect to Citrix ADC SNIP (NSMGMT SNIP) using credentials
nsroot/nsroot.
• In the right-pane, browse to the /var/nstrace/ directory.
Use the top icon to move up a directory level until you reach "/" (root), then browse to
/var/nstrace/.
Open the folder with the date on which the exercise is performed.
• In the left pane, browse to C:\Resources\ on the Student Desktop.

• Copy the nstrace1.cap file to the Resources folder.
• Close WinSCP.
8. Open Trace file:
• Browse to C:\Resources\ on the Student Desktop.
• Open the file nstrace1.cap in Wireshark.
54
9. Analyze the trace file.
• Locate the [PSH-ACK] packets from client to vserver and snip to backend
• Right-Click on the [PSH,ACK] from 192.168.10.10 -172.21.10.103

• Go to Follow > TCP Stream.
• WireShark Follow TCP Stream window will appear. Observe that it does not have the Client
IP.Click Close.
• Clear the Wireshark filter.
• Right-Click on the [PSH,ACK] from 192.168.10.111 -192.168.30.12

• Go to Follow > TCP Stream.
• WireShark Follow TCP Stream window will appear. Observe that the Client IP has been
inserted.
10. Close Wireshark.
55
11. Unbind Policy to the vserver lb_vsrv_ldap:

Select the bind point for lb_vsrv_ldap for HTTP Response-time traffic:
• Select TCP from the Protocol field.
• Select Client from the Connection Type field.
• Select lb_vsrv_ldap from the Virtual Server field.
• Click Continue.
• Select rw_insert_tcp_pol and click Unbind.

• Click Close.
13. Save Citrix ADC configuration and confirm.
Key Takeaways:
• TCP rewrite helps rewrite data in TCP payload. Thus to make TCP based Apps end-client
aware we can insert the client IP into the TCP payload going to the backend TCP App
using TCP rewrite.
• Target expressions in actions for TCP rewrite must begin with the expression prefixe
CLIENT.TCP.PAYLOAD. or SERVER.TCP.PAYLOAD.
56
Exercise 3-7: Responder Policy - Redirect to SSL (GUI)
Introduction:
In this exercise, you will learn to create a Responder policy to redirect HTTP requests to HTTPS.
You will use the Configuration Utility to perform this exercise.
Company ABC is not happy with an earlier solution. The application ssl_vsrv_rbg
(172.21.10.105) is configured properly to accept user requests over HTTPS. As this is supposed
to be a sensitive application, all content should be on HTTPS only. During the initial rollout, a
load balancing virtual server on HTTP:80 (lb_vsrv_rbg_sslredirect) was implemented in a down
state to act as a redirect to the SSL vserver using the redirect URL property. While this solution
meets the requirements of redirecting all HTTP requests to HTTPS and preventing access to the
application over HTTP, it also causes a DOWN virtual server to be displayed in the console,
dashboard, and reports. SNMP alerts are also being generated for this DOWN entity.
You have been asked to change the configuration so that all requests to http:// are redirected
to https for the 172.21.10.105 virtual server, but the HTTP listener should remain in an UP state
instead of DOWN.
The requirements for this scenario are:
• Keep lb_vsrv_rbg_sslredirect (172.21.10.105:HTTP:80) in an UP state, but do not allow it

to pass traffic to the backend servers over HTTP.
• All requests to lb_vsrv_rbg_sslredirect (HTTP) should be redirected to ssl_vsrv_rbg
(HTTPS) and without changing the original user request URL, path, or query parameters
when the Redirect is performed.
The Responder Policy Redirect action is a simple way to redirect an HTTP to HTTPS request. The
Redirect action generates a 302 Moved Temporarily response code. The action just needs the
Redirect destination, which will appear in the response's Location header.
• Prepare the HTTP Load Balancing Virtual Server.

• Configure Responder Policy to Redirect to SSL.
• Test the Redirect to SSL Responder Policy.
Prepare the HTTP Load Balancing Virtual Server

Step Action
57
1. View the current state of lb_vsrv_rbg_sslredirect.

• View the lb_vsrv_rbg_sslredirect state.
Verify the following:

• The state is DOWN.
• Effective State is DOWN.
2. View virtual properties:
• Select lb_vsrv_rbg_sslredirect and click Edit.
• No services are bound to this virtual server.

• A redirect URL is configured to redirect traffic to https://172.21.10.105
The existing configuration allows any traffic sent to http://172.21.10.105 to be redirected to

https://172.21.10.105. However, this requires a virtual server with an effective state of DOWN in
order to be used.
3. Click Back to return to the virtual server list.
4. Create an unmonitored service which will always remain UP:
• Browse to Traffic Management > Load Balancing > Services.

• Click Add.
• Enter svc_alwaysup in the Service Name field.
• Enter 1.2.3.4 in the IP Address field.
• Click More to display additional basic settings for the service.
• Deselect Health Monitoring to disable monitoring for this service.
• Click OK.
Click Done.
NOTE: This service is configured as an unmonitored service so it will never go DOWN. The service
points to a dummy IP address that is not valid in the lab environment. Alternatively, the service
could be pointed at the Citrix ADC loopback address (127.0.0.1) to provide the same
functionality.
5. Verify that the service svc_alwaysup state is UP.
6. Bind the service to lb_vsrv_rbg_sslredirect to keep the load balancing virtual server in a UP state.

• Select lb_vsrv_rbg_sslredirect and click Edit.
• Click No Load Balancing and Virtual Server Service Binding under Services and Service
Groups.
• Click Click to Select under Select Service.
• Select svc_alwaysup and click Select.
• Click Bind.
• Click Done.
Verify that the lb_vsrv_rbg_sslredirect State and Effective State are both UP. Refresh if
necessary.
58
7. Test connection to load balancing virtual server lb_vsrv_rbg_sslredirect:
• Open Firefox and browse to http://172.21.10.105/home.php.
Expected Result: The browser attempts to connect to the current URL on HTTP and is not
redirected to HTTPS; the browser will eventually time out the connection. Since the virtual
server lb_vsrv_rbg_sslredirect is not pointing to a valid destination and is instead bound to the
service svc_alwaysup, the virtual server is in a UP state, but there is no server object to respond.
The configured Redirect URL is only invoked when the virtual server's effective state is DOWN. It
will be used if the service is unbound.
Now, a Responder policy can be configured on this UP virtual server to redirect all traffic to
HTTPS, instead of relying on a DOWN virtual server.
Configure Responder Policy to Redirect to SSL

Step Action
1. Create a Responder action that will redirect a request to https:// while preserving all the
elements of the original URL (host, path, and query).

• Click Add.
Configure Responder action:
• Enter rs_act_sendtossl in the Name field.

• Select Redirect in the Type field.
Configure the Expression to identify the destination for the Redirect action:
"https://" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE +
HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE
Click Create.
The Redirect action uses a 302 Object Moved (Moved Temporarily) response code. For other
response codes, use the Respond with action type.
59
2. Create a Responder policy to invoke the action:

• Click Add.
• Enter rs_pol_sendtossl in the Name field.
• Select rs_act_sendtossl in the Action field.
Configure policy expression to redirect any non-SSL requests.
!CLIENT.SSL.IS_SSL
Click Create.
The policy action could be used with a wide range of HTTP applications and could be bound to
specific virtual servers or globally. The policy expression used excludes redirecting existing
https:// requests to avoid potential redirect loops if the policy is bound somewhere other than a
specific HTTP virtual server. Other expressions could be used as appropriate.
3. Bind the policy to lb_vsrv_rbg_sslredirect to redirect all HTTP requests to HTTPS:
Select the bind point for lb_vsrv_rbg_sslredirect. All Responder policies bind request-time only.
• Select lb_vsrv_rbg_sslredirect from the Virtual Server field.
• Click Continue.

• Select rs_pol_sendtossl and click Select.
• Click Bind.
Click Done.
60
Test the Redirect to SSL Responder Policy

Step Action
1. Test connection to load balancing virtual server lb_vsrv_rbg_sslredirect. Open Firefox and
browse to the following URLs. Use Live HTTP Headers to view the 302 redirect responses:
• Browse to http://172.21.10.105/dist_blue.php
• Browse to http://172.21.10.105/media.php?a1=b1&a2=b2
Expected Result: Verify that you are redirected to https://172.21.10.105 and that the path and
query parameters of the original requests are preserved in the redirects.
NOTE: You will need to ignore SSL cert errors in browser.
In Live HTTP Headers, move to the first request in the capture for each test and verify that the
302 redirect is received. Clear results between test cases as necessary.
2. View Responder policy hits for rs_pol_sendtossl:

• View the hits for rs_pol_sendtossl.
Key Takeaways:
• Responder (and all other policies) bound to virtual servers are only processed if the
virtual server is in an UP state. DOWN virtual servers do not receive traffic, and
therefore policy evaluation does not occur.
• If the virtual server is in a DOWN state, backup methods like backup virtual servers and
redirect URLs will apply at this point and can still be configured. However, while the
virtual server is UP, the Responder policy will take precedence over the backup
methods.
• Responder policies run request-time only.
• Responder policies can be used with other traffic types; it is not limited to HTTP only.
• Unlike with Rewrite policies, only one Responder policy can apply to a given request.
The GoTo expression is set to end.
• Responder policies can also be used to DROP or RESET requests and can, therefore,
replace content filtering.
61
Exercise 3-8: Responder Policy - Redirect Using String Maps

(GUI)
Introduction:
In this exercise, you will learn to use a Responder policy to redirect content based on a string
map. You will use the Configuration Utility to perform this exercise.
Company ABC has identified that they want to implement some navigational shortcuts for users
so that when certain paths are accessed on the RBG virtual server, users will be redirected to a
new location. Some parts of the web site that users once accessed at
http://172.21.10.101/dept1 or http://172.21.10.101/dept2 are now being hosted on separate
web applications. To allow users and applications that are still using the old paths to be
directed to the new locations, Responder policies should be implemented.
This exercise will not follow the above example exactly. For demonstration purposes, this
exercise will redirect to public search websites for Google, Bing, and Yahoo.
• The Responder policies will only apply to the lb_vsrv_rbg virtual server.
• The following paths should redirect to their corresponding URL:
/google http://www.google.com
/bing http://www.bing.com
/yahoo http://www.yahoo.com
• All other content on the RBG virtual server should continue to be served as normal from
lb_vsrv_rbg.
About String Maps:
String Maps are hash tables that are indexed by a key. Contents in string maps consist of key-
value pairs. Typically, a string map is used to look up a key to find its associated value.
String Maps can be used with Responder or Rewrite policies (and other advanced policy
features). String Maps are very useful when trying to consolidate a large number of repetitive
policies that perform the same type of comparisons.
For example, it would take three Responder policies and actions to perform the redirects listed
above normally:
Responder Policy Responder Action
rs_pol_sendto_google rs_act_sendto_google
Expr: http.req.url.path.contains("/google") Action Type: Redirect
Target: "http://www.google.com"
62
rs_pol_sendto_bing rs_act_sendto_bing
Expr: http.req.url.path.contains("/bing") Action Type: Redirect
Target: "http://www.bing.com"
rs_pol_sendto_yahoo rs_act_sendto_yahoo
Expr: http.req.url.path.contains("/yahoo") Action Type: Redirect
Target: "http://www.yahoo.com"
In the above example, three separate Responder policies can be used. However, each one of the policies is making
the same comparison and the actions are performing the same type of response:
• If path contains "x", redirect to "y"
If a string map is defined with key-value pairs, where the keys correspond to the paths (/google, /bing, /yahoo) and
then the value for each key identifies the intended redirect URL, then it would be easy to build a Responder policy
that determines the redirect destination using a string map:
• If the path contains "a key in the string map", redirect to "the value for that key"
A single Responder policy could then perform all three or more redirects, based on the key-value pairs in the string
map:
Responder Policy with String Map

rs_pol_searchstringmaps
Expr:
HTTP.REQ.URL.PATH.IS_STRINGMAP_KEY("search_redirects")
This expression uses the path as input to the IS_STRINGMAP_KEY() function.

• If the path is /google, the response is TRUE (/Google is a key in the table); therefore, do an action
because policy applies.
• If the path is /home, the response is FALSE (/home is not a key in the table); therefore, do not do an
action because the policy does not apply.
Responder Action with String Map
rs_act_searchstringmaps
Action Type: Redirect
Target: HTTP.REQ.URL.PATH.MAP_STRING("search_redirects")
This expression uses the path as input to the MAP_String() function. If you give Map_String a key, it outputs the
associated value.
This action returns the redirect destination for each key (path) in the string map table.
One Responder policy using a string map can replace the three original policies. If the string
map needs to grow from 3 to 30 key-value pairs, then the string map can be updated. No
change to the policy is required.
• Create a String Map for the Path/Redirect URL mappings.

• Create a Responder Policy to Redirect Based on a String Map.
• Test the Responder Policy with String Map.
63
Create a String Map for the Path/Redirect URL Mappings

Step Action
1. Create a string map:
• Browse to AppExpert > String Maps.

• Click Add.
• Enter search_redirects in the Name field.
A string map is a hash table of key/value pairs. The key will match the target paths and the
values will be the expected redirect URLs. The string map will have the following pairs:
2. Bind the key/value pair for Yahoo:
• Click Insert.
• Enter /yahoo in the Key field.
• Enter http://www.yahoo.com in the Value field.
• Click Insert.
3. Bind the key/value pair for Google:
• Click Insert.
• Enter /google in the Key field.
• Enter http://www.google.com in the Value field.
• Click Insert.
4. Bin the key/value pair for Bing:
• Click Insert.
• Enter /bing in the Key field.
• Enter http://www.bing.com in the Value field.
• Click Insert.
5. Click Create to create the string map.
64
Create a Responder Policy to Redirect Based on a String Map

Step Action
1. Create the Responder action which will redirect to the target URL for each key:

• Click Add.
• Enter rs_act_searchstringmaps in the Name field.
• Select Redirect in the Type drop-down list box as the Responder Action type.
Configure the Expression to identify the destination for the Redirect action:
HTTP.REQ.URL.PATH.MAP_STRING("search_redirects")
NOTE: The Expression Editor has a bug and does not enclose the string map name in quotes in
the map_string() function. Remember to include the quotes manually.
• Click Create.
This Responder action will use the PATH as the key for the string map. If the path corresponds to
a key in the string map, then the function (map_string) outputs the associated value, which is a
complete URL as the target for the Responder action.
This action will perform a 302 redirect to the destination URLs listed as values in the string map.
2. Create the Responder policy. The policy expression will only be true if the original PATH in the
request matches a key in the string map table. Otherwise, the policy does not apply.

• Click Add.
• Enter rs_pol_searchstringmaps in the Name field.
• Select rs_act_searchstringmaps in the Action field.
Configure policy expression to redirect any request that matches a path listed as a key in the
string map to the URL in the corresponding value field:
The policy will only apply to paths that match keys in the string map; requests without a
matching key will not be affected by the policy.
Click Create.
3. Bind the policy to lb_vsrv_rbg:
Select the bind point for lb_vsrv_rbg_sslredirect. All Responder policies bind request-time only.
• Click Continue.
65

• Click Click to select under Select Policy.
• Select rs_pol_searchstringmaps and click Select.
• Click Bind.
• Click Done > Close.
• Click Back icon to exit the Responder Policy Manager.
Test the Responder Policy with String Map

Step Action
1. Open Firefox and browse to the following URLs:
• http://172.21.10.101/yahoo
Verify that you are successfully redirected to http://www.yahoo.com/
• http://172.21.10.101/google
Verify that you are successfully redirect to http://www.google.com/
• http://172.21.10.101/bing
Verify that you are successfully redirected to http://www.bing.com
Any path that matches a key in the string map is redirected.

2. View the Responder policy hits:

• View Hits for rs_pol_searchstringmaps.
• Refresh Citrix ADC view as necessary.
3. Confirm the policy does not affect regular content on the lb_vsrv_rbg:
Open Firefox and browse to any of the following URLs. Verify that the expected RBG content is
displayed:
• http://172.21.10.101/
• http://172.21.10.101/media.php
• http://172.21.10.101/dist_red.php
• http://172.21.10.101/home.php
Key Takeaways:
• The Responder redirect provides an already configured 302-redirect response; you just
need to provide the redirect destination.
• String maps can be used to reduce the number of policies being implemented and
simplify management in scenarios where many parallel policies perform the same type
of comparison with the same type of actions. In many cases, those 5 or 10 similar
policies can be replaced with a single policy or action and string map.
• String maps can be used with any default feature such as Rewrite as well as Responder.
66
Exercise 3-9: Responder Policy - Redirect to Imported

Maintenance Page (GUI)
Introduction:
In this exercise, you will learn to use a Responder policy to provide custom "down for
maintenance" responses in the event a virtual server goes offline without a backup resource
available to take over. The exercise will demonstrate the use of Responder policies in this
scenario with two different actions: the respond with custom response action and a response
from a page imported on the Citrix ADC. You will use the Configuration Utility to perform this
exercise.
Company ABC wants to ensure that if an outage occurs for one of the applications that an
appropriate outage message can be displayed.
The requirements for this scenario are that when a given load balancing virtual server is offline
for any reason, users receive a "down for maintenance" message. Three different Responder
actions will be tested to compare the different responses using a 200 OK response, a 503
response, and an imported web page.
This scenario will involve the following:

1. Create a backup virtual server with an always UP service (to deploy the Responder
policy) when primary is DOWN.
2. Create a Responder action (1) of type Respond with. Generate a custom 200 OK
response manually.
3. Create a Responder action (2) of type Respond with. Generate a custom 503 Service
Unavailable response manually.
4. Create a Responder action (3) of type Respond with HTML Import.
5. Create a Responder policy and bind it to the backup virtual server.
6. Test the maintenance policy with each of the actions.
Additional information on this scenario and its alternatives:
• http://support.citrix.com/article/CTX117337
• Importing and Exporting Files (detailed in the Citrix ADC Admin Guide: App Firewall
chapter): http://docs.citrix.com/en-us/NetScaler/11/security/application-
firewall/imports/import-export-files.html
• Prepare the Backup Virtual Server.
67
• Configure Responder Actions.

• Configure Responder Policies.
• Test the Responder Policies.
• Restore the Virtual Server.
Prepare the Backup Virtual Server

Step Action
1. Create the maintenance load balancing virtual server. The virtual server will be configured as a
non-addressable virtual server (No virtual IP address or port).

• Click Add.
• Enter lb_vsrv_maint in the Name field.
• Select HTTP in the Protocol field.
• Select Non Addressable in the IP Address Type field.
• Click OK.
2. Bind the existing always up service to the maintenance virtual server:
• Click No Load Balancing Virtual Server Service Binding under Services and Service
Groups to bind the server.
• Select svc_alwaysup and click Select.
• Click Bind.
• Click Continue.
• Click Done.
3. Verify lb_vsrv_maint is in an UP state. Refresh the Citrix ADC view if necessary.
4. Simulate an outage for lb_vsrv_rbg by disabling the virtual server:
• Select lb_vsrv_rbg , click Disable and confirm.
• State is Out of Service (since the virtual server was disabled).

Attempts to connect to lb_srv_rbg (http://172.21.10.101) at this point would fail.

5. Configure lb_vsrv_maint as the backup virtual server for lb_vsrv_rbg. This virtual server will only
be used when lb_vsrv_rbg is DOWN.

• Click Protection under Advanced Settings in the right-pane to add the Protection
category to the active view.
• Select lb_vsrv_maint under Backup Virtual Server within the Protection settings.
• Click OK.
• Click Done.
68
6. Verify the lb_vsrv_rbg state:
• State is still Out of Service (since the virtual server was disabled).
• Effective State is now UP (since a backup virtual server in an UP state is bound).
An attempt to connect to lb_vsrv_rbg will still fail at this point, because the lb_vsrv_maint is not
yet configured to respond with content.
Configure Responder Actions/Policies to Redirect to Maintenance Page

Step Action
1. Create a Responder action (1) using the custom response type RespondWith. Use this action to
generate a "down for maintenance" message using a 200 OK HTTP response.
Create the Responder action (1):

• Click Add.
• Enter rs_act_sendtomaint1 in the Name field.
• Select Respond with in the Type drop-down list box as the Responder action type.
Configure the Expression to generate the 200 OK response:
"HTTP/1.1 200 OK\r\n\r\n" + "Down for Maintenance\r\nYou are connected from Client
IP: " + client.ip.src + "\r\n\r\n"
• Click Create.
This action will generate a standard 200 OK response. However, since this may be cached, you
may want to generate a 503 Service Unavailable message instead.
NOTE: The RespondWith action is useful in that you can generate any response required with
custom headers and body content. The drawback is that the entire response must be generated
inline and will probably result in very basic page content. (The client IP insertion demonstrates
that the response content can take dynamic content from the policy engine.)
69
2. (OPTIONAL) Create a Responder action (2) using the custom response action type RespondWith.
Use this action to generate a "down for maintenance" message using a 503 Service Unavailable
message.
• Click Add.
Configure the Expression to generate the 503 Service Unavailable response:
"HTTP/1.1 503 Service Unavailable\r\n\r\n" + "Down for Maintenance\r\nYou are

connected from Client IP: " + client.ip.src + "\r\n\r\n"
• Click Create.
NOTE: This is the same action as before but with a different response code/message. The 503
Service Unavailable messages can be used to prevent caching of maintenance responses.
3. Import a maintenance page from an existing URL.
• Browse to AppExpert > Responder > HTML Page Imports.

• Click Add.
• Enter MaintPage in the Name field.
• Select URL in the Import From drop-down list box.
• Enter http://192.168.30.51/maint.htm in the URL field.
• Click Continue.
View the HTML source of the imported maintenance page in the File Contents screen. Note that
the page content can be manually edited prior to import.
Click Done.
4. Create Responder action (3) using the custom response type Respond With HTML Page. Use this
action to display the imported content from maint.htm to the user.

• Click Add.
• Select Respond with HTML Page in the Type drop-down list box as the Responder
action type.
• Select MaintPage in the HTML Page field.
• Enter 503 for the Response Status Code.
Click Create.
70
5. Create a Responder policy to respond under maintenance conditions:
• The policy will be bound to the lb_vsrv_maint virtual server. It will only be hit when the
primary virtual server (lb_vsrv_rbg) is down and traffic is then directed to
lb_vsrv_maint. Therefore, the policy expression can be set to always run for traffic on
the lb_vsrv_maint virtual server.
• For this exercise, one policy will be created and bound to lb_vsrv_rbg. The action
associated with the policy will be changed to demonstrate the different methods.
Create the Responder policy. The policy will be configured to always run.

• Click Add.
• Enter rs_pol_sendtomaint in the Name field.
• Select rs_act_sendtomaint1 in the Action field.
Configure Policy expression:
HTTP.REQ.IS_VALID
Click Create.
6. Do not bind the policy yet. Continue with the next task.
Test Responder Policy: rw_pol_sendtomaint

Step Action
1. Open Firefox.
2. Baseline: No Responder policy. No maintenance page.
Verify that no response is returned.

3. Bind the policy to lb_vsrv_maint.

Select the bind point for lb_vsrv_maint.
• Select lb_vsrv_maint from the Virtual Server field.
• Click Continue.
71

• Select rs_pol_sendtomaint and click Select.
• Click Bind.
Click Done > Close > Back.
This is using rs_act_sendtomaint1, which is based on the RespondWith action returning a 200 OK
response code.
5. Test 1: Responder policy with custom RespondWith action (1). Maintenance content is
displayed.
Verify that the maintenance message is displayed. This is the manually created message from
the policy action.
NOTE: Live HTTP Headers can be used to confirm the response is of type 200 OK.
6. (Optional) Edit the policy to use action 2: rs_act_sendtomaint2

• Select rs_pol_sendtomaint and click Edit.
Click OK.
displayed.
Verify that the maintenance message is displayed.
NOTE: Live HTTP Headers can be used to confirm the response is of type 503 Service
Unavailable.
8. Edit the policy to use action 3: rs_act_sendtomaint3:

• Select rs_pol_sendtomaint and click Edit.
• Click OK.
9. Test 3: Responder policy with custom RespondWith action (3). Maintenance content displayed.
Verify that the maintenance page (/maint.htm) is displayed from the Citrix ADC. Response code
is also 503 Service Unavailable.
Restore the Virtual Server (lb_vsrv_rbg)
72
Step Action
1. Re-enable the load balancing virtual server lb_vsrv_rbg:

• Select lb_vsrv_rbg, click Enable and confirm.
Key Takeaways:
• The custom “Respond with” actions can be difficult to use as the entire response must
be fully generated, from headers to body content. This includes HTTP version, response
code, status message, required headers, optional headers, and body content.
Formatting issues with the content or the line returns can cause the response to not be
generated properly. The response also will be relatively simplistic when viewed in a
browser.
• The “Respond with” HTML import makes delivering a more robust response page output
easier and requires less work. The content can be imported from an existing URL (the
page source is copied to the Citrix ADC), or from file, or manually entered as text. Links
to images will not be included.
• Both the “Respond with” and “Respond with” HTML imports allow the administrator to
supply a response type other than 200 OK. So these methods are appropriate if you
need to supply a 301 or 503 response.
• However, for simplicity, the default Redirect action that formats a standard 302 redirect
is still the simplest action to use with Responder.
73
Exercise 3-10: Responder Policy- Respond to the DNS request

(GUI)
(Optional Exercise)
Introduction:
In this exercise, we will learn to configure the responder feature to respond to DNS requests.
DNS Expressions:
In a responder configuration, we can use the following Citrix ADC expressions to refer to various
portions of a DNS request:
Expressions Descriptions
DNS.NEW_RESPONSE Creates a new empty DNS response based on the

request.
DNS.NEW_RESPONSE <AA, TC, rcode> Creates a new DNS response based on the specified
parameters.
DNS Bind Points:
The following global bind points are available for policies that contain DNS expressions.
Bind Points Descriptions
DNS_REQ_OVERRIDE Priority/override request policy queue.

DNS_REQ_DEFAULT Standard request policy queue.
Scenario:
Company ABC wants to send DNS responses over UDP to ensure that the DNS requests from
the client are sent over TCP.
• Configure Responder policy to check if the Request is over UDP.

• If yes, send response to client requesting the data over TCP.
74
Step Action
1. Test the original behavior:
Browse to Start > Command Prompt.
From the cmd prompt, test the following resolutions:
nslookup webred.training.lab 172.21.10.102
Observe that the request resolves to 192.168.30.51

2. Connect to Citrix ADC HA Pair using the NSMGMT SNIP (192.168.10.103) using SSH (PuTTY). Log
on using the following credentials:
User name: nsroot

Password: nsroot
3. Enter the shell prompt:
shell
dig webred.training.lab @172.21.10.102
Observe that the DNS resolution is successful.

exit
6. Connect to the ADCMGMT SNIP at http://192.168.10.103 from Google chrome.
User Name: nsroot

Password: nsroot
7. Configure Responder Action to set the TC flag:

• Click Add.
• Enter rs_ enforce_tcp _act in the Name field.
• Configure the Expression
DNS.NEW_RESPONSE(true, true, NOERROR)
Click Create.
75
8. Configure Responder Policy:

• Click Add.
• Enter rs_enforce_tcp_pol in the Name field.
• Select rs_ enforce_tcp _act in the Action field.
• Configure Policy expression:
dns.REQ.TRANSPORT.EQ(udp)
Click Create.
9. Bind the policy to lb_vsrv_dns:

Select the bind point for lb_vsrv_dns.
• Click Continue.

• Select rs_enforce_tcp_pol and click Select.
• Click Bind.
Click Done.
11. Go to the Citrix ADC CLI connection and enter the shell prompt:
shell
12. Perform test using dig:
Observe that the resolution is failing with following message:
;;Truncated, retrying in TCP mode.

;; Connection to 172.21.10.102#53(172.21.10.102) for webred.training.lab failed:
connection refused.
13. Exit shell prompt:
exit
76
14. Unbind the policy to lb_vsrv_dns:
• Switch to the Citrix ADC GUI.

Select the bind point for lb_vsrv_dns.
• Click Continue.
• Select rs_enforce_tcp_pol and click Unbind.

• Click Close.
• Click the Back icon to exit the Responder Policy Manager.
Exercise 3-1: Rewrite Policy - Modify a URL (CLI)
Introduction:
In this exercise, you will learn to use a rewrite policy to modify a URL. You will use the
command-line interface to perform this exercise.
Company ABC has noticed that the default page on the RBG virtual server is not the best
landing page for their users. They want you to implement a Rewrite policy to direct default
requests to /home.php without affecting other traffic.
Rewrite policies can be used to insert, modify, or delete elements of a request or a response,
which includes URLs, Headers, and body content. In this scenario, the Rewrite policy will be
used to rewrite the path of the URL in the original request from the client to a new destination
path as the Citrix ADC submits the request to the server.
Requirements for this scenario:
• HTTP requests sent to the default page (/) should be modified to Browse to /home.php
instead.
• The policy should not apply for any other requests.
• The policy will be used with the lb_vsrv_rbg only.
During this first exercise working with the default policy engine, take note of the following:
• How policies can be bound to global objects or virtual servers.

• Policy bind points must indicate the flow: request or response.
77
• Policy expressions based on HTTP elements must also indicate request (HTTP.REQ) or
response (HTTP.RES). It is easy to use the wrong expression or the wrong-bind point.
• Notice how the Rewrite feature can affect the request or response.
• View the Default Web Page.

• Use Rewrite to Modify a URL.
• Test Rewrite Policy: rw_pol_sendtohome.
About policy syntax in the CLI:
Policy expressions entered in the command-line interface, such as the target of the replace
action and the value for the replace action, must be enclosed in double quotes (" "). If double
quotes are needed for literal strings within the policy expression, the quotes must be escaped
(\").
Example 1: Using double quotes with policy expressions in the CLI. (Examples only. Do not
create in lab.)
add rewrite action rw_act_demo1 REPLACE "HTTP.REQ.URL.PATH" "\"/home.php\""
add rewrite policy rw_pol_demo1

"HTTP.REQ.HEADER(\"host\").CONTAINS(\"rbg.training.lab\") &&
http.REQ.URL.PATH.CONTAINS(\"/home.php\")" rw_act_demo1
To simplify entering the expressions, an alternative method allows the expression to be quoted
using a single quote ('), then any double quotes appearing within the expression are treated as
literals without needing to be escaped ("). This can be easier to type and troubleshoot. Most of
the expressions in this course will use this method.
Example 2: Using single quotes with policy expressions and literal double quotes in the CLI.
add rewrite action rw_act_demo1 REPLACE 'HTTP.REQ.URL.PATH' '"/home.php""
add rewrite policy rw_pol_demo1

'HTTP.REQ.HEADER("host").CONTAINS("rbg.training.lab") &&
http.REQ.URL.PATH.CONTAINS("/home.php")' rw_act_demo1
Viewing the Default Web Page

Step Action
78
• Open a web browser and connect to http://172.21.10.101/
NOTE: The default page displays "serverindex", a Citrix logo, and "Welcome".
2. Compare to the home page ("/home.php") on lb_vsrv_rbg:
• Open a web browser and connect to http://172.21.10.101/home.php
NOTE: The home page displays the server color and home as the title with a corresponding
home graphic.
Using Rewrite to Modify a URL

Step Action
1. Connect to Citrix ADC HA Pair using the ADCMGMT SNIP (192.168.10.103) using SSH (PuTTY). Log
User name: nsroot

Password: nsroot
2. Create a rewrite action that will replace the URL path to the new value "/home.php":
add rewrite action rw_act_sendtohome REPLACE "HTTP.REQ.URL.PATH" '"/home.php"'

3. Create a rewrite policy to replace the original URL only when users access the default path ("/"):
add rewrite policy rw_pol_sendtohome 'HTTP.REQ.URL.PATH.EQ("/")'

rw_act_sendtohome
4. Bind the rewrite policy to lb_vsrv_rbg:
bind lb vserver lb_vsrv_rbg -policyName rw_pol_sendtohome -priority 100 -

gotoPriorityExpression NEXT -type REQUEST
NOTE: When binding policies at the CLI, default (advanced) policies are either bound to a virtual
server or to the global bind point for that feature. When binding to a virtual server, the policy
binding must also specify the bind point type or flow as Request or Response to determine when
the policy is processed.
When binding to the global object for the feature, the bind point type must be specified which
identifies global override or global default along with request or response time flows.
save ns config
Test Rewrite Policy: rw_pol_sendtohome

Step Action
79
1. Switch to Firefox and browse to http://172.21.10.101/
• Verify content for "/home.php" is displayed, though only "/" appears in the browser
URL.
• Live HTTP Headers will display a 200 OK for the request to "/" and not indicate a
redirect (since one has not occurred).
NOTE: Using the Rewrite policy, the client asks for "/" in the request to the virtual server. The
Citrix ADC than modifies the request sent to the server and fetches "/home.php". The client
receives the response associated with "/" and are not aware that a different request was
delivered. The rewrite is not visible to the end user.
2. On ADC_VPX_01, identify the policy hits:
show rewrite policy rw_pol_sendtohome
Policy hits should increase for each request to "/".

3. Switch to Firefox and confirm that other URLs are not affected:
• Browse to http://172.21.10.101/blue.php
4. On ADC_VPX_01, identify the policy hits:
show rewrite policy rw_pol_sendtohome
No policy hits should occur for requests to other content.
Takeaways:
• Rewrite policies can be used modify a request URL and rewrites the request between the Citrix ADC and
the Server. The modified URL is not returned to the user, so it does not display in the browser address bar
and it does not appear as a redirect. However, the content fetched by the modified request is displayed to
the user. Rewrite policies when used for this type of URL rewrite is somewhat transparent to the user.
• Multiple rewrite policies can apply to a single request or response transaction. When the policies are
bound, the GoTo expression must be set to NEXT to allow processing of additional policies.
• Rewrite was useful in this scenario to seamlessly change the requested URL to a new value. If you need
the user to be aware of the change in destination, then try using a Responder policy to redirect the user.
Exercise 3-2: Rewrite Policy - Delete HTTP Headers (CLI)
Introduction:
80
In this exercise, you will learn to create a Rewrite policy to delete an HTTP header. You will use
the command-line interface to perform this exercise.
Company ABC has implemented a security policy stating that Web servers should not broadcast
their server platform and version in the returned HTTP responses. Some of the web application
owners have not yet updated their servers (or some servers were missed), so the company
would like you to get the Citrix ADC to remove these headers from the responses. Eventually
this policy may be applied globally, but the company wants to test this on the lb_vsrv_rbg only
first.
The rewrite policy configuration in this scenario should meet the following requirements:
• Remove the Server header from HTTP responses.

About Rewrite Policy Action Types:
There are many types rewrite actions. The Insert and Replace action types need to be
configured with a target for where to begin the insert action or a target identifying what to
replace. Then these actions are assigned a value for what to insert at the target location or a
value for what to replace.
Delete actions are simpler. The delete actions need to identify the target for what to delete.
There is no replacement value.
This exercise demonstrates the use of the DELETE_HTTP_HEADER to delete an HTTP header
specifically. The Delete action type could also have been used; it can be used to delete headers
or other elements of a request or a response.
• View the Default Headers.

• Create a Rewrite Policy to Delete the Server Header.
View the Default Headers

Step Action
1. Open the Firefox browser in the Student Desktop.
NOTE: During this exercise, you will switch back and forth between the Citrix ADC CLI and
Firefox.
81
2. Open Live HTTP Headers:
• In Firefox, Open Live HTTP Headers: Tools > Live HTTP Headers.
• Verify that Capture is enabled on the Headers tab.
• Click Clear to clear the capture windows as needed.
The Add-on Live HTTP Headers will be used with Firefox during this exercise. For convenience,
Live HTTP Headers is also added to the Chrome browser in the lab; however, lab steps will not
reference this configuration explicitly.
3. Browse to http://172.21.10.101/home.php and view Request and Response headers in Live
HTTP Headers.
Use Live HTTP Headers to view the header information for the /home.php request (at top of list).
• The request contains the HTTP Method (Get), the target (/home.php), Host header, and
user-agent headers, among others.
• The response contains the response code and message (200 OK) and a Server header
indicating content came from an Apache server.
Create Rewrite Policy to Delete the Server Header

Step Action
User name: nsroot

Password: nsroot
2. Create a rewrite action to delete the response-time header "server":
add rewrite action rw_act_removesrvid delete_http_header Server

3. Create a rewrite policy that will run for all http responses:
add rewrite policy rw_pol_removesrvid 'HTTP.REQ.IS_VALID' rw_act_removesrvid

4. Bind the policy to the load balancing virtual server lb_vsrv_rbg:
bind lb vserver lb_vsrv_rbg -policyName rw_pol_removesrvid -priority 100 -

gotoPriorityExpression NEXT -type RESPONSE
• Click Clear in Live HTTP Headers to clear the capture window. Keep it open.
Live HTTP Headers.
Verify that the Server header no longer appears in the response.
82
6. View the policy hits for the rw_pol_removesrvid:
show rewrite policy rw_pol_removesrvid
Policy hits should increase for all web requests on lb_vsrv_rbg as each request generates a
response which contains a Server header. The policy will ensure it is removed and no longer
displays for the client.
Requests to other virtual servers (HTTP) will still result in Server headers being present as traffic
on the other virtual servers are not affected by this policy.
save ns config
Key Takeaways:
• A rewrite action that targets a response object must be bound to a response-time policy
bind point.
• The Delete_HTTP_Header action targets the entire HTTP header (name and value). The
Delete action targeting an HTTP Header will usually delete the value, but leave the
header name behind.
• If a request or a response contains duplicate headers, the policy will only delete the first
instance of the header it finds.
Exercise 3-3: Rewrite Policies - Insert HTTP Headers (CLI)
Introduction:
In this exercise, you will learn to use a rewrite policy to insert an HTTP header into a response.
You will use the command-line interface to perform this exercise.
Company ABC decided that instead of deleting the server header completely, a generic header
should be used.
The rewrite policy in this scenario should meet the following requirements:
• Insert a new HTTP response header named "Server" with a generic value "Unspecified"
to obscure the server platforms in use.
83
• Ensure that this policy (rw_pol_newsrvid) and the previous policy (rw_pol_removesrvid)
both apply to the request. As a result, the insert header policy rw_pol_newsrvid must
run after the delete header policy.
IMPORTANT: Do not replace the server header or other response content with strings or
phrases such as "Hack this" or "Try to hack me now." Potential legal implications with such a
statement may exist because you could be granting permission to hackers to attempt to violate
your security. As always, consult the appropriate security experts within your organization for
guidelines and requirements for your environment.
This scenario could also have been done by using a single REPLACE action instead of a separate
DELETE_HTTP_HEADER and INSERT_HTTP_HEADER action.
• Create Rewrite Policy to Insert New Header.
Create Rewrite Policy to Insert New Header

Step Action
User name: nsroot

Password: nsroot
2. Create a rewrite action to insert a new Server header:
add rewrite action rw_act_newsrvid insert_http_header "Server" "\"Unspecified\""

3. Create a rewrite policy that will run for all HTTP responses and insert the new header:
add rewrite policy rw_pol_newsrvid 'HTTP.REQ.IS_VALID' rw_act_newsrvid

4. Bind the rewrite policy to the virtual server lb_vsrv_rbg:
bind lb vserver lb_vsrv_rbg -policyName rw_pol_newsrvid -priority 110 -

gotoPriorityExpression NEXT -type RESPONSE
• Click Clear in Live HTTP Headers to clear the capture window. Keep open.
Live HTTP Headers.
Verify that a new server header with the value "Unspecified" appears at the end of the response
header section.
NOTE: Make sure that multiple server headers or one with combined values (original value,
Unspecified) are not present. This could be an indicator that the policy processing order is
incorrect.
84
save ns config
Takeaways:
• Rewrite policies are evaluated against the original unmodified request or response.
• When multiple rewrite policies apply, they apply all at once.
• Output from one policy cannot be input to another on the same request or response.
• The same header cannot be modified by multiple policies in the same request or
response.
This does not apply to the last two exercises because the delete action and the insert
action are working on two separate instances of the Server header. This limitation
impacts the replace action types more often.
Exercise 3-4: Rewrite Policy - Convert URL Paths to Lowercase

(CLI)
Introduction:
In this exercise, you will learn to use a rewrite policy to convert URL Paths to lowercase for
case-sensitive paths. You will use the command-line interface to perform this exercise.
Company ABC has received complaints from users who are trying to browse the RBG web site;
sometimes it works and sometimes it does not. The senior administrator investigated the issue
and realized that, during the recent Web server migration, the web platform had changed from
IIS to Apache. As a result, users were requesting invalid URLs because the Apache URL paths are
case-sensitive. The Web server administrator has promised to update the Apache configuration
so that it does not treat paths as case-sensitive. However, the administrator is on vacation for
another week, so you have been asked to fix it now.
User requests to the following URLs are failing because the actual objects should be lower case.
Here are some examples:
Invalid Requests Required Value
/Home.php /home.php
/images/Red_home_top.JPG /images/red_home_top.jpg
/Dist_Red.php /dist_red.php
/MEDIA.php /media.php
85
You plan to use a rewrite policy to convert all URL paths to lowercase for this application. For
the RBG site, this will work because all of the paths and objects on the server are lowercase.
Therefore, the rewrite policy in this scenario should meet the following requirements:
• Rewrite the original URL in the request to all lowercase.

• Apply the policy to lb_vsrv_rbg only.
• Use a policy expression to ensure the policy runs only when needed, meaning when the
request contains uppercase letters. (Hint: This is going to require a regular expression.)
This policy is actually quite similar to the first rewrite policy in the send-to-home example
(rw_pol_sendtohome). The policy action needs to rewrite the URL path in the original HTTP
request. Therefore, this policy will use a replace action type and the action target should
identify the originating URL (or URL Path).
The main difference in this scenario and the earlier exercise is the criteria for when this policy
should apply. The policy will still be bound to the lb_vsrv_rbg. All requests sent to this virtual
server will be compared against this policy. To avoid running the policy for every request and
forcing the Citrix ADC to rewrite every URL, the expression for this policy will only run if
uppercase letters are present. If the request already contains the correct URL path, there is no
need for rewrite to apply.
To detect whether a string like a URL contains any uppercase letters, a regular expression will
be used. The expression is provided in the exercise.
About Regular Expressions in Default Policy Syntax:

Citrix ADC uses PCRE syntax for its regular expressions. The raw regex to identify uppercase
letters in a string is:
[A-Z]+
This expression identifies if any character in the range Uppercase A-to-Uppercase Z Is present.
The "+" at the end means "one or more of the preceding". The expression will match if the
request contains one or more capital letters.
When integrating a regular expression with a default policy expression, the Citrix ADC requires
that the regex is included within its own delimiter within the expression syntax.
Expression Example Details
http.req.url.contains("somestring") No regex in this example.
The operator contains takes a string value somestring in quotes.
86
http.req.url.REGEX_MATCH(re/ /) Regex syntax example:

operator(re<delimiter><regexpattern><delimiter>
Regular Expressions in a policy operator always begins with re

The forward slash "/" is then use to mark the start and end of the
regular expression pattern as the delimiter.
http.req.url.REGEX_MATCH(re/[A-Z]+/) Example with actual regex included:

The regex: [A-Z+
is contained within the regex delimiter: re/ /
This expression will look to see if the request URL contains a regex
match for one or more uppercase letters.
• If the match is true, the policy applies and we can convert
to lowercase.
• If the match is false, there are no uppercase letters and
the policy does not apply.
• Configure Rewrite to Transform URLs to All Lowercase.
Configure Rewrite to Transform URLs to all Lowercase

Step Action
1. Verify original behavior.

• Open Firefox and find http://172.21.10.101/Home.php (note case)
This should fail with a 404 Not Found error saying the content was not found on the
server.
NOTE: The Apache web server is case-sensitive, so /Home.php is a distinct object from
/home.php. (IIS is not case-sensitive with regards to path and file names.)
2. Create a rewrite policy action to transform a URL path to all lowercase elements:
add rewrite action rw_act_replacepath_lowerc REPLACE HTTP.REQ.URL

HTTP.REQ.URL.HTTP_URL_SAFE.TO_LOWER
3. Create a rewrite policy to perform the transform only for URLs with path elements when
uppercase letters are present in the URL:
add rewrite policy rw_pol_replacepath_lowerc "HTTP.REQ.URL.REGEX_MATCH(re/[A-

Z]+/)" rw_act_replacepath_lowerc
4. Bind policy to the virtual server lb_vsrv_rbg:
bind lb vserver lb_vsrv_rbg -policyName rw_pol_replacepath_lowerc -priority 110 -

gotoPriorityExpression NEXT -type REQUEST
87
5. Save Citrix ADC configuration:
save ns config
6. Test policy:

• Open Firefox and find http://172.21.10.101/Home.php (note case)
This should now succeed without error.
Other URLs could include:
• http:/172.21.10.101/Dist_Red.php (normally dist_red.php)

• http://172.21.10.101/mEDIa.PHP
All content should be properly displayed without issue.
Key Takeaways:
• Regular string comparison operators like contains(); eq(); before_str(); after_str(); and
others can provide a lot of sophisticated string parsing with the default policy engine on
the Citrix ADC. When needed, though, the Citrix ADC can use regular expressions for
more complex string comparisons with regex operators like regex_match() and others.
• String comparison operators are quicker to evaluate than the regex operators, so only
use regex operators when necessary.
• Rewrite policies are useful for modifying requests and responses in situations in which
the correction can be made without having to explicitly convey the correction to the
user for the user to make a new request.
Exercise 3-5: Rewrite Policy – Modify the DNS Response (CLI)

(Optional Exercise)
Introduction:
We can implement rewrite feature to manage the flow of DNS requests, and make necessary
modifications in the header, or in the answer section.
Rewrite Action Types for DNS
88
• replace_dns_answer_section—This action replaces the DNS answers section with the

defined expression in the DNS policy.
• replace_dns_header_field—Checks the opcode type in the DNS request. Returns True or
False, indicating whether the opcode type in the DNS request matches the specified
opcode type. This action replaces the DNS header section with the defined expression in
the DNS policy.
Limitations
• If the Recursion Available (RA) flag in the header is set to YES, the RA flag will not be
modified in the rewrites.
• If the RA flag in the header is set to YES, the CD flag in the header is modified regardless
of any rewrite action.
Step Action
User name: nsroot

Password: nsroot
2. Enter the shell prompt

shell
89
3. Test the DNS resolution using dig
dig yahoo.com @172.21.10.102
Observe that the DNS resolution is successful. and the flags set are qr rd
4. Exit the shell prompt
exit
5. Configure Rewrite Action to set AA bit of the DNS response:
add rewrite action rw_set_aa_act replace_dns_header_field "dns.res.header.flags.set(aa)"
6. Configure Rewrite Policy
add rewrite policy rw_set_aa_pol true rw_set_aa_act

7. Bind Policy to the vserver
bind lb vserver lb_vsrv_dns -policyName rw_set_aa_pol -priority 10 -type RESPONSE

shell
90
dig yahoo.com @172.21.10.102
Observe that the DNS resolution is successful. and the flags set are : qr aa rd
NOTE: In case you are not seeing the expected results, please flush the cached DNS entries on
Citrix ADC and try again.
exit
11. Unbind Policy to the vserver
unbind lb vserver lb_vsrv_dns -policyName rw_set_aa_pol -priority 10 -type RESPONSE
12. Save Citrix ADC configuration:
save ns config
Exercise 3-6: Rewrite Policy – Rewrite TCP header (CLI)

(Optional Exercise)
Introduction:
In this exercise, you will learn to insert the client ip in the TCP header using rewrite policy.
91
For the protocols like HTTP, SIP, the protocol has headers available to insert the client
information. However, in the case when the virtual servers are configured to implement using
TCP /SSL Bridge, Citrix ADC does not inspect/modify the application payload. Hence, in order to
maintain the transparent communication, we need to use the TCP rewrite.
Scenario:
The company ABC has configured virtual server to load balance the LDAP servers.
They need to record the client ip address to the backend server.
• Create Rewrite policy to enter the client ip before the start of the data.
• Bind the policy to lb_vsrv_ldap and perform test.
Step Action
1. Connect to Citrix ADC HA Pair using the ADC_HA_MGMT SNIP (192.168.10.103) using SSH (PuTTY).
User name: nsroot

Password: nsroot
2. Create Rewrite action to insert the client IP
add rewrite action rw_insert_tcp_act insert_before "client.TCP.PAYLOAD(1)" "\"From Client:

\"+client.IP.SRC"
3. Create Rewrite Policy
add rewrite policy rw_insert_tcp_pol true rw_insert_tcp_act
4. Bind Rewrite Policy to vserver lb_vsrv_ldap
bind lb vserver lb_vsrv_ldap -policyName rw_insert_tcp_pol -priority 100 -type REQUEST
92
5. Perform Test
• Start Citrix ADC Trace
start nstrace -size 0 -traceFormat PCAP -filter
(connection.ip.eq(192.168.10.10)&&connection.port.eq(389)) -link ENABLED
• To Generate test traffic

o Open command prompt.
o Type telnet 172.21.10.103 389 and hit the Enter key to establish the connection.
o Hit any key from the keyboard.
o The telnet connection will be terminated
• Stop the Citrix ADC Trace

stop nstrace
6. Download Trace file

• Open WinSCP and connect to Citrix ADC SNIP (NSMGMT SNIP) using credentials
nsroot/nsroot
• In the right-pane, browse to the /var/nstrace/ directory.
Use the top icon to move up a directory level until you reach "/" (root), then browse to
/var/nstrace/.
Open the folder with the date on which the exercise is performed.
• In the left pane, browse to C:\Resources\ on the Student Desktop.
• Copy the nstrace1.cap file to the Resources folder.

• Close WinSCP.
93
7. Open Trace file

• Browse to C:\Resources\ on the Student Desktop.
• Open the file nstrace1.cap in Wireshark.
8. Analyze the trace file.
Locate the [PSH-ACK] packets from client to vserver and snip to backend.
Right-Click on the {PSH,ACK] from 192.168.10.10 -172.21.10.103

Go to Follow > TCP Stream.
WireShark Follow TCP Stream window will appear. Observe that it does not have the Client IP.
Click Close.
Clear the Wireshark filter.
Right-Click on the {PSH,ACK] from 192.168.10.111 -192.168.30.12

Go to Follow > TCP Stream.
WireShark Follow TCP Stream window will appear. Observe that the Client ip has been inserted
9. Close Wireshark.
10. Unbind Policy
unbind lb vserver lb_vsrv_ldap -policyName rw_insert_tcp_pol -priority 100 -type REQUEST
94
Exercise 3-7: Responder Policies to Redirect to SSL (CLI)
Introduction:
In this exercise, you will learn to create a Responder policy to redirect HTTP requests to HTTPS.
You will use the command-line interface to perform this exercise.
Company ABC is not happy with the result of an earlier solution. The application ssl_vsrv_rbg
(172.21.10.105) is configured properly to accept user requests over HTTPS. As this is supposed
to be a sensitive application, all content should be on HTTPS only. During the initial rollout, a
load balancing virtual server on HTTP:80 (lb_vsrv_rbg_sslredirect) was implemented in a DOWN
state to act as a redirect to the SSL vserver using the redirect URL property. While this solution
meets the requirements of redirecting all HTTP requests to HTTPS and preventing access to the
application over HTTP, it also causes a DOWN virtual server to be displayed in the console,
dashboard, and reports. SNMP alerts are also being generated for this DOWN entity.
You have been asked to change the configuration so that all requests to http:// are redirected
to https for the 172.21.10.105 virtual server, and the HTTP listener remains in an UP state
instead of DOWN.
• Keep lb_vsrv_rbg_sslredirect (172.21.10.105:HTTP:80) in an UP state, but do not allow it

to pass traffic to the backend servers over HTTP.
• All requests to lb_vsrv_rbg_sslredirect (HTTP) should be redirected to ssl_vsrv_rbg
(HTTPS) and without changing the original user request URL, path, or query parameters
when the redirect is performed.
The Responder Policy Redirect action is probably the easiest way to redirect an HTTP to HTTPS
request. The Redirect action generates a 302 Moved Temporarily response code. The action
just needs the redirect destination, which will appear in the Location header of the response.
• Prepare the HTTP Load Balancing Virtual Server.

• Configure Responder Policy to Redirect to SSL.
• Test the Redirect to SSL Responder Policy.
95
Prepare the HTTP Load Balancing Virtual Server

Step Action
14. View the current state of lb_vsrv_rbg_sslredirect:
show lb vserver lb_vsrv_rbg_sslredirect
• State is DOWN.
• No services are bound to this virtual server.
The existing configuration allows any traffic sent to http://172.21.10.105 to be redirected to

https://172.21.10.105. However, this requires a virtual server with an effective state of DOWN in
order to be used.
15. Create an unmonitored service which will remain always up by disabling health monitoring:
add service svc_alwaysup 1.2.3.4 HTTP 80 -healthMonitor NO
This service is configured as an unmonitored service so it will never go down. No monitor probes
are performed on the service. The service points to a dummy IP address that is not valid in the
lab environment. Alternatively, the service could be pointed at the Citrix ADC loopback address
(127.0.0.1).
16. Bind the service to lb_vsrv_rbg_sslredirect to keep the load balancing virtual server in an UP
state:
bind lb vserver lb_vsrv_rbg_sslredirect svc_alwaysup
17. Verify that the virtual server is now UP:
show lb vserver lb_vsrv_rbg_sslredirect
• State is UP.
• Effective State is UP.
• The service svc_alwaysup is bound and in an UP state.
96
18. Test connection to load balancing virtual lb_vsrv_rbg_sslredirect:
Expected Result: The browser attempts to connect to the current URL on HTTP and is not
redirected to HTTPS; the browser will eventually time out the connection. Since the virtual
server lb_vsrv_rbg_sslredirect is not pointing to a valid destination and is instead is bound to the
service svc_alwaysup, the virtual server is in an UP state but there is no server object to respond.
The configured Redirect URL is only invoked when the virtual server effective state is DOWN. It
will be used if the service is unbound.
Now a Responder policy can be configured on this UP virtual server to redirect all traffic to
HTTPS://, instead of relying on a DOWN virtual server.
Configure Responder Policy to Redirect to SSL

Step Action
1. Create a Responder action that will redirect a request to https:// while preserving all the
elements of the original URL (host, path, and query):
add responder action rs_act_sendtossl redirect '"https://" +

HTTP.REQ.HOSTNAME.HTTP_URL_SAFE +
HTTP.REQ.URL.PATH_AND_QUERY.HTTP_URL_SAFE'
This creates an action that will redirect using the default 302 Moved Temporarily response code.
Alternate response codes can be provided using the RespondWith action type, making it possible
to supply a 301 Moved Permanently message or other response code when needed.
2. Create a Responder policy to invoke the action:
add responder policy rs_pol_sendtossl '!CLIENT.SSL.IS_SSL' rs_act_sendtossl
The policy action could be used with a wide range of HTTP applications and could be bound to
specific virtual servers or globally. The policy expression used excludes redirecting existing
https:// requests to avoid potential redirect loops if the policy is bound somewhere other than a
specific HTTP virtual server. Other expressions could be used as appropriate.
3. Bind the policy to lb_vsrv_rbg_sslredirect to redirect all HTTP requests to HTTPS:
bind lb vserver lb_vsrv_rbg_sslredirect -policyName rs_pol_sendtossl -priority 100
save ns config
97
Test the Redirect to SSL Responder Policy

Step Action
1. Test connection to load balancing virtual server lb_vsrv_rbg_sslredirect. Open Firefox and
browse to the following URLs. Use Live HTTP Headers to view the 302 redirect responses:
• Find http://172.21.10.105/home.php
• Find http://172.21.10.105/dist_blue.php
• Find http://172.21.10.105/media.php?a1=b1&a2=b2
NOTE: Verify that you are redirected to https://172.20.10.105 and that the path and query
parameters of the original requests are preserved in the redirects.
In Live HTTP Headers, move to the first request in the capture for each test and verify that the
302 redirect is received. Clear results between test cases as necessary.
2. View Responder policy hits:
show responder policy rs_pol_sendtossl
save ns config
Key Takeaways:
• Responder (and all other policies) bound to virtual servers are only processed if the
virtual server is in an UP state. Down virtual servers do not receive traffic and therefore
policy evaluation does not occur.
• If the virtual server is in a DOWN state, backup methods like backup virtual servers and
redirect URLs will apply at this point and can still be configured. However, while the
virtual server is UP, the Responder policy will take precedence over the backup
methods.
• Responder policies run request-time only.
• Responder policies can be used with other traffic types; it is not limited to HTTP only.
• Unlike with Rewrite policies only one Responder policy can apply to a given request.
The GoTo expression is set to end.
• Responder policies can also be used to DROP or RESET requests and can therefore
replace content filtering.
98
Exercise 3-8: Responder Policy - Redirect using String Maps

(CLI)
Introduction:
In this exercise, you will learn to use a responder policy to redirect content based on a string
map. You will use the command-line interface to perform this exercise.
Company ABC has identified that they want to implement some navigational shortcuts for users
so that when certain paths are accessed on the RBG virtual server, users will be redirected to a
new location. Some parts of the web site that users were used to going to as
http://172.21.10.101/dept1 or http://172.21.10.101/dept2 are now hosted on separate web
applications. To allow users and applications that are still using the old paths to be directed to
the new locations, Responder policies should be implemented.
This exercise will not follow the above example exactly. For demonstration purposes, this
exercise will redirect to public search websites for Google, Bing, and Yahoo.
• The Responder policies will only apply to the lb_vsrv_rbg virtual server.
• The following paths should redirect to their corresponding URL:
• All other content on the RBG virtual server should continue to be served as normal from
lb_vsrv_rbg.
About String Maps:
String Maps are hash tables that are indexed by a key. Contents in string maps consist of key-
value pairs. Typically, a string map is used to look up a key to find its associated value.
String Maps can be used with Responder or Rewrite policies (and other advanced policy
features). String Maps are very useful when trying to consolidate a large number of repetitive
policies that perform the same type of comparisons.
For example, it would take three Responder policies and actions to perform the redirects listed above normally:
Responder Policy Responder Action
99
rs_pol_sendto_google rs_act_sendto_google
Expr: http.req.url.path.contains("/google") Action Type: Redirect
Target: "http://www.google.com"
rs_pol_sendto_bing rs_act_sendto_bing
Expr: http.req.url.path.contains("/bing") Action Type: Redirect
Target: "http://www.bing.com"
rs_pol_sendto_yahoo rs_act_sendto_yahoo
Expr: http.req.url.path.contains("/yahoo") Action Type: Redirect
Target: "http://www.yahoo.com"
In the above example, three separate Responder policies can be used. However, each one of
the policies is making the same comparison and the actions are performing the same type of
response:
• If the path contains "x", redirect to "y".

If a string map is defined with keys that correspond to the paths (/google, /bing, /yahoo) and
then the value of each key is the intended redirect target.
• If path contains "a key in the string map", redirect to "the value for that key".
A single Responder policy could then perform all three or more redirects, based on the key-
value pairs in the string map:
Responder Policy with String Map
rs_pol_searchstringmaps
Expr:
This expression uses the path as input to the IS_STRINGMAP_KEY() function.

• If the path is /google, the response is TRUE (/google is a key in the table); therefore, do action because
policy applies.
• If the path is /home, the response is FALSE (/home is not a key in the table); therefore, do not do action
because policy does not apply.
Responder Action with String Map

rs_act_searchstringmaps
Action Type: Redirect
Target: HTTP.REQ.URL.PATH.MAP_STRING("search_redirects")
This expression uses the path as input to the MAP_String() function. If you give Map_String a key it, outputs the
associated value.
This action returns the redirect destination for each key (path) in the string map table.
100
So one Responder policy using a string map can replace the three original policies. If the string
map needs to grow from 3 to 30 key-value pairs, then the string map can be updated. No
change to the policy is required.
• Create a String Map for the Path/Redirect URL mappings.

• Create a Responder Policy to Redirect Based on a String Map.
• Test the Responder Policy with String Map.
Create a String Map for the Path/Redirect URL Mappings

Step Action
1. Create string map:
add policy stringmap search_redirects
A string map is a hash table of key/value pairs.
The key will match the target paths and the values will be the expected redirect URLs. The string
map will have the following pairs:
2. Bind the key/value pair for Yahoo:
bind policy stringmap search_redirects "/yahoo" "http://www.yahoo.com"
3. Bind the key/value pair for Google:
bind policy stringmap search_redirects "/google" "http://www.google.com"
4. Bind the key/value pair for Bing:
bind policy stringmap search_redirects "/bing" "http://www.bing.com"
5. View string map:
show policy stringmap search_redirects
Create a Responder Policy to Redirect Based on a String Map

Step Action
101
1. Create the Responder action which will redirect to the target URL for each key:
add responder action rs_act_searchstringmaps REDIRECT

'HTTP.REQ.URL.PATH.MAP_STRING("search_redirects")'
This Responder action will use the PATH as the key for the string map. If the path corresponds to
a key in the string map, then the function (map_string) outputs the associated value, which is a
complete URL as the target for the Responder action.
This action will perform a 302 redirect to the destination URL's listed as values in the string map.
2. Create the Responder policy:
add responder policy rs_pol_searchstringmaps

'HTTP.REQ.URL.PATH.IS_STRINGMAP_KEY("search_redirects")' rs_act_searchstringmaps
The policy expression will only be true if the original PATH in the request matches a key in the
string map table. Otherwise, the policy does not apply.
3. Bind the policy to lb_vsrv_rbg:
bind lb vserver lb_vsrv_rbg -policyName rs_pol_searchstringmaps -priority 100
save ns config
Test the Responder Policy with String Map

Step Action
1. Open Firefox and browse to the following URLs:
• http://172.21.10.101/yahoo
Verify that you are successfully redirected to http://www.yahoo.com/
• http://172.21.10.101/google
Verify that you are successfully redirect to http://www.google.com/
• http://172.21.10.101/bing
Verify that you are successfully redirected to http://www.bing.com
Any path that matches a key in the string map is redirected.
2. View the Responder policy hits:
show responder policy -summary
102
3. Confirm that the policy does not affect regular content on the lb_vsrv_rbg:
Open Firefox and find any of the following URLs. Verify that the expected RBG content is
displayed:
• http://172.21.10.101/
• http://172.21.10.101/dist_red.php
Key Takeaways:
• The Responder redirect provides an already configured 302 redirect response; you just
need to provide the redirect destination.
• String maps can be used to reduce the number of policies being implemented and
simplify management in scenarios where many parallel policies perform the same type
of comparison with the same type of actions. In many cases, those 5 or 10 similar
policies can be replaced with a single policy/action and string map.
• String maps can be used with any default feature such as Rewrite as well as Responder.
Exercise 3-9: Responder Policy to Redirect to Maintenance

Page (CLI)
Introduction:
In this exercise, you will learn to use a Responder policy to provide custom "down for
maintenance" responses in the event a virtual server goes offline without a backup resource
available to take over. The exercise will demonstrate the use of Responder policies in this
scenario with two different actions: the respond with custom response action and a response
from a page imported on the Citrix ADC. You will use the command-line interface to perform
this exercise.
Company ABC wants to ensure that if an outage does occur for one of the applications, that an
appropriate outage message can be displayed.
This scenario will involve the following:
103
1. Create a Backup vserver with an ALWAYS UP service (to deploy the Responder policy)
when the primary is DOWN.
2. Create a Responder action (1) of type Respond with. Generate a custom 200 OK
response manually.
3. Create a Responder action (2) of type Respond with. Generate a custom 503 Service
Unavailable response manually.
4. Create a Responder action (3) of type Respond with HTML Import.
5. Create a Responder policy and bind to the backup virtual server
6. Test the maintenance policy and each of the actions
For additional info see:
• http://support.citrix.com/article/CTX117337
• Importing and Exporting Files (detailed in the Citrix ADC Administrator’s Guide: App
Firewall chapter): http://docs.citrix.com/en-us/NetScaler/11/security/application-
firewall/imports/import-export-files.html
• Prepare the Backup Virtual Server.

• Configure Responder Actions/Policies to Redirect to Maintenance Page.
• Test the Responder Policies.
• Restore the Virtual Server.
Prepare the Backup Virtual Server

Step Action
1. Create the maintenance load balancing virtual server. The virtual server will be configured as a
non-addressable virtual server (No virtual IP address or port):
add lb vserver lb_vsrv_maint http
2. Bind the existing ALWAYS UP service to the maintenance virtual server:
bind lb vserver lb_vsrv_maint svc_alwaysup
This virtual server will remain in an UP state (due to the service svc_alwaysup created in an
earlier exercise) allowing any bound policies to process. This virtual server will be the backup
virtual server to our primary virtual server (lb_vsrv_rbg).
3. Verify that the maintenance load balancing virtual server is UP:
show lb vserver lb_vsrv_maint
104
4. Configure lb_vsrv_maint as the backup virtual server for lb_vsrv_rbg:
set lb vserver lb_vsrv_rbg -backupvServer lb_vsrv_maint
This virtual server will only be used when lb_vsrv_rbg is DOWN.
NOTE: Backup virtual servers are processed before Redirect URLs, if both are configured.
5. Simulate an outage by disabling the primary virtual server (lb_vsrv_rbg):
disable lb vserver lb_vsrv_rbg
6. Verify lb vserver status:
show lb vserver lb_vsrv_rbg
• State is OUT OF SERVICE.

• Effective State is UP.
Configure Responder Actions/Policies to Redirect to Maintenance Page

Step Action
1. Create Responder action (1) using the custom response action type RespondWith. Generate a
down for maintenance request using a 200 OK HTTP response:
add responder action rs_act_sendtomaint1 respondwith q{"http/1.1 200 OK\r\n\r\n" +

"Down for Maintenance.\r\nYou are connected from Client IP: " + client.ip.SRC +
"\r\n\r\n"}
This action will generate a standard 200 OK response. However, since this may be cached, you
may want to generate a 503 Service Unavailable message instead.
The RespondWith action is useful in that you can generate any response required with custom
headers and body content. The drawback is that the entire response must be generated in line
and will probably result in very basic page content. (The client IP address insertion demonstrated
that the response content can take dynamic content from the policy engine.)
2. (OPTIONAL) Create Responder action (2) using the custom response action type RespondWith.
Generate a 503 Service Unavailable message:
add responder action rs_act_sendtomaint2 respondwith q{"http/1.1 503 Service

Unavailable\r\n\r\n" + "Down for Maintenance.\r\nYou are connected from Client IP: " +
client.ip.SRC + "\r\n\r\n"}
Note from Architect: This is the same action as before but with a different response
code/message. The 503 Service Unavailable messages can be used to prevent caching of
maintenance responses.
105
3. Import a maintenance page from an existing URL:
import responder htmlpage http://192.168.30.51/maint.htm maint1
NOTE: From the GUI, you can view the imported page source and modify before uploading to
the Citrix ADC. The GUI supports importing content by URL, file, or text.
4. Create Responder action (3) using the custom response type Respond With HTML Page:
add responder action rs_act_sendtomaint3 respondwithhtmlpage maint1

-responseStatusCode 503 -reasonPhrase '"Service Unavailable"'
Use this action to display the imported content from maint.htm to the user.
5. Create a policy to respond under maintenance conditions:
• The policy will be bound to the lb_vsrv_maint virtual server. It will only be hit when the
primary virtual server (lb_vsrv_rbg) is DOWN and traffic is then directed to
lb_vsrv_maint. Therefore, the policy expression can be set to always run for traffic on
the lb_vsrv_maint virtual server.
• For this exercise, one policy will be created and bound to lb_vsrv_rbg. The action
associated with the policy will be changed to demonstrate the different methods.
add responder policy rs_pol_sendtomaint "HTTP.REQ.IS_VALID" rs_act_sendtomaint1
6. Do not bind the policy yet. Continue with the next task.
Test the Responder Policies

Step Action
1. Open Firefox.
106
2. Baseline: No Responder policy. No maintenance page.
Verify that no response is returned.

3. Bind the policy to the lb_vsrv_maint:
bind lb vserver lb_vsrv_maint -policyName rs_pol_sendtomaint -priority 10
This is using rs_act_sendtomaint1, which is based on the RespondWith action returning a 200 OK
response code.
Verify that the maintenance message is displayed. This is the manually created message from
the policy action.
NOTE: Live HTTP Headers can be used to confirm the response is of type 200 OK.
5. Modify the policy to use action 2:
set responder policy rs_pol_sendtomaint -action rs_act_sendtomaint2
displayed.
Verify that the maintenance message is displayed.
NOTE: Live HTTP Headers can be used to confirm the response is of type 503 Service
Unavailable.
7. Modify the policy to use action 3: rs_act_sendtomaint3:
set responder policy rs_pol_sendtomaint -action rs_act_sendtomaint3
Verify that the maintenance page (/maint.htm) is displayed from the Citrix ADC. Response code
is also 503 Service Unavailable.
Restore the Virtual Server

Step Action
107
1. Re-enable the load balancing virtual server to return lb_vsrv_rbg to an UP state:
enable lb vserver lb_vsrv_rbg
save ns config
Key Takeaways:
• The custom Respond with actions can be difficult to use as the entire response must be
fully generated from headers to body content. This includes HTTP version, response
code, status message, required headers, optional headers, and body content.
Formatting issues with the content or the line returns can cause the response to not be
generated properly. The response will also be relatively simplistic when viewed in a
browser.
• The respond with HTML import makes it easier to deliver a more robust response page
output with less work. The content can be imported from an existing URL (the page
source is copied to the Citrix ADC), or from file, or manually entered as text. Links to
images will not be included.
• Both the Respond with and Respond with HTML import allow the administrator to
supply a response type other than 200 OK. Therefore, these methods are appropriate if
needing to supply a 301 or 503 response as well.
• However, for simplicity, the default Redirect action that formats a standard 302 redirect
is still the simplest action to use with Responder.
Exercise 3-10: Responder Policy- Respond to the DNS request

(CLI)
Introduction:
In this exercise, we will learn to configure the responder feature to respond to DNS requests.
DNS Expressions
In a responder configuration, we can use the following Citrix ADC expressions to refer to various
portions of a DNS request:
Expressions Descriptions
108
DNS.NEW_RESPONSE Creates a new empty DNS response based on the

request.
DNS.NEW_RESPONSE <AA, TC, rcode> Creates a new DNS response based on the specified
parameters.
DNS Bind Points
The following global bind points are available for policies that contain DNS expressions.
Bind Points Descriptions
DNS_REQ_OVERRIDE Priority/override request policy queue.

DNS_REQ_DEFAULT Standard request policy queue.
Scenario:
Company ABC wants to send DNS responses over UDP to ensure that the DNS requests from
the client are sent over TCP.
Configure Responder policy to check if the Request is over UDP
If yes, send a response to client requesting the data over TCP
Step Action
1. Test the original behavior
Browse to Start > Command Prompt
Observe that the request resolves to 192.168.30.51
109
2. Connect to Citrix ADC HA Pair using the NSMGMT SNIP (192.168.10.103) using SSH (PuTTY). Log
User name: nsroot

Password: nsroot
shell
Observe that the DNS resolution is successful

exit
6. Configure Responder Action to set the TC flag
add responder action rs_enforce_tcp_act respondwith

DNS.NEW_RESPONSE(true,true,NOERROR)
7. Configure Responder Policy
add responder policy rs_enforce_tcp_pol dns.REQ.TRANSPORT.EQ(udp) rs_enforce_tcp_act
8. Bind Responder Policy to the lb vserver
bind lb vserver lb_vsrv_dns -policyName rs_enforce_tcp_pol -priority 100

9. Perform Test
Browse to Start > Command Prompt
• From the cmd prompt, test the following:

Observe that the DNS lookup fails
• Run command nslookup -debug webred.training.lab 172.21.10.102

Observe that the message is as following:
truncated answer
connect failed: No error
10. Go to the Citrix ADC enter shell prompt

shell
110
11. Perform test using dig
observe that the resolution is failing with following message
;;Truncated, retrying in TCP mode.

;; Connection to 172.21.10.102#53(172.21.10.102) for webred.training.lab failed:
connection refused.
12. Exit shell prompt
exit
13. Unbind the policy
unbind lb vserver lb_vsrv_dns -policyName rs_enforce_tcp_pol
14. Save configuration
save nsconfig
Module 4: Content Switching

Introduction:
Content Switching is a traffic management feature that uses the policy engine to identify traffic
of interest and then direct it to the appropriate virtual server. Content switching can be used to
sort traffic into buckets for easier traffic management.
For HTTP requests, content switching policies often look at headers or elements of the URL,
Path, or content extensions to identify traffic.
When configuring content switching, the following are generally required:
• A content-switching virtual server with a VIP:Protocol:Port specified.

• One or more content-switching policies with expressions identifying the criteria for the
traffic of interest.
• One or more virtual servers to which the content-switching policies will direct matching
traffic.
Content-switching policies are bound to the content0switching virtual servers. Requests that
arrive at the content switching virtual server are compared against the policies and then
directed to the target load balancing virtual server. If no content switching policies match for
the traffic, then a default destination can be specified. If a request has no destination to be sent
to, the request is dropped.
In this module, you will perform hands-on exercises to simulate following content switching
examples:
111
• Exercise 4-1 implements content switching based on the browser type used to make the
request by identifying the contents of the User-Agent HTTP header.
• Exercise 4-2 implements content switching based on request content types and
demonstrates the use of pattern sets in the policy expressions.
Content Switching can be used with a wide range of traffic types, such as MYSQL/MSSQL
database content, DIAMETER, SIP, DNS, and can be used to provide content switching in front
of SSL VPN virtual servers or AAA virtual servers.
• Create non-addressable load balancing virtual servers as content-switching destinations.

• Create non-addressable AAA virtual servers as content-switching destinations.
• Create and configure content-switching policies using default policy syntax.
• Bind content-switching policies to content-switching virtual servers.
• Assign target destinations for each content-switching policy condition.
• Understand SSL Interception.
Before you Begin:

Estimated time to complete this lab: 30 minutes
• WebBlue • AD02.training.lab
• WebRed
Exercise 4-1: Configure Content Switching by User Agent (GUI)
Introduction:
In this exercise, you will learn to create a content-switching virtual server and use content-
switching policies to direct traffic to specific load balancing virtual servers. You will use the
Configuration Utility to perform this exercise.
112
Scenario:
Company ABC wants to direct user requests for their web app to different load balancing
servers based on which browser type the user is connecting from. The initial implementation
will identify mobile devices identified as iPhone devices and legacy IE 6.0 browsers for special
handling. All other traffic will be treated the same.
The content-switching configuration in this scenario should meet the following requirements:
• Requests from iPhone devices browsers should be directed to the RED server.
• Requests from MSIE 6.0 browsers should be directed to the BLUE server.
• Requests from all other clients should be directed to the GREEN server.
Devices will be identified by looking for the following values in user-agent headers in the HTTP
Requests:
• Mobile devices: iPhone

• Legacy devices: MSIE 6.0
A new content-switching virtual server will be created: cs_vsrv_rbg (172.21.10.106: HTTP:80).
New, non-addressable load balancing virtual servers will be created for the Red, Blue, and
Green content using the existing HTTP services.
• Create Content Switching Policies and Expressions.

• Configure Content Switching Virtual Server and Binding Policies.
• Test Content Switching.
Create Content Switching Policies and Expressions

Step Action
User Name: nsroot

Password: nsroot
113
2. Enable the Content Switching feature:

(Choose Method 1 or Method 2)
Method 1:
• Select Content Switching.
• Click OK.
Method 2:
• Browse to Traffic Management > Content Switching.
• Right-click on yellow (!) icon.
• Click Enable Feature.
In the further exercises, we will be using the Method 1; However, you are free to use either of
these methods to enable a feature.
3. Create a policy expression to identify iPhone users from the user-agent header:
Create Default Policy Expressions:

• Browse to AppExpert > Expressions > Advanced Expressions.
• Click Add.
• Enter iPhone in the Expression Name field.
• Enter the expression:
HTTP.REQ.HEADER("USER-AGENT").CONTAINS("iPhone")
• Click Create.
4. Create a policy expression to identify Internet Explorer 6 users using the user-agent header:
• Click Add.
• Enter IE6 in the Expression Name field.
• Enter the expression:
HTTP.REQ.HEADER("USER-AGENT").CONTAINS("MSIE 6.0")
• Click Create.
Make sure your header value is "MSIE<space>6.0". The contains operator is case-sensitive in
this expression as written.
5. Create a content-switching policy for iPhone users:
• Browse to Traffic Management > Content Switching > Policies.
• Click Add.
• Enter cs_pol_mobile in the Name field.
• Leave Action <blank>.
• Select iPhone from the Saved Policy Expressions drop-down list to configure the
expression:
iPhone
• Click Create.
This content-switching policy is created without an action. The target for this policy can be set
when it is bound to the virtual server.
114
6. Create a content-switching policy for MSIE 6.0 (legacy) users:

• Click Add.
• Enter cs_pol_legacy in the Name field.
• Select IE6 from the Saved Policy Expressions drop-down list to configure the
expression:
IE6
• Click Create.
Configure Content-Switching Virtual Server and Binding Policies

Step Action
1. Create non-addressable virtual servers corresponding to the Red, Blue, and Green web servers:
• Click Add.
2. Create a non-addressable load balancing virtual server bound to the red service named:
lb_vs_red
• Enter lb_vs_red in the Name field.
• Verify that the Protocol is set to HTTP and the Port is set to 80.
• Select Non Addressable from the IP Address type drop-down list.
• Click OK.
Bind the service:

Groups.
• Select svc_red and click Select.
• Click Bind.
• Click Continue.
Click Done.
3. Create a non-addressable load balancing virtual server bound to the blue service named:
lb_vs_blue:
• Click Add.
• Enter lb_vs_blue in the Name field.
• Select Non Addressable from the IP Address type drop-down list box.
• Click OK.
Bind the service:

Groups.
• Select svc_blue and click Select.
• Click Bind.
• Click Continue.
• Click Done.
115
4. Create a non-addressable load balancing virtual server bound to the green service named:
lb_vs_green:
• Click Add.
• Enter lb_vs_green in the Name field.
• Select Non Addressable from the IP Address type drop-down list box.
• Click OK.
Bind the service:

Groups.
• Select svc_green and click Select.
• Click Bind.
• Click Continue.
• Click Done.
5. Create a content-switching virtual server named cs_vsrv_rbg:
• Browse to Traffic Management > Content Switching > Virtual Servers.
• Click Add.
Configure content-switching virtual server basic settings:
• Enter cs_vsrv_rbg in the Name field.
• Verify that Protocol and Port are set to HTTP and 80 respectively.
• Click OK.
6. Bind the content-switching policies for Mobile users to direct traffic to lb_vs_red:
• Click No Content Switching Policy Bound under Content Switching Policy Binding.
• Click cs_pol_mobile and click Select.
• Verify that Priority is set to 100.
• Click Click to select under Target Load Balancing Virtual Server.
• Select lb_vs_red and click Select.
• Click Bind.
Keep Content Switching Virtual Server settings open.
7. Bind the content-switching policies for Legacy users to direct traffic to lb_vs_blue:
• Click 1 Content Switching Policy under Content Switching Policy Binding.
• Click cs_pol_legacy and click Select.
• Select lb_vs_blue and click Select.
• Click Bind.
• Click Close to return to the virtual server properties.
• Click OK.
116
8. Configure the default destination for all unmatched traffic to direct traffic to lb_vs_green:
• Click No Default Load Balancing Virtual Server Bound.
• Select lb_vs_green from Default Load Balancing Virtual Server Name drop-down list
box.
• Click Bind.
• Click Done. Close the Content Switching Virtual Server properties.
NOTE: There is no Default Load balancing virtual server bound by default. Without the default
virtual server, any request that does not match any of the content switching policies will be
dropped.
Test Content Switching

Step Action
1. Open the FireFox web browser, using the current user agent header value:
• The content being displayed is from the GREEN server. (Current User-Agent header
contains Firefox.)
NOTE: The Firefox extension Live HTTP Headers can be used to confirm which User-Agent value
is being sent in the requests. This is not required but may provide additional information.
The Chrome browser in the lab also contains extensions for Live HTTP Headers and the User-
Agent switcher. Either browser may be used for this demonstration, though steps may vary
slightly.
2. Change the browser user agent header to iPhone, in Firefox:
• Click Tools > Default User Agent > Edit User Agents.
• Select iPhone 3.0, click OK.
• Select iPhone 3.0
• Refresh the URL: http://172.21.10.106/home.php.
• The content being displayed is from the RED server.
3. Change the browser user agent header to MSIE 6.0, in Firefox:
• Click Tools > iPhone 3.0 > Internet Explorer > Internet Explorer 6.
• The content being displayed is from the BLUE server.
4. Restore the user agent header to the default (native) browser value:
• Click Tools > Internet Explorer 6 > Default User Agent.
• Content returns to being displayed from the GREEN server.
117
5. View the content-switching policy statistics after the test cases:

• Switch to the Citrix ADC GUI and browse to Traffic Management > Content Switching >
Virtual Server.
• Select cs_vsrv_rbg and click Edit.
• Click Content Switching Policies under Content Switching Policy Bindings.
View policy hits for each policy.
Click Close.
6. View hits on Default Load Balancing virtual server:
• View the hits by selecting a Load Balanced Virtual Server form the drop-down menu.
• The hits are displayed below the selected vServer.
Click Close.
7. Click Done.
Key Takeaways:
• Content Switching is evaluated before Load Balancing.
• Content-switching policies are used to direct matching traffic to specific load balancing
virtual servers.
• If no content-switching policies match, traffic will be sent to the default destination if
configured.
• If no default destination is specified and a request does not match any other policy, the
request is dropped.
• Content-switching policies can be based on the classic or default policy engine.
• Non-addressable load balancing virtual servers are not configured with VIPs or Ports.
Load balancing vServers act as internal resources to the Citrix ADC appliance, therefore
traffic can be sent to them by content-switching policies or virtual server backup
methods like the backup virtual server. Otherwise, non-addressable virtual servers
cannot receive a direct connection from an external source.
Exercise 4-2: Configure Content Switching by Content Type

(GUI)
Introduction:
In this exercise, you will learn to create a content-switching virtual server with policies that will
direct traffic to different virtual servers based on content type. This exercise also demonstrates
the use of pattern sets to simplify long, complex comparisons when constructing policy
expressions. You will use the Configuration Utility to perform this exercise.
118
Company ABC wants to set up their web application so that web requests for a specific
application can be handled by different banks of servers. For example, image content can be
handled by one bank of servers, while dynamic or script content can be handled by another,
and static content (and everything else) by the third. They want to keep the initial scenario
simple until they can move on to a more complex application. The initial demonstration will be
based on the Red, Blue, Green web servers to begin with.
The content-switching configuration in this scenario should be based on the following:
• Image content should be directed to the RED server.

• Script/Dynamic content should be directed to the BLUE server.
• All other content should be directed to the GREEN server.
The content type in a request can be identified by evaluating the extension contained in the
URL path for the object requested.
A new content-switching virtual server will be created: cs_vsrv_rbg_webcontent
(172.21.10.107:HTTP:80). The same non-addressable load balancing virtual servers for the Red,
Blue, Green content from the last exercise will be used in this one.
About Pattern Sets:

This exercise also introduces the concept of Pattern Sets in expressions to simplify long,
complicated policies. For example, here is an advanced expression that can search for content
types .jpg, .gif, and, .png:
HTTP.REQ.URL.PATH.SUFFIX.EQ("jpg") || HTTP.REQ.URL.PATH.SUFFIX.EQ("gif")
|| HTTP.REQ.URL.PATH.SUFFIX.EQ ("png")
The Suffix() operator identifies the extension referenced in the path of the request URL
(without the leading ".").
The problem is that the more extensions you need to compare, the longer this expression will
get and the more difficult it is to maintain.
A pattern set can be defined which contains all of the image extensions (or other items) of
interest. The pattern set can then be used with a single expression to see if a path matches any
of the values in the pattern set. The same comparison using a pattern set that contains the
appropriate suffixes for the extensions .jpg, .gif, .png would look like:
HTTP.REQ.URL.PATH.SUFFIX.EQUALS_ANY("ps_imagestuff")
• Create Pattern Sets for Content Types.
119
• Create Content-Switching Policies using Pattern Sets.

• Bind Content-Switching Policies to CS Virtual Server.
• Test Content-Switching Policies.
Create Pattern Sets for Content Types

Step Action
1. Create a pattern set to identify image content types by URL suffix - jpg, png, gif, and ico:
• Browse to AppExpert > Pattern Sets.
• Click Add.
• Enter ps_imagestuff in the Name field.
Bind pattern set values for the image extensions to this pattern set:
• Click Insert.
• Enter jpg in the Pattern field and click Insert.
• Click Insert.
• Enter png in the Pattern field and click Insert.
• Click Insert.
• Enter gif in the Pattern field and click Insert.
• Click Insert.
• Enter ico in the Pattern field and click Insert.
Click Create.
2. Create a pattern set to identify script content types by URL suffix - cgi and js:
• Click Add.
• Enter ps_scriptstuff in the Name field.
Bind pattern set values for the image extensions to this pattern set:
• Click Insert.
• Enter cgi in the Pattern field and click Insert.
• Click Insert.
• Enter js in the Pattern field and click Insert.
Click Create.
Create Content-Switching Policies Using Pattern Sets

Step Action
120
1. Create a content-switching policy with an expression that matches if the URL path contains
extensions found in the ps_imagestuff pattern set:

• Click Add.
• Enter cs_pol_imagestuff in the Name field.
• Configure expression identifies if the path contains image content:
HTTP.REQ.URL.SUFFIX.EQUALS_ANY("ps_imagestuff")
• Click Create.
NOTE: Usually, the expression builder will supply quotes when required. For the pattern set
objects, the expression editor omits quotes. Whether you enter the expression manually using
the inline editor or you build the expression using the expression editor, note that the pattern
set name must be enclosed in quotes and match the original pattern set name to be valid.
extensions found in the ps_scriptstuff pattern set:
• Click Add.
• Enter cs_pol_scriptstuff in the Name field.
• Configure expression identifies if the path contains script content:
HTTP.REQ.URL.SUFFIX.EQUALS_ANY("ps_scriptstuff")
• Click Create.
NOTE: Quotes are required for the pattern set name for the same reason as in the previous step.
Bind Content-Switching Policies to Content Switching Virtual Server

Step Action
1. Create a content-switching virtual server named cs_vsrv_rbg_webcontent:
• Browse to Traffic Management > Content Switching > Virtual Servers.
• Click Add.
Configure content-switching virtual server basic settings:
• Enter cs_vsrv_rbg_webcontent in the Name field.
• Verify Protocol and Port are set to HTTP:80.
• Click OK.
For this scenario:
• Image content will be sent to Red.
• Script content will be sent to Blue.
• All other content will be sent to Green.
121
2. Bind the content-switching policies for image content so that traffic is sent to Red:
• Click No Content Switching Policy Bound under Content Switching Policy Binding.
• Click cs_pol_imagestuff and click Select.
• Select lb_vs_red and click Select.
• Click Bind.
Keep Content Switching Virtual Server settings open.
3. Bind the content-switching policies for script content so that traffic is sent to Blue:
• Click 1 Content Switching Policy under Content Switching Policy Binding.
• Click cs_pol_scriptstuff and click Select.
• Select lb_vs_blue and click Select.
• Click Bind.
• Click Close to return to the virtual server properties.
Keep Content Switching Virtual Server properties open.
4. Configure the default destination for all unmatched traffic to be sent to Green:
• Click No Default Virtual Server bound.
• Select lb_vs_green from Default Load Balancing Virtual Server Name drop-down list
box.
• Click Bind.
• Click OK.
Click Done. Close the Content Switching Virtual Server properties.
Test Content-Switching Policies

Step Action
1. Open FireFox web browser and Live HTTP Headers. Clear the capture before testing.
Test the following URLs:
Click Download on this page. (This image file is intentionally large and may take several
seconds to display.)
• Browse to http://172.21.10.107/jspage.php
Expected results:
• All content displays. In the web browser, the only "server color" displayed is Green.
• In Live HTTP Headers, verify that different request objects are coming from the
expected servers by looking at the Served-by header in each response. This custom
header is being added by the web servers to indicate the origin server for the content; it
was added for lab demonstration purposes only.
122
2. View the content-switching policy statistics after the test cases:

• Switch to the Citrix ADC GUI and Browse to Traffic Management > Content Switching >
Virtual Server.
• Select cs_vsrv_rbg_webcontent and click Edit.
• Click 2 Content Switching Policies under Content Switching Policy Bindings.
Identify how many hits were handled by the bound policies.
Click Close.
3. View hits on Default Load Balancing virtual server:
• Click Default Load Balancing Virtual Server under Content Switching Policy Binding.
• View Hits by selecting a Load Balanced Virtual Server from the drop-down menu. The
Hits aredisplayed below the selected vServer.
Identify how many content requests were handled by the default destination (Green).
Click Close.
4. Click Done.
Key Takeaways:
• Content-switching decisions can be based on any request-time criteria. User agent headers, request URLs,
content type, are all convenient policy criteria.
• Pattern sets make it easy to handle long, repetitive comparisons in a short, easy to read, and easy to
update policy expression. There is a maximum character limit to content-switching policies, and pattern
sets can help avoid that.
• If the policy criteria need to change, pattern sets can be easily updated to contain additional values or
regular expression patterns.
• This exercise demonstrated an EQUALS_ANY() operator that performs a comparison against a pattern set.
Any of the <name>_any operators can take a pattern set as input: equals_any, contains_any,
before_str_any, after_str_any, and others.
Exercise 4-1: Configuring Content Switching by User Agent

(CLI)
In this exercise, you will learn to create a content-switching virtual server and use content-
switching policies to direct traffic to specific load balancing virtual servers. You will use the
command-line interface to perform this exercise.
Company ABC wants to direct user requests for their web app to different load balancing
servers based on which browser type the user is connecting from. The initial implementation
will identify mobile devices that are iPhone devices and legacy IE 6.0 browsers for special
handling. All other traffic will be treated the same.
123
The content-switching configuration in this scenario should meet the following requirements:
• Requests from iPhone devices browsers should be directed to the RED server.
• Requests from MSIE 6.0 browsers should be directed to the BLUE server.
• Requests from all other clients should be directed to the GREEN server.
Devices will be identified by looking for the following values in user-agent headers in the HTTP
Requests:
• Mobile devices: iPhone

• Legacy devices: MSIE 6.0
A new content-switching virtual server will be created: cs_vsrv_rbg (172.21.10.106:HTTP:80).
New non-addressable load balancing virtual servers will be created for the Red, Blue, and Green
content using the existing HTTP services.
• Create Content-Switching Policies and Expressions.

• Configure Content-Switching Virtual Server and Binding Policies.
• Test Content Switching.
Create Content-Switching Policies and Policy Expressions

Step Action
User name: nsroot

Password: nsroot
2. Enable the Content Switching feature:

enable ns feature cs
3. Create a policy expression to identify iPhone users from the user-agent header:
add policy expression iPhone 'HTTP.REQ.HEADER("User-Agent").CONTAINS("iPhone")'
NOTE: The eq (equals) and contains operators in the default policy engine are case-sensitive.
Equals is a full string match. Contains is a partial string match.
To create a case-insensitive version of the expression, use the SET_TEXT_MODE(IGNORECASE)

operator. Example (for reference only):
add policy expression iPhone 'HTTP.REQ.HEADER("User-
Agent").SET_TEXT_MODE(IGNORECASE).CONTAINS("iPhone")'
124
4. Create a policy expression to identify Internet Explorer 6 Users:

add policy expression IE6 'HTTP.REQ.HEADER("User-Agent").CONTAINS("MSIE 6.0")'
Make sure your header value is "MSIE<space>6.0". (The space may not be easy to see.)
The contains operator is case-sensitive in this expression as written.
5. Create a content-switching policy for iPhone users:
add cs policy cs_pol_mobile -rule iPhone
6. Create a content-switching policy for MSIE 6.0 (legacy) users:
add cs policy cs_pol_legacy -rule IE6
save ns config
Configure Content Switching

Step Action
1. Create a non-addressable load balancing virtual server for red content (bound to the red
service):
add lb vserver lb_vs_red HTTP
Bind the red service:

bind lb vserver lb_vs_red svc_red
2. Create a non-addressable load balancing virtual server for blue content (bound to the blue
service):
add lb vserver lb_vs_blue HTTP
Bind the blue service:

bind lb vserver lb_vs_blue svc_blue
3. Create a non-addressable load balancing virtual server for green content (bound to the green
service):
add lb vserver lb_vs_green HTTP
Bind the green service:

bind lb vserver lb_vs_green svc_green
4. Verify that all the new virtual servers are in an UP state:

show lb vserver -summary
125
5. Create a content-switching virtual server named cs_vsrv_rbg. Bind the content-switching

policies. For each policy, set a target destination to the appropriate non-addressable load
balancing virtual server.
Create the content-switching virtual server:

add cs vserver cs_vsrv_rbg HTTP 172.21.10.106 80
For this scenario:

• Mobile users with the iPhone header value will be sent to the RED server.
• Legacy users with the MSIE 6.0 header value will be sent to the BLUE server.
• All other users will be sent to the GREEN server.
6. Bind the content-switching policies for Mobile users to direct traffic to lb_vs_red:
bind cs vserver cs_vsrv_rbg -policyName cs_pol_mobile
-targetLBVserver lb_vs_red -priority 100
7. Bind the content-switching policies for Legacy users to direct traffic to lb_vs_blue:
bind cs vserver cs_vsrv_rbg -policyName cs_pol_legacy
-targetLBVserver lb_vs_blue -priority 110
8. Configure the default destination for all unmatched traffic to direct traffic to lb_vs_green:
bind cs vserver cs_vsrv_rbg -lbvserver lb_vs_green

save ns config

Step Action
1. Open FireFox web browser, using the current user agent header value:
• Browse to http://172.21.10.106/home.php.
• The content being displayed is from the GREEN server. (Current User-Agent header
contains Firefox.)
NOTE: The Firefox extension Live HTTP Headers can be used to confirm which User-Agent value
is being sent in browser the requests. This is not required, but may provide additional
information.
The Chrome in the lab also contains extensions for Live HTTP Headers and the User-Agent
switcher. Either browser may be used for this demonstration, though steps may vary slightly.
2. Change the browser user agent header to iPhone, in Firefox:

• Click Tools > Default User Agent > iPhone 3.0.
• Refresh the URL: http://172.21.10.106/home.php
• The content being displayed is from the RED server.
3. Change the browser user agent header to MSIE 6.0, in Firefox:

• Click Tools > iPhone 3.0 > Internet Explorer > Internet Explorer 6.
• The content being displayed is from the BLUE server.
126
4. Restore the user agent header to the default (native) browser value:
• Click Tools > Internet Explorer 6 > Default User Agent.
• Content is from the GREEN server.
5. View the content switching policy stats after the test cases:
show cs vserver cs_vsrv_rbg
Identify how many requests resulted in hits on the Mobile and Legacy content-switching policies.
Also, identify how many requests results in hits on the default target load balancing virtual
server for traffic not matching a bound content-switching policy.
Key Takeaways:
• Content Switching is evaluated before Load Balancing.
• Content-switching policies are used to direct matching traffic to specific load balancing
virtual servers.
• If no content-switching policies match, traffic will be sent to the default destination if
configured.
• If no default destination is specified, and a request does not match any other policy, the
request is dropped.
• Content-switching policies can be based on the classic or default policy engine.
• Non-addressable load balancing virtual servers are not configured with VIPs or Ports.
They act as internal resources to the Citrix ADC appliance. Traffic can be sent to them by
content-switching policies or virtual server backup methods like the backup virtual
server. Otherwise, non-addressable virtual servers cannot receive a direct connection
from an external source.
Exercise 4-2: Configure Content Switching by Content Type

(CLI)
Introduction:
In this exercise, you will learn to create a content-switching virtual server with policies that will
direct traffic to different virtual servers based on content type. This exercise also demonstrates
the use of pattern sets to simplify long, complex comparisons when constructing policy
expressions. You will use the command-line interface to perform this exercise.
Company ABC wants to set up their web application so that web requests can be handled by
different banks of servers for a specific application. For example, image content can be handled
127
by one bank of servers, dynamic or script content can be handled by another, and static content
(and everything else) by the third. They want to keep the initial scenario simple until they are
ready to move on to a more complex application. The initial demonstration will be based on the
Red, Blue, Green web servers to begin with.
The content-switching configuration in this scenario should be based on the following:
• Image content should be directed to the RED server.

• Script/Dynamic content should be directed to the BLUE server.
• All other content should be directed to the GREEN server.
The content type in a request can be identified by evaluating the extension contained in the
URL path for the object requested.
A new content-switching virtual server will be created: cs_vsrv_rbg_webcontent
(172.21.10.107:HTTP:80). The same non-addressable, load balancing virtual servers for the Red,
Blue, and Green content from the last exercise also will be used in this one.
About Pattern Sets:
This exercise also introduces the concept of Pattern Sets in expressions to simplify long,
complicated policies. For example, here is an advanced expression that can search for .jpg, .gif,
and, .png content types:
HTTP.REQ.URL.PATH.SUFFIX.EQ("jpg") || HTTP.REQ.URL.PATH.SUFFIX.EQ("gif")
|| HTTP.REQ.URL.PATH.SUFFIX.EQ ("png")
The Suffix() operator identifies the extension referenced in the path of the request URL
(without the leading ".").
The problem is that the more extensions you need to compare, the longer this expression will
get and the more difficult it is to maintain.
You can define a pattern set which contains all of the image extensions (or other items) of
interest. The pattern set can then be used with a single expression to see if a path matches any
of the values in the pattern set. The same comparison using a pattern set that contains the
appropriate suffixes for the extensions .jpg, .gif, .png would look like:
HTTP.REQ.URL.PATH.SUFFIX.EQUALS_ANY("ps_imagestuff")
• Create Pattern Sets for Content Types.

• Create Content-Switching Policies using Pattern Sets.
• Bind Content-Switching Policies to CS Virtual Server.
128
• Test Content-Switching Policies.
Create Pattern Sets for Content Types

Step Action
1. Create a pattern set to identify image content types by URL suffix - .jpg, .png, .gif, and .ico:
add policy patset ps_imagestuff
Bind values to the pattern set:

bind policy patset ps_imagestuff jpg
bind policy patset ps_imagestuff png
bind policy patset ps_imagestuff gif
bind policy patset ps_imagestuff ico
2. Create a pattern set to identify script content types by URL suffix - .cgi and .js:
add policy patset ps_scriptstuff
Bind values to the pattern set:

bind policy patset ps_scriptstuff cgi
bind policy patset ps_scriptstuff js
Create Content-Switching Policies Using Pattern Sets

Step Action
extensions found in the ps_imagestuff pattern set:
add cs policy cs_pol_imagestuff -rule

'HTTP.REQ.URL.SUFFIX.EQUALS_ANY("ps_imagestuff")'
extensions found in the ps_scriptstuff pattern set:
add cs policy cs_pol_scriptstuff -rule
'HTTP.REQ.URL.SUFFIX.EQUALS_ANY("ps_scriptstuff")'
Bind Content-Switching Policies to Content Switching Virtual Server

Step Action
1. Create a content-switching virtual server named cs_vsrv_rbg_webcontent. Bind the content-
switching policies. For each policy, set a target destination to the appropriate non-addressable
load balancing virtual server, for this scenario:
Create the content-switching virtual server:

add cs vserver cs_vsrv_rbg_webcontent HTTP 172.21.10.107 80
For this scenario:

129
2. Bind the content-switching policies for Image content so that traffic is sent to Red:
bind cs vserver cs_vsrv_rbg_webcontent -policyName cs_pol_imagestuff -targetLBVserver

lb_vs_red -priority 100
3. Bind the content-switching policies for Script content so that traffic is sent to Blue:
bind cs vserver cs_vsrv_rbg_webcontent -policyName cs_pol_scriptstuff -targetLBVserver

lb_vs_blue -priority 110
4. Configure the default destination for all unmatched traffic to be sent to Green:
bind cs vserver cs_vsrv_rbg_webcontent -lbvserver lb_vs_green

save ns config

Step Action
1. Open FireFox web browser and Live HTTP Headers. Clear the capture before testing.
Test the following URLs:
Click Download on this page. (This image file is intentionally large and may take a
several seconds to display.)
Expected Results:
• All content displays. In the web browser, the only "server color" displayed is Green.
• In Live HTTP Headers, verify different request objects are coming from the expected
servers by looking at the Served-by header in each response. This is a custom header
that is added by the web servers and which indicates the origin server for the content; it
was added for lab demonstration purposes only.
2. View the content-switching policy stats after the test cases:
show cs vserver cs_vsrv_rbg_webcontent
Identify how many hits were handled by the bound policies and how much content was handled
by the default destination (Green).
NOTE: There is no Default Content switching server is bound by default. Without this bound any
requests that do not match a policy will be dropped.
Key Takeaways:
• Content-switching decisions can be based on any request-time criteria. User agent
headers, request URLs, and content type, are all convenient policy criteria.
• Pattern sets make it easy to handle long, repetitive comparisons in a short, easy to read,
and easy to update policy expression. There is a maximum character limit to content
switching policies, and pattern sets can help avoid that.
130
• If the policy criteria need to change, pattern sets can be easily updated to contain
additional values or regular expression patterns.
• This exercise demonstrated an EQUALS_ANY() operator that performs a comparison
against a pattern set. Any of the <name>_any operators can take a pattern set as input:
equals_any, contains_any, before_str_any, after_str_any, and others.
Module 5: Optimization
Introduction:
Company ABC wants to ensure that the Citrix ADC is optimizing HTTP traffic by verifying that
HTTP compression is enabled and properly configured. The company wants to include an extra
policy to compress JavaScript content that is not being handled by the built-in policies. The
company wants you to confirm that compression is configured and working as expected.
The HTTP Compression feature requires that the feature is enabled globally and at the service
level. Built-in policies are applied automatically, but additional policies can be bound.
Compression also has global parameters that can be adjusted to control overall compression
behavior on the Citrix ADC.
In this module, you will perform hands-on exercises to verify the compression settings that are
configured in the environment. You will also create and bind a new compression policy and
confirm that it is working. You will also learn how to view compression statistics.
After completing the lab module, you will be able to:
• Enable the HTTP Compression feature.

• Configure and manage compression parameters.
• Create and bind custom compression policies.
This module contains the following exercises using the Citrix ADC Configuration Utility GUI and
Citrix ADC CLI:
• Exercise: Configuring Compression Policies

Before you Begin:
131
• ADC_VPX_01 • WebRed
• WebBlue • Ad.training.lab
Exercise 5-1: Configuring Compression Policies (GUI)

Introduction:
In this exercise, you will learn to configure the compression feature to use the default policy
engine and customize the compression behavior to compress content with JavaScript mime
types. You will use the Configuration Utility to perform this exercise.
The default compression policies on the Citrix ADC already compress most text-based mime
types except when compression is not compatible with a given browser. For example,
Mozilla/4.7 does not like compressed stylesheets (css), and MSIE does not like compressed XML
content.
Additional compression policies can be configured and bound to compress or not compress
HTTP content for unique criteria. Compression behavior can also be controlled by the global
compression feature parameters.
• Compression is enabled globally for all content.

• Compression feature is configured to use the default policy engine.
• Compression policy to be added to compress HTTP responses with JavaScript content.
• Confirmation that compression is occurring.
Use the load balancing virtual server lb_vsrv_rbg and its services for this exercise.
• Configure Compression Policies for JavaScript MIME types.
Configure Compression Policies for JavaScript MIME Types

Step Action
132
User Name: nsroot

Password: nsroot
2. Enable the Compression feature:

• Enable HTTP Compression.
• Click OK.
3. View Compression Settings at the service level for svc_red, svc_blue, and svc_green:

• Select svc_red and click Edit.
• Verify that compression is set to Yes under the Settings property category. If
compression is set to NO, click the Edit icon and change the parameter.
• Click Done.
Repeat verification for svc_blue and svc_green, and fix if necessary. Compression should be
enabled on all three services.
NOTE: In order for responses from web servers to be compressed, the feature must be enabled
globally and compression must also be enabled on each service. Otherwise, responses will not
be compressed.
4. Create a compression policy to compress JavaScript content based on the mime-type displayed
in the response-time header Content-Type. Create the expression inline instead of using a
named expression.
• Browse to Optimization > HTTP Compression > Settings, Change Compression Settings
> Policy Type > Advanced
• Click Add.
• Enter cmp_pol_javascript in the Policy Name field.
• Select Compress in the Response Action field.
Configure the policy expression:
• Configure the expression using the default syntax. Use either the inline editor or the
Expression Editor.
HTTP.RES.HEADER("Content-Type").CONTAINS("javascript")
Click Create.
133
5. Bind the compression policy to lb_vsrv_rbg:
• Click Select Action and from the drop-down list select Policy Manager.
• Select Load Balancing Virtual Server under Bind Point.
• Select Response under Connection Type.
• Select lb_vsrv_rbg under Virtual Server.
• Click Continue.
Select Policy to Bind and configure priorities:

• Select cmp_pol_javscript and click Select.
• Click Bind.
Click Done.
6. Change policy engine for global settings on compression feature:
• Browse to HTTP Compression > Settings.

• Click Change compression settings.
• Select ADVANCED from the Policy Type drop-down list box.
• Click OK.
Test Compression Policy

Step Action
1. Open Firefox and Live HTTP Headers:
• In Firefox, Click Tools > Live HTTP Headers. Verify that Capture is enabled.
• Click Clear to clear the display, if necessary.
2. In Live HTTP Headers, scroll to the top and look at the request and response headers for the
/jspage.php object. (This is not the JavaScript object).
Verify that the following request header is present:

• Accept-Encoding: gzip, deflate.
In the response headers, verify that the following headers are present:
• Content-Type: text/html; charset=UTF-8

• Content-Encoding: gzip
134
3. In Live HTTP Headers, next look at the request and response headers for the /common.js and
/external.js objects. These are the third and fourth objects in the list.
Verify the following request header is present:
• Accept-Encoding: gzip, deflate
• Content-Type: application/x-javascript
The JavaScript mime types are compressed.

4. View compression policy hits:
• Browse to Optimization > HTTP Compression > Policies.
View the hits next to the compression policies: cmp_pol_javascript and

ns_adv_cmp_content_type.
NOTE: To view ns_adv_cmp you need to view built-in compression policies.

5. View compression statistics:
• Browse to Optimization > HTTP Compression.

• Click Statistics in the right-pane. View the summary view of compression statistics.
• Click Details to see the full compression statistics.
The statistics view should show compression statistics from the beginning of the week, since the
compression feature has been enabled since the first exercise.
Key Takeaways:
• HTTP Compression is a response-time feature.
• In order for compression to occur, the global feature must be enabled and the
compression feature for each service must be enabled. If compression is not occurring
when expected, check both the feature and the service state.
• Changing the global setting does not change the compression setting at the service level
for existing services, but it does change the default setting for new services. If the CMP
feature is disabled globally, then new services will default to compression OFF. This may
result in having to manually update services to turn CMP on at the service level even
after changing the global feature state.
• Compression on the Citrix ADC can either use the classic engine or the default engine,
but only one type of policy can be in use at one time. Classic is on by default. To use the
default policies, change the global compression parameter for Policy Type to Advanced.
• All the default compression policies are bound to the RESPONSE-Time: Default Global
policy bank, starting at priority 8700. To implement your own compression policies, bind
them to a higher-precedent policy bank or user a higher priority (lower index).
135
136
Exercise 5-1: Configuring Compression Policies (CLI)
Introduction:
In this exercise, you will learn to configure the compression feature to use the default policy
engine and customize the compression behavior to compress content with JavaScript mime
types. You will use the command-line interface to perform this exercise.
The default compression policies on the Citrix ADC already compress most text-based mime
types except when compression is not compatible with a given browser. For example,
Mozilla/4.7 does not like compressed stylesheets (css), and MSIE does not like compressed XML
content.
Additional compression policies can be configured and bound to compress or not compress
HTTP content for unique criteria. Compression behavior can also be controlled by the global
compression feature parameters.
• Compression is enabled globally for all content.

• Compression feature is configured to use the default policy engine.
• Compression policy has been added to compress HTTP responses with JavaScript
content.
• Confirmation that compression is occurring.
Use the load balancing virtual server lb_vsrv_rbg and its services for this exercise.
• Configure Compression Policies for JavaScript MIME types.
Configure Compression Policies for JavaScript Mime Types

Step Action
User name: nsroot

Password: nsroot
2. Enable the Compression feature:
enable ns feature cmp
137
3. View and enable Compression settings for each service:
show service svc_red

show service svc_blue
show service svc_green
Verify that each service has HTTP Compression (CMP) set to YES.
If needed, update the service properties so that compression is enabled:
set service svc_red -cmp YES

set service svc_blue -cmp YES
set service svc_green -cmp YES
NOTE: In order for responses from web servers to be compressed, the feature must be enabled
globally and compression must also be enabled for each service. Otherwise, responses will not
be compressed
4. View compression engine to using the classic policy engine:
show cmp parameter
Verify that the compression policy type is set to Classic.
5. View the compression policy global bind point:
show cmp global
NOTE: Classic policies are bound to the cmp global bind point. These policies are all named
ns_cmp_ or ns_nocmp_. The advanced policies are bound to the Global:Response Default bind
point (RES_DEFAULT).
6. Generate some preliminary compression data. Compression statistics should already exist based
on other application testing up to this point. However, if no data is present, use the following
procedure to generate some additional test data.
Open a web browser and access the following URLs from Firefox, Chrome, or Internet Explorer:
NOTE: stylesheets (.css) will be compressed in MSIE and not in Firefox.

7. View current policy hits:
show cmp policy -summary
Notice that all the policy hits up to this point are with the classic policies only.
8. Change compression engine to using the default (Advanced) policy engine:
set cmp parameter -policyType ADVANCED
138
9. Generate additional compression data.
Open a web browser and access the following URLs from Firefox, Chrome, or Internet Explorer:
10. View current policy hits:
This time, the policy hits occur with the default policy engine. This is all the policies named
ns_adv_.
11. Create cmp policy to compress JavaScript content (mime-types):
add cmp policy cmp_pol_javascript -rule 'HTTP.RES.HEADER("Content-

Type").CONTAINS("javascript")' -resAction COMPRESS
12. Bind the compression policy to lb_vsrv_rbg:
bind lb vserver lb_vsrv_rbg -policyName cmp_pol_javascript -Priority 100

-gotoPriorityExpression END -type RESPONSE
Test Compression Policy

Step Action
1. Open Firefox and Live HTTP Headers:
• In Firefox, Click Tools > Live HTTP Headers. Verify that Capture is enabled. Click Clear to
clear existing capture data, if needed.
2. In Live HTTP Headers, scroll to the top and look at the request and response headers for the
/jspage.php object. (This is not the JavaScript object).
• Content-Type: text/html; charset=UTF-8

139
3. In Live HTTP Headers, next look at the request and response headers for the /common.js and
/external.js objects. These are the third and fourth objects in the list.
• Content-Type: application/x-javascript
The JavaScript mime types are now compressed.

4. View compression statistics:
stat cmp
stat cmp -detail
Compression statistics are present since the CMP feature has been enabled since the start of
class and default policies are compression most text-based content.
5. View policy hits:
This time the default (Advanced) policies are receiving hits:

• Most text-based content is hitting the built-in policy: ns_adv_cmp_content_typ
• JavaScript-based content hit the custom policy: cmp_pol_javascript
If you repeat the test with Internet Explorer, you may also see the ns_adv_cmp_mscss policy hit
for CSS stylesheets.
save ns config
Key Takeaways:
• HTTP Compression is a response-time feature.
• In order for compression to occur, the global feature must be enabled and the
compression feature for each service must be enabled. If compression is not occurring
when expected, check both the feature and the service state.
• Changing the global setting does not change the compression setting at the service level
for existing services. However, it does change the default setting for new services. If the
CMP feature is disabled globally, then new services will default to compression OFF. This
may result in having to manually update services to turn CMP on at the service level
even after changing the global feature state.
• Compression on the Citrix ADC can use either the classic engine or the default engine,
but only one type of policy can be in use at one time. Classic is on by default. To use the
default policies, change the global compression parameter for Policy Type to Advanced.
140
• All the default compression policies are bound to the RESPONSE-Time: Default Global
policy bank, starting at priority 8700. To implement your own compression policies, bind
them to a higher-precedent policy bank or user a higher priority (lower index).
141
Module 6: Global Server Load Balancing (GSLB)

Introduction:
In the GSLB, Citrix ADC acts as a DNS server to provide the DNS reply based on the various
parameters to provide the best user experience.
While providing the reply the Citrix ADC takes following in to consideration:
• Status of the entity.
• Give out the IP address that is closest to the user (proximity load balancing).
• Give out different IPs for internal vs external (DNS View).
GSLB is only useful if the setup consists of a single domain name that could resolve to multiple
IP addresses.
Following are some typical GSLB configurations:
• Active-active data center setup. Consists of multiple active data centers. Client requests
are load balanced across active data centers.
• Active-standby data center setup. Consists of an active and a standby data center.
When a failover occurs as a result of a disaster event, the standby data center becomes
operational.
• Proximity setup. Directs client requests to the data center that is closest in geographical
distance or network distance.
Scenario:
Company ABC has a web application available in two of its locations.
• One is based in Frankfurt, Germany and the other is based in Tokyo, Japan.
• The company wants to implement Global Server Load Balancing (GSLB) so that the
Frankfurt and Tokyo instances of the web application can be accessed using a common
URL http://globalweb.training.lab.
The initial configuration will just demonstrate that GSLB will work with a basic Active/Active
configuration using round robin.
The GSLB configuration in this scenario should be based on the following:
Citrix ADC Appliances:
• ADC_VPX_01 and ADC_VPX_02 will remain in an HA Pair and will make up the Frankfurt
location and its resources.
142
• ADC_VPX_03 will be a standalone Citrix ADC in the Tokyo site, hosting the Tokyo
resources. Redundancy will not be implemented for the Tokyo location at this time.
Web Resources:
• The Frankfurt web application will be configured as lb_vsrv_ffm and will be bound to the
existing WebGreen web server.
• The Tokyo web application will be configured using the lb_vsrv_tok and will be bound to
the REMOTE web server, which is similar to WebRed.
A successful demonstration of GSLB will require that users from the Student Desktop can access
the URL http://globalweb.training.lab and successfully connect to the intended resource. DNS
will be handled using a DNS proxy configuration on the Citrix ADC and by updating the local
clients to use the DNS proxy (load balancing virtual server) on the Frankfurt HA Pair as the
workstation's DNS server.
The following diagram illustrates the Citrix ADC, IP addresses and entities that will be
configured in this exercise.
Figure 1: GSLB Site Diagram
• Create GSLB Sites, GSLB Services, and GSLB virtual servers.

• Configure an active/active GSLB virtual server configuration that will alternate between
available IP addresses.
143
• Configure an active/passive GSLB virtual server configuration that will be used to direct
traffic to a primary location and will then direct traffic to a backup destination only
when the primary is DOWN.
This module contains the following exercises using the Citrix ADC Configuration Utility GUI and
Citrix ADC CLI:
• Exercise 1: Configuring Active/Active GSLB

• Exercise 2: Testing GSLB with DNS Proxy Configuration
• Exercise 3: Configuring GSLB for Active/Passive Scenario
• Exercise 4: Configuring Active/Active GSLB (Using Citrix ADC GSLB Wizard)
NOTE: The exercsie 7-4, we will be using Citrix ADC GSLB Wizard to configure GSLB
Active/Active setup. It is an optional exercise; no class time will be allotted to complete it but
you are encouraged to utilize any free time during the course to complete it.
We will be configuring the exactly same setup in exercise 7-1 and exercise 7-4 so make sure you
take the snapshots the Virtual Machines as instructed.
Before you Begin:


• ADC_VPX_03 • AD02.training.lab
• WebBlue • WebRemote
• WebRed
144
Exercise 6-1: Configuring Active/Active GSLB (GUI)
Introduction:
In this exercise, you will learn to configure Global Server Load Balancing on Citrix ADC
appliances in two sites. You will use the Configuration Utility to perform this exercise.
This initial configuration will verify that GSLB can distribute traffic between the two sites and
will configure an active/active configuration that alternates between Frankfurt and Tokyo using
GSLB round robin.
This exercise will demonstrate the following concepts of GSLB:
• GSLB site, GSLB service, and GSLB virtual server configuration.

• GSLB site to site communication using MEP.
• Requirements and procedures for GSLB Synchronization.
• Configure the Frankfurt and Tokyo GSLB Sites.

• Create the GSLB Services for the Frankfurt and Tokyo load balancing virtual servers.
• Configure the GSLB load balancing virtual server for an active/active distribution.
• Complete GSLB synchronization between the Frankfurt and Tokyo Citrix ADC appliances.
• Prepare for GSLB on the Citrix ADC HA Pair for Frankfurt.

• Create the GSLB Site on the Citrix ADC HA Pair for Frankfurt.
• Create the GSLB Site on the Citrix ADC for Tokyo.
• Configure GSLB Services and Virtual Server on the Citrix ADC HA Pair for Frankfurt.
• Synchronize the GSLB Configuration between Frankfurt and Tokyo sites.
NOTE: In this exercise, you will be required to switch between Citrix ADC appliances to make
configurations. You will be told which Citrix ADC to connect to at which point.
Take Snapshot of the Virtual Machine
NOTE: This is an optional step, required if you wish to perform Exercise 7-4.
Step Action
1. Launch Citrix XenCenter by clicking on the icon located on the desktop.
145
2. Take snapshot of ADC_VPX_01
• Right Click on ADC_VPX_01 and click Snapshots>Take a snapshot…

• Enter Name as ADC_VPX_01_state1.
• Select Snapshot the virtual machine’s disks.
• Click Take Snapshot.


Prepare for GSLB on the Citrix ADC HA Pair for Frankfurt

• Before this lab begins please ensure the following vms have been started:
• WebRemote.
Step Action
5. Connect to the Citrix ADC HA Pair for Frankfurt using ADCMGMT at http://192.168.10.103.
User Name: nsroot

Password: nsroot
6. Create a load balancing virtual server for the Frankfurt web site:

• Click Add.
• Enter lb_vsrv_ffm in the Name field.
• Verify HTTP is selected for the Protocol.
• Verify 80 is selected for the Port.
• Click OK.
7. Bind service svc_green to the lb_vsrv_ffm. This will represent the Frankfurt web content:
• Click Load Balancing Virtual Server Service Binding.
• Click Click to Select in the Select Service field.
• Click Bind.
• Click Continue.
• Click Done.
Verify that lb_vsrv_ffm is UP. If not, click Refresh to update the Citrix ADC view.
146
8. Enable the GSLB feature:
Method 1:
• Browse to Traffic Management > GSLB.
• Right-click the Yellow icon (!).
• Observe that the Yellow icon (!) has disappeared.
Method 2
• If the Yellow icon (!) is not present in front of GSLB, go to the next step as GSLB is
already enabled.
• Click Configure Advanced Features.
• Select Global Server Load Balancing to enable.
• Click OK.
Create the GSLB Site on the Citrix ADC HA Pair for Frankfurt
Step Action
1. Create the GSLB Site for the Frankfurt HA Pair. Use the management SNIP (192.168.10.103) as
the GSLB site IP address:
• Browse to Traffic Management > GSLB > Sites.

• Click Add.
• Enter site_ffm in the Name field.
• Enter 192.168.10.103 in the Site IP Address field.
• Click Create.
• site_ffm is identified as LOCAL under type.

• Metric Exchange is enabled, but no MEP status is displayed. This is expected for the
local site.
2. Create the GSLB site for the Tokyo Citrix ADC. Use the management SNIP (172.22.15.211) as the
site IP address:
• Click Add.
• Enter site_tok in the Name field.
• Click Create.

• The site_tok is identified as REMOTE under type. This site represents a remote Citrix
ADC.
• Metric Exchange is enabled but the MEP status is DOWN. This is expected behavior until
the Tokyo Citrix ADC is configured in a later exercise.
147
3. Verify that the GSLB site IP address function is running on a Citrix ADC-owned IP address for the
Frankfurt HA pair:
• Browse to System > Network > IPs.

• Confirm the management SNIP 192.168.10.103 is being used for both SNIP and GSLB
functions.
Create the GSLB Site on the Citrix ADC for Tokyo

Step Action
1. Connect to the ADC_VPX_03 for Tokyo using its NSIP at http://172.22.15.201.
User Name: nsroot

Password: nsroot
For best results, open NS_VPXP_03 in a second browser window so you can switch back and
forth between the configuration utility GUI for the Citrix ADC HA Pair and ADC_VPX_03.
Exercises will indicate when to switch between systems.
2. ADC_VPX_03 (172.22.15.201) - Enable GSLB Feature:
Method 1:
Method 2
already enabled.
• Click OK.
3. Create the GSLB Site for the Tokyo Citrix ADC. Use the management SNIP (172.22.15.211) as the
Site IP address:

• Click Add.
• Click Create.
• site_tok is identified as LOCAL to this Citrix ADC.

• Metric Exchange is enabled, but no MEP status is displayed. This is expected for the
local site.
148
the GSLB Site IP address:
• Click Add.
• Click Create.
Wait a few seconds after creating the site and then click Refresh to update the Citrix ADC view.
• site_ffm is identified as REMOTE to this Citrix ADC.

• Metric Exchange is enabled.
• MEP status is now Active.
Once both GSLB sites have been configured with valid IP addresses on both Citrix ADC
appliances, Metric Exchange Protocol (MEP) is successful and the MEP status for the REMOTE
site on each respective Citrix ADC will now be UP.
NOTE: This may take a few minutes to show.

5. Verify that the GSLB site IP address function is running on a Citrix ADC-owned IP address for the
Tokyo Citrix ADC:
• Browse to System > Network > IPs.

• Confirm that the SNIP 172.22.15.211 is being used for both SNIP and GSLB functions.
6. ADC_VPX_03 (172.22.15.201) - Save the Citrix ADC configuration and confirm.
7. Switch to NSHA Mgmt (192.168.10.103).
8. NSHA MGMT (192.168.10.103) - Verify that GSLB Sites are also UP with MEP active on the
Frankfurt Citrix ADC HA Pair as well.
The following details should be displayed:
•site_ffm should be identified as the LOCAL site for this Citrix ADC.
•site_tok should be identified as the REMOTE site for this Citrix ADC. MEP Status is now
ACTIVE.
9. NSHA MGMT (192.168.10.103) - Save the Citrix ADC configuration and confirm.
Configure GSLB Services and Virtual Server on the Citrix ADC HA Pair for
Frankfurt
Step Action
1. Remain on ADCMGMT (192.168.10.103). Do not configure ADC_VPX_03 (172.22.15.201) until
instructed to do so.
149
2. Create the GSLB Service for the Frankfurt load balancing virtual server (lb_vsrv_ffm). Configure
the GSLB service using the virtual IP address:
• Browse to Traffic Management > GSLB > Services.

• Click Add.
Configure the GSLB Service Basic Settings:
• Enter gslb_svc_ffm under Service Name.

• Select site_ffm under Site Name.
• Verify that HTTP and 80 are selected for Protocol and Port.
• Select the Virtual Servers.
• In the Virtual Servers field select lb_vsrv_ffm from the drop-down.
• Observe that the Server IP and Public IP have populated as 172.21.10.122. Also, the
Public port is now 80.
• Click OK.
• Click Done.
Verify the GSLB service state:
• Click Refresh to update the Citrix ADC view.

• Verify that the service State is UP and the Effective State is UP.
NOTE: GSLB Services can be created from named server objects, existing virtual servers, or by
specifying the IP address and letting the Citrix ADC create the server object behind the scenes.
3. Create the GSLB Service for the Tokyo load balancing virtual server (lb_vsrv_tok). Configure the
GSLB service using the virtual IP address.
• Click Add.
• Enter gslb_svc_tok under Service Name.

• Select site_tok under Site Name.
• Select New Server.
NOTE: On the web page If the Server Name field is shown and shows an in-use server. If an
error occurs, switch between New Server - Existing Server - New Server until the Server
Name* field is hidden.
• Enter 172.22.15.231 in the Server IP Address field. (This is the VIP for lb_vsrv_tok).
• Click OK.
• Click Done.
Verify the GSLB service state:
• Wait a few seconds and click Refresh to update the Citrix ADC view. (It may take a time
or two for all service’s status to be reported.)
• Verify that the Service State is UP and the Effective State is UP.
150
4. Create the GSLB virtual server:
• Browse to Traffic Management > GSLB > Virtual Servers.

• Click Add.
Configure the GSLB virtual server basic settings:
• Enter gslb_vsrv_global in the Name field.

• Verify HTTP is selected for the Service Type.
• Click OK. The virtual server is created with initial settings.
Keep the GSLB Virtual Server properties open and continue to the next step.
5. Bind the GSLB services to the GSLG virtual server:
• Click No GSLB Virtual Server to GSLB Service Binding..

• GSLB Service Binding dialog window will open.
• Select the gslb_svc_ffm and gslb_svc_tok services and click Select.
• Click Bind.
• Click OK.
6. Bind the FQDN to the virtual server that GSLB will be used to resolve:
• In the field GSLB Virtual Server Domain Binding, click No GSLB Virtual Server Domain
Binding.
• The Domain Binding dialog box will appear.
• Enter globalweb.training.lab in the FQDN field.
• Click Bind.
• Click OK.
Click Done to close the GSLB Virtual Server properties.

7. Configure Load Balancing Method:
• Click Edit (pencil icon) for the Method section.

• Select ROUNDROBIN in the Choose Method drop-down list box to set the primary load
balancing method.
• Observe that now the Backup Method is LEASTCONNECTION.
• Click OK to apply settings.
Click Done.
8. Verify the GSLB virtual server state:
• Click Refresh to update the Citrix ADC view.

• Verify that the virtual server state is UP.
151
9. Test that GLSB is resolving the FQND to the correct service from the Citrix ADC.
• Browse to System > Diagnostics.

• Click Command-line interface under Utilities.
• Enter the following command in the Command field and click Go:
ping -c 2 globalweb.training.lab
• Repeat the command a second time. Manually enter it or use the drop-down list box in
the Command field to select the previous command. Click Go:
• Note the IP address returned for each test.

• Click Close to close the CLI dialog box.
Each time the ping test is repeated, a different IP address is returned. The response should
alternate between 172.21.10.122 (Frankfurt) and 172.22.15.231 (Tokyo).
10. ADCMGMT (192.168.10.103) - Save the Citrix ADC configuration and confirm.
Synchronize the GSLB Configuration between Frankfurt and Tokyo Sites

Step Action
1. Arrange both browsers so that you can easily switch back and forth to make configuration
changes:
• Connect to ADCMGMT at http://192.168.10.103.

• Connect to NS_VPXP_03 at http://172.22.15.201.
2. NS_VPXP_03 (172.22.15.201) - Verify state before beginning synchronization.
View GSLB Sites:

• Verify that both GSLB sites are present and in an UP state. Remember that MEP Status
will not display for the local site site_tok on the Tokyo Citrix ADC.
Verify that other GSLB resources are not configured:
• Browse to Traffic Management > GSLB > Services. Verify that no GSLB services are
listed.
• Browse to Traffic Management > GSLB > Virtual Servers. Verify that no GSLB virtual
servers are listed.
3. Switch to ADCMGMT (192.168.10.103).
NOTE: Be sure you are connected to 192.168.10.103 for this next step, or you will lose
configuration settings.
152
4. ADCMGMT (192.168.10.103) - Synchronize the GSLB configuration from NSHA MGMT to

NS_VPXP_03.
NOTE: The GSLB Site, GSLB Services, and GSLB Virtual Server were created in the previous steps.
The GSLB configuration can be pushed from this Citrix ADC to the GSLB partner site using GSLB
synchronization. GSLB synchronization is not automatic and must be manually triggered. Also
note that GSLB sites do not have a hierarchy, and the synchronization is always pushed from the
Citrix ADC the command is issued on to the designated sites, overwriting their configuration. It
is possible to run this command on the wrong Citrix ADC and lose settings.
Also, for GSLB synchronization to work, the GSLB sites must be configured on all partner Citrix
ADC appliances with the same site name as the system with the authoritative configuration, or
else the synchronization will fail.
Synchronize the GSLB Configuration from NSHA MGMT to ADC_VPX_03:
• Browse to Traffic Management > GSLB> Dashboard.

• Click Auto Synchronization GSLB.
• Select ForceSync.
• Select site_tok under GSLB Site Name. This limits the configuration synchronization to
the single target site when multiple sites are available. Default is ALL sites.
• Click Run.
• Synchronize GSLB Configuration, window will appear. Observe the sync process.
• Click Close, once the process completes
• Click Close.
5. View Synchronization State to verify that synchronization worked:
• Click View Synchronization State under GSLB Configuration.
• In case a message, Some of the commands failed, is reported under Applying Changes,
please ignore the error message.
• Click Close.
About GSLB Synchronization:

More than likely, GSLB synchronization was successful for the intended GSLB Services and GSLB
Virtual Servers. However, the GSLB configuration also synchronizes content-switching virtual
servers and related entities. You receive a report of a failure; some of the load balancing virtual
servers used with an existing CS virtual server configuration in the lab did not replicate to the
partner Citrix ADC.
We will manually confirm that the replication completed successfully.

7. Switch to ADC_VPX_03 (172.22.15.201).
153
8. Verify that GSLB configuration synchronized successfully:
View GSLB Sites:

• Verify that both GSLB sites are present and in an UP state. This should not have
changed.
Verify GSLB Services:
• Browse to Traffic Management > GSLB > Services. Refresh the Citrix ADC view, if
needed.
• Verify that both services, gslb_svc_ffm and gslb_svc_tok, are present and in an UP
state.
Verify GSLB Virtual Servers:
• Browse to Traffic Management > GSLB > Virtual Servers. Refresh the view, if needed.
• Verify that gslb_vsrv_global is present and in an UP sate.
• Select gslb_srv_global and click Edit.
• Verify that both services are bound.
• Verify that the FQDN globalweb.training.lab is bound under Domains.
• Click Done.
The GSLB Synchronization option to save the configuration will not apply to remote nodes if
there are synchronization command failures. So, the save configuration must be manually
performed.
Key Takeaways:
• GSLB Sites are configured to represent the Citrix ADC appliances participating in the
GSLB configuration. Citrix ADC appliances in a GSLB configuration communicate to the
GSLB Site IP address of partner Citrix ADC.
• GSLB Services represent the potential IP addresses that the FQDN can be resolved to by
GSLB. The GSLB Services generally correspond to the IP address of the intended target
virtual servers where the traffic will be sent. In this case, the GSLB service IP addresses
correspond to the target load balancing virtual server IPs (lb_vsrv_ffm and lb_vsrv_tok).
• GSLB Services have an UP and DOWN status like regular services. GSLB virtual servers
will only select a GSLB service in an UP state. GSLB Service status is controlled by the
MEP communication between sites. If monitors are bound to GSLB services, then
monitors control the UP and DOWN state of the service, overriding MEP.
• GSLB virtual servers determine the GSLB load balancing distribution method and can be
configured for active/active load balancing, client proximity load balancing, or
active/passive load balancing.
154
• Citrix ADC appliances in a GSLB configuration are independently configured from each
other. To ensure that the GSLB configuration is properly configured on all participatory
sites, the GSLB synchronization command can be used to synchronize the GSLB parts of
the configuration with other sites. The synchronization process uses the system the
command is issued from as the source (authoritative) configuration and then
synchronization overrides the target site or sites.
• In order for GSLB synchronization to work, the GSLB feature must be enabled on all
participant nodes and GSLB sites must already be created on each node for themselves
and the partner locations (each site must know about all other sites). The site names
must be configured the same across Citrix ADC appliances for synchronization to work.
Exercise 6-2: Testing GSLB with DNS Proxy Configuration (GUI)
Introduction:
In this exercise, you will learn to integrate the GSLB configuration with the DNS resolution
process. You will use the Configuration Utility to perform this exercise.
For this exercise, the existing DNS load balancing virtual server will be used as a DNS Proxy
configuration. The DNS load balancing virtual server VIP will be set as the workstation's DNS
server IP address. This will result in all DNS lookups requested by the client to be directed to the
load balancing virtual server.
Once the GSLB virtual server has domain names bound, the Citrix ADC will recognize these
FQDNs as GSLB-based resolutions. Requests for non-GSLB entities will be handled by the DNS
load balancing virtual server. Requests for name resolution of FQDN associated with GSLB
virtual servers will be intercepted by the Citrix ADC and handled as a GSLB resolution, and not
sent to the DNS services for the domain.
• Testing GSLB with DNS Proxy Configuration.
Testing GSLB with DNS Proxy Configuration

Step Action
1. Attempt to resolve globalweb.training.lab from the Student Desktop:
Open a cmd prompt: Right-click Start and select Command Prompt.
ping -n 2 globalweb.training.lab
NOTE: This will currently fail, as the client local DNS name resolver is currently trying to resolve
the request.
155
2. Configure the Student Desktop with the DNS Proxy load balancing virtual server on the Citrix
ADC (lb_vsrv_dns).
Open the Windows Network and Sharing Center Control panel. Right-click on the Network icon
in the system tray or use the detailed steps below.
• Open Control Panel: Start > All Apps > Windows System > Control Panel.
• Click Network and Sharing Center.
Update the DNS Settings on the lab interface:
• Click Change Adapter Settings.

• Right-click Ethernet Network X and click Properties.
• Select Internet Protocol Version 4 (TCP/IPv4) and click Properties. Do not clear this
check box.)
• Change the Preferred DNS Server from 192.168.30.11 to 172.21.10.102. (This is the VIP
assigned to the lb_vsrv_dns.)
• Click OK.
• Click Close to close the Ethernet Network X Properties.
3. Test that DNS resolution for internal training.lab FQDNs is working:
webred.training.lab should resolve to 192.168.30.51

4. Test GSLB resolution for globalweb.training.lab with nslookup:
nslookup globalweb.training.lab 172.21.10.102
Repeat the command multiple times and verify that the results alternate between IP addresses
172.21.10.122 and 172.22.15.231.
5. Switch to ADCMGMT at http://192.168.10.103.
6. Enable MIR (Multiple IP Address Response) on the GSLB virtual server:

• Select gslb_vsrv_global and click Edit.
• Click Edit (pencil icon) for Basic Settings.
• Enable Send all “active" service IPs’ in response (MIR) under When this Virtual Server
is UP.
• Click OK to close the Basic Settings.
• Click OK for all the other settings when prompted.
• Click Done to close the GSLB Virtual Server properties.
NOTE: If you see any warning regarding the ADNS service or DNS vserver please ignore it at this
point.
7. ADCMGMT (192.168.10.103) - Save the Citrix ADC Configuration and confirm.
8. Return to the CMD prompt on Student Desktop.
156
Repeat the command a few times.
NOTE: This time nslookup returns with both possible IP addresses for the name resolution. The
preferred order still alternates.
The MIR (Multiple IP Address Response) asks the GSLB configuration to return all available IP
addresses during a name resolution. Every GSLB service in an UP state will be returned. The
current preferred load balancing service will be listed first, but other available IP addresses are
returned as well. When MIR is disabled, only a single IP address is returned for each lookup
which is the current preferred GSLB decision for that transaction.
The MIR option is used to help mitigate some of the effects of an intermediate device caching a
DNS query. If a previous query was cached, then one or more potential alternate IP addresses
are included, in case the primary IP is down by the time the cached result is being used.
10. Disable MIR (Multiple IP Address Response) on the GSLB virtual server:

• Click Edit (pencil icon) for Basic Settings.
• Disable Send all “active" service IPs’ in response (MIR) under When this Virtual Server
is UP.
• Click OK to close the Basic Settings.
• Click OK for all the other settings when prompted.
• Click Done to close the GSLB Virtual Server properties.
11. Test GSLB in the Web Browser:
• Open Firefox and connect to http://globalweb.training.lab/remote.php

• Open Chrome and connect to http://globalweb.training.lab/remote.php
Between the two browsers, remote.php should display GREEN and German content when served
from the Frankfurt Citrix ADC HA Pair, and it should display RED and Japanese content when
served from the Tokyo Citrix ADC.
NOTE: The browsers will tend to cache the DNS resolution and not update the IP address for
each refresh. Alternatively, you can flush the DNS cache on the Student Desktop between tests.
From the cmd prompt run:
ipconfig /flushdns
Key Takeaways:
• DNS requests for GSLB-based names have to get to the Citrix ADC to be resolved using a
GSLB-based process.
• Citrix ADC GSLB can integrate with DNS through sub-delegation, ADNS configurations, or
the DNS Proxy configuration illustrated in the exercise.
157
• Normal GSLB behavior defaults to the settings, Multiple IP Response (MIR) is Disabled,
and Empty Down Response (EDR) is Disabled. When multiple GSLB services are UP, only
a single IP address is returned during the GSLB resolution. The IP address that is
returned is the preferred IP address given the current load balancing method. If all
services are DOWN, then GSLB will return all IP addresses associated with all services as
a potential connection point, though they are all currently DOWN. The MIR and EDR
settings can be adjusted to override this behavior in order to mitigate some of the
impacts of an intermediate device caching a previous DNS query.
• If Empty Down Response (EDR) is enabled, then the behavior when all services are
DOWN changes so that no IP address is returned. When no services are available, GSLB
returns no results, avoiding a situation where an intermediate device would cache a
DOWN response, forcing a new DNS lookup to be performed to find an available service
at a later point in time.
• If Multiple IP Response (MIR) is enabled, then when multiple services are UP instead of
returning a single IP address in the DNS resolution response, the Citrix ADC will return all
available services in an UP state in a preferred order. If an intermediate device were to
cache this DNS resolution, then it at least has the preferred service available at the time
the request was cached and a list of other potential IP addresses if the preferred service
is DOWN at a later point in time.
Exercise 6-3: Configuring GSLB for Active/Passive Scenario

(GUI)
Introduction:
In this exercise, you will learn to configure GSLB in an Active/Passive configuration for use as a
data center failover solution. You will use the Configuration Utility to perform this exercise.
The configuration will use the existing GSLB configuration and add an additional GSLB virtual
server to it. The Citrix ADC HA pair (ADC_VPX_01 and ADC_VPX_02) will host the primary data
center using the Frankfurt resource (lb_vsrv_ffm). ADC_VPX_03 will act as the backup data
center using the Tokyo resource (lb_vsrv_tok). Only when the Frankfurt Web server or the Citrix
ADC HA pair is offline, should traffic failover to the Tokyo web server.
• Configure GSLB for Active/Passive Failover.

• Test the Active/Passive Configuration.
Configure GSLB for Active/Passive Failover
158
Step Action
1. ADCMGMT (192.168.10.103) - Create a new GSLB virtual server as a backup virtual server.

• Click Add.
Configure the GSLB virtual server basic settings:
• Enter gslb_vsrv_backup in the Name field.

• Click OK. The virtual server is created with initial settings.
2. Bind the Tokyo service to the backup GSLB virtual server:
• Click No GSLB Virtual Server to GSLBService Binding.

• In the Select Service field, click Click to select.
• Select gslb_svc_tok and click Select.
• Click Bind.
Click OK for all the other settings.

Click Done to close the window.
Click Refresh and verify that the backup virtual server gslb_vsrv_backup is UP
3. Update the Frankfurt service, so that it only points to the Frankfurt GSLB service by unbinding
the Tokyo service:

• Click 2 GSLB Virtual Server to GSLBService Bindings under GSLB Virtual Server GSLB
Service Binding.
• Select gslb_svc_tok, click Unbind and Yes to confirm.
• Click Close.
Keep the GSLB Virtual Properties open.

4. Configure the GSLB virtual server gslb_vsrv_global with a backup virtual server, using
gslb_vsrv_backup:
• Click Backup Virtual Server under Advanced Settings (right-pane).

• Select gslb_vsrv_backup from the Backup Virtual Server drop-down list box.
• Click OK to apply the Backup Virtual Server setting.
Click Done.
159
6. ADCMGMT (192.168.10.103) - Synchronize the GSLB Configuration from NSHA MGMT to

ADC_VPX_03:
• Browse to Traffic Management > GSLB > Dashboard.

• Click Auto Synchronization GSLB.
• The Synchronize GSLB Configuration window will open.
• Select ForceSync.
• Select site_tok under GSLB Site Name. This limits the configuration synchronization to
the single target site when multiple sites are available. Default is ALL sites.
• Click Run.
• Observe the sync progress in the Synchronize GSLB Configuration window.
• Close the window once sync is complete.
• Click Close.
7. Switch to ADC_VPX_03 (172.22.15.201).
8. Verify that GSLB configuration synchronized successfully:
Verify GSLB Virtual Servers:
• Browse to Traffic Management > GSLB > Virtual Servers. Refresh the view, if needed.
• Verify that gslb_vsrv_global is present and in an UP state.
• Verify that gslb_vsrv_backup is present and in an UP state.
Test the Active/Passive Configuration

Step Action
1. On the Student Desktop, use the CMD prompt and test GSLB resolution for
globalweb.training.lab with nslookup:
NOTE: This time, nslookup only returns a single IP address for the Frankfurt virtual server:
17.21.10.122.
2. Switch ADCMGMT (192.168.10.103):
Disable the Frankfurt load balancing virtual server to simulate an outage. This will cause the gslb
service gslb-svc_ffm to go down, which will result in the GSLB virtual server gslb_vsrv_global
going DOWN. The backup virtual server will be used, and traffic will now failover to lb_vsrv_tok
on the Tokyo Citrix ADC.

• Right-Click on lb_vsrv_ffm and select Disable.
160
NOTE: This time nslookup only returns a single IP address for the Tokyo virtual server:
172.22.15.231.
Key Takeaways:
• Multiple GSLB virtual servers can be associated with a single GSLB site configuration.
• GSLB services can represent entities on remote Citrix ADC appliances and they can
report an UP or DOWN status by using MEP.
• GSLB virtual servers can be configured with backup virtual servers, which will only be
used when services on the primary virtual server fail.
161
Exercise 6-4: Configuring Active/Active GSLB (Using Wizard)
This is an exercise to demonstrate the use of the GSLB Wizard.

With Citrix ADC version 12, wizard is available to configure GSLB.
The Wizard can be used to configure following deployment modes:
1] Active/Active GSLB Mode.

2] Active/Passive GSLB Mode.
3] Parent/Child Topology.
In this exercise, we will be configuring GSLB Active/Active configuration.
NOTE: The end result of this exercise will be exactly as that of Exercise 7-1.
Restore the Snapshot of the Virtual Machine

NOTE: We need to remove the GSLB configuration done in the previous exercises to perform
this exercise. We will be reverting the configuration to end of Exercise 6-1 by using the
snapshots taken earlier.
Step Action
1. Launch Citrix XenCenter by clicking on the icon located on the desktop.
162
2. Restore ADC_VPX_01
• Click ADC_VPX_01
• On the right pane, click Snapshots.
• Click ADC_VPX_01_state1 in the Snapshots tab.
• Click Revert To…
• Clear the checknbox for Take a snapshot of the VM’s current state and revert.
• Click Yes.
• Click Yes.
• Click Yes.

Step Action
163
1. Connect to the Citrix ADC HA Pair for Frankfurt using ADCMGMT at http://192.168.10.103.
User Name: nsroot

Password: nsroot
2. Create a load balancing virtual server for the Frankfurt web site:

• Click Add.
• Enter lb_vsrv_ffm in the Name field.
• Verify HTTP is selected for the Protocol.
• Verify 80 is selected for the Port.
• Click OK.
3. Bind service svc_green to the lb_vsrv_ffm. This will represent the Frankfurt web content.
• Click No Load Balancing Virtual Server Service Binding.

• Click Bind.
• Click Continue.
• Click Done.
Verify that lb_vsrv_ffm is UP. If not, click Refresh to update the Citrix ADC view.
4. Enable the GSLB feature:
Method 1:
Method 2:
already enabled.
• Click OK.
Configure GSLB on the Citrix ADC HA Pair for Frankfurt

Step Action
164
5. Access the GSLB Wizard to enter Domain:

• Click Get Started.
• Select Active-Active Site.
• Enter FQDN as globalweb.training.lab
• Click OK.
• Click Continue.
the GSLB site IP address:
• In the GSLB sites section, Click Add Sites under No Site Present in the system.
• Select Type as LOCAL.
• Select Site IP Address as 192.168.10.103.
• Click Create.
• site_ffm is identified as LOCAL under type.

• Metric Exchange is enabled.
7. Create the GSLB site for the Tokyo Citrix ADC. Use the management SNIP (172.22.15.211) as the
site IP address:
• Click Add Sites.

• Click Create.
• site_tok is identified as REMOTE under type. This site represents a remote Citrix ADC.
• Metric Exchange is enabled but the MEP status is DOWN. This is expected behavior until
the Tokyo Citrix ADC is configured in a later exercise.
Click Continue.
the GSLB service using the virtual IP address.

• Confirm the site name is site_ffm. If not select site_ffm from drop-down.
• In the Virtual Servers field select lb_vsrv_ffm from the drop-down.
• Click Create.
165
GSLB service using the virtual IP address:
• Click Add Services.

• Select site_tok under Site Name.
NOTE: On the web page If the Server Name field is shown and shows an in-use server. If an
error occurs, switch between New Server - Existing Server - New Server until the Server
Name field is hidden.
• Click Create.
Click Continue.
10. Configure the GSLB virtual server basic settings:

Configure Service and Domain Binding

• In the Select Service field click “>” icon to add service if not auto populated.
• Select gslb_svc_ffm and gslb_svc_tok and Click Select.
• In the Domain Binding field click “>” icon to add Domain if not auto populated.
• Select globalweb.training.lab and Click Select.
Configure GSLB method:

• Select Algorithm based.
• Confirm the method is ROUNDROBIN.
Click Create.
Click Continue.
Click Done.
NOTE: The status of the Remote GSLB service and GSLB Site will be down. This is expected
behavior, as the other side is not yet configured.
Configure GSLB on the Citrix ADC for Tokyo

Step Action
166
1. Connect to the ADC_VPX_03 for Tokyo using its NSIP at http://172.22.15.201.
User Name: nsroot

Password: nsroot
2. Configure DNS Service
• Click Add.
• Enter Service Name as dns_svc.
• Enter IP Address 192.168.30.12.
• Select Protocol DNS.
• Click OK.
• Click Done.
3. Configure DNS Vserver:
• Click Add.
• Enter Virtual Server Name as dns_vsrv
• Enter IP Address 172.22.15.20
• Select Protocol as DNS.
• Click OK.
• Click No Load Balancing Virtual Server Service Binding.
• In the Service Binding window, Click Click to select.
• Select the service dns_svc, Click Select.
• Click Bind.
• Click Continue.
• Click Done.
4. ADC_VPX_03 (172.22.15.201) - Enable GSLB Feature:
Method 1:
Method 2:
already enabled.
• Click OK.
5. Access the GSLB Wizard to enter Domain:

• Click Get Started.
• Select Active-Active Site.
• Enter FQDN as globalweb.training.lab
• Click OK.
Click Continue.
167
GSLB site IP address:
• In the GSLB sites section, Click Add Sites under No Site Present in the system.
• Select Type as LOCAL.
• Select Site IP Address as 172.22.15.211.
• Click Create.
7. Create the GSLB site for the Frankfurt Citrix ADC. Use the management SNIP (192.168.10.103) as
the site IP address:
• Click Add Sites.

• Click Create.
Click Continue.
GSLB service using the virtual IP address.

• Confirm the site name is site_tok. If not select site_tok from drop-down.
• In the Virtual Servers field select lb_vsrv_tok from the drop-down.
• Click Create.
the GSLB service using the virtual IP address.
• Click Add Services.

• Select site_ffm under Site Name.
• Click Create.
Click Continue.
168
10. Configure the GSLB virtual server basic settings:

Configure Service and Domain Binding:

• In the Select Service field click “>” icon to add service if not auto populated.
• Select gslb_svc_ffm and gslb_svc_tok and Click Select.
• In the Domain Binding field click “>” icon to add Domain if not auto populated.
• Select globalweb.training.lab and Click Select.
Configure GSLB method:

• Select Algorithm based.
• Confirm the method is ROUNDROBIN.
Click Create.
Click Continue.
Click Done.
Exercise 6-1: Configuring Active/Active GSLB (CLI)
Introduction:
In this exercise, you will learn to configure Global Server Load Balancing on Citrix ADC
appliances in two sites. You will use the Configuration Utility to perform this exercise.
This initial configuration will verify that GSLB can distribute traffic between the two sites and
will configure an active/active configuration that alternates between Frankfurt and Tokyo using
GSLB round robin.
This exercise will demonstrate the following concepts of GSLB:
• GSLB site, GSLB service, and GSLB virtual server configuration.

• GSLB site to site communication using MEP.
• Requirements and procedures for GSLB Synchronization.
• Configure the Frankfurt and Tokyo GSLB Sites.

• Create the GSLB Services for the Frankfurt and Tokyo load balancing virtual servers.
• Configure the GSLB load balancing virtual server for an active/active distribution.
• Complete GSLB synchronization between the Frankfurt and Tokyo Citrix ADC appliances.
169
• Prepare for GSLB on the Citrix ADC HA Pair for Frankfurt.

• Create the GSLB Site on the Citrix ADC HA Pair for Frankfurt.
• Create the GSLB Site on the Citrix ADC for Tokyo.
• Configure GSLB Services and Virtual Server on the Citrix ADC HA Pair for Frankfurt.
• Synchronize the GSLB Configuration between Frankfurt and Tokyo sites.
NOTE: In this exercise, you will be required to switch between Citrix ADC appliances to make
configurations. You will be told which Citrix ADC to connect to at which point.

Step Action
User Name: nsroot

Password: nsroot
2. NSHA MGMT (192.168.10.103) - Create a load balancing virtual server for the Frankfurt location:
add lb vserver lb_vsrv_ffm HTTP 172.21.10.122 80
Bind service svc_green as the application backend.
bind lb vserver lb_vsrv_ffm svc_green
3. Enable GSLB Feature:
enable ns feature gslb lb
Create the GSLB Site on the Citrix ADC HA Pair for Frankfurt
Step Action
1. NSHA MGMT (192.168.10.103) - Create the GSLB Site for the Frankfurt HA Pair. Use the
management SNIP (192.168.10.103) as the site IP address:
add gslb site site_ffm 192.168.10.103
site IP address:
add gslb site site_tok 172.22.15.211
170
3. Verify the GSLB site IP address:
show ns ip
Confirm the management SNIP 192.168.10.103 is being used for both SNIP and GSLB functions.
4. Verify the GSLB Site status:
show gslb site
• site_ffm should be identified as the LOCAL site for this Citrix ADC.
• site_ffm metric exchange is enabled.
• site_tok should be identified as the REMOTE site for this Citrix ADC.
• site_tok metric exchange is enabled, but MEP status is DOWN. This is expected
behavior until the Tokyo Citrix ADC is configured.
5. NSHA MGMT (192.168.10.103) - Save the Citrix ADC configuration:
save ns config
Create the GSLB Site on the Citrix ADC for Tokyo

Step Action
1. Connect to ADC_VPX_03 for Tokyo using its NSIP at 172.22.15.201 over SSH (PuTTY). Log on
using the following credentials:
User Name: nsroot

Password: nsroot
NOTE: In case the VM is down, go to XenCentre and start the VM ADC_VPX_03.
2. ADC_VPX_03 (172.22.15.201) - Enable the GSLB Feature:
enable ns feature gslb lb
3. Verify that the load balancing virtual server for Tokyo is configured:
show lb vserver lb_vsrv_tok
• VIP assigned is 172.22.15.231

• Virtual server is in an UP state.
• Service svc_tok, which points to the WebRemote server at 172.22.15.41, is bound and
UP.
171
the site IP address:
add gslb site site_ffm 192.168.10.103
site IP address:
add gslb site site_tok 172.22.15.211
6. Verify the GSLB site IP address:
show ns ip
Confirm that the management SNIP 172.22.15.211 is being used for both SNIP and GSLB
functions.
7. Verify the GSLB site status:
show gslb site
• site_ffm should be identified as the REMOTE site for this Citrix ADC.
• site_ffm metric exchange is enabled and MEP Status is now ACTIVE.
• site_tok should be identified as the LOCAL site for this Citrix ADC.
• site_tok metric exchange is enabled.
8. ADC_VPX_03 (172.21.15.201) - Save the Citrix ADC configuration:
save ns config
9. Switch to NSHA Mgmt (192.168.10.103).
10. NSHA MGMT (192.168.10.103) - Verify that GSLB sites are also UP with MEP active on the
Frankfurt Citrix ADC HA Pair as well:
show gslb site
• site_ffm should be identified as the LOCAL site for this Citrix ADC.
• site_tok should be identified as the REMOTE site for this Citrix ADC. MEP Status is now
ACTIVE.
11. NSHA MGMT (192.168.10.103) -
Save the Citrix ADC configuration:
save ns config
172
Configure GSLB Services and Virtual Server on the Citrix ADC HA Pair for
Frankfurt
Step Action
1. Remain on ADC_HA_ MGMT (192.168.10.103). Do not configure ADC_VPX_03 (172.22.15.201)
until instructed to do so.
the GSLB service using the virtual IP address:
add gslb service gslb_svc_ffm 172.21.10.122 HTTP 80 -siteName site_ffm
GSLB service using the virtual IP address:
add gslb service gslb_svc_tok 172.22.15.231 HTTP 80 -siteName site_tok
4. Verify that both GSLB services are UP:
show gslb service
Both services should be in an UP state. If gslb_svc_tok is DOWN initially, wait 5 seconds then
repeat the command. If the service is still DOWN you may have a configuration issue.
Otherwise, the service should report as UP.
5. Create the GSLB virtual server:
add gslb vserver gslb_vsrv_global HTTP -lbMethod ROUNDROBIN
6. Bind the GSLB services to the GSLB virtual server:
bind gslb vserver gslb_vsrv_global -serviceName gslb_svc_ffm
bind gslb vserver gslb_vsrv_global -serviceName gslb_svc_tok
7. Bind the FQDN to the virtual server that GSLB will be used to resolve:
bind gslb vserver gslb_vsrv_global -domainName globalweb.training.lab
8. Verify the GSLB virtual server is UP:
show gslb vserver

show gslb vserver gslb_vsrv_global
• GSLB virtual server is UP.

• Both GSLB services are bound and are UP: gslb_svc_ffm and gslb_svc_tok.
• Verify the domain name is bound: globalweb.training.lab
173
9. Test that GSLB is resolving the FQDN to the correct service from the Citrix ADC:
Wait a second and repeat the test:
NOTE: Each time the ping test is repeated, a different IP address is returned. The response
should alternate between 172.21.10.122 (Frankfurt) and 172.22.15.231 (Tokyo).
10. NSHA MGMT (192.168.10.103) -
save ns config
174
Synchronize the GSLB Configuration between Frankfurt and Tokyo Sites

Step Action
1. Be sure you have two SSH session opened to both Citrix ADC management IP addresses. For best
results, arrange the windows so you can view the sessions side-by-side:
• Connect to ADC_HA_ MGMT at 192.168.10.103 over SSH (using PuTTY).

• Connect to ADC_VPX_03 at 172.22.15.201 over SSH (using PuTTY).
2. ADC_VPX_03 (172.22.15.201)
Verify that the GSLB Sites are configured, but no GSLB Services or Virtual Servers are present:
show gslb site

show gslb services
show gslb vserver
3. Switch to NSHA MGMT (192.168.10.103).
IMPORTANT: Be sure that you are connected to 192.168.10.103 for this next step or you will
lose configuration settings.
4. NSHA MGMT (192.168.10.103) - Synchronize the GSLB configuration from NSHA MGMT to
NS_VPXP_03.
NOTE: The GSLB Site, GSLB Services, and GSLB Virtual Server were created in the previous steps.
The GSLB configuration can be pushed from this Citrix ADC to the GSLB partner site using GSLB
synchronization. GSLB synchronization is not automatic and must be manually triggered. Also
note that GSLB sites do not have a hierarchy, and the synchronization is always pushed from the
Citrix ADC. The command is issued on to the designated sites, overwriting their configuration. It
is possible to run this command on the wrong Citrix ADC and lose settings.
Also, for GSLB synchronization to work, the GSLB sites must be configured on all partner Citrix
ADC applianceswith the same site name as the system with the authoritative configuration, or
the synchronization will fail.
Sync the configuration from the Frankfurt HA Pair to the Tokyo Citrix ADCs, using the GSLB sync
command:
sync gslb config -forceSync site_tok
Enter Y to confirm synchronization.
NOTE: More than likely, GSLB synchronization was successful for the intended settings for GSLB
Services and GSLB Virtual Servers. However, the GSLB configuration also synchronizes content-
switching virtual servers and related entities. A failure is reported: some of the load balancing
virtual servers used with an existing content-switching virtual server configuration in the lab did
not replicate to the partner Citrix ADC.
We will manually confirm that the replication completed successfully.
175
save ns config
6. Switch to ADC_VPX_03 (172.22.15.201).
7. Verify that the GSLB configuration synchronized successfully:
show gslb vserver

• The virtual server gslb_vsrv_global is UP.

• Both services, gslb_svc_ffm and gslb_svc_tok, are bound.
• Both services are in an UP state.
NOTE: To view the actual GSLB configuration commands:
show gslb runningconfig

8. ADC_VPX_03 (172.22.15.201) -
save ns config
Key Takeaways:
• GSLB sites are configured to represent the Citrix ADC appliances participating in the
GSLB configuration. Citrix ADC appliances in a GSLB configuration communicate to the
GSLB Site IP address of partner Citrix ADCs.
• GSLB Services represent the potential IP addresses that the FQDN can be resolved to by
GSLB. The GSLB Services generally corresponds to the IP address of the intended target
virtual servers that the traffic will be sent to. In this case, the GSLB service IP addresses
correspond to the target load balancing virtual servers’ VIPs (lb_vsrv_ffm and
lb_vsrv_tok).
• GSLB Services have an UP and DOWN status like regular services. GSLB virtual servers
will only select a GSLB service in an UP state. GSLB Service status is controlled by the
MEP communication between sites. If monitors are bound to GSLB services, then
monitors control the UP and DOWN state of the service, overriding MEP.
• GSLB virtual servers determine the GSLB load balancing distribution method and can be
configured for active/active load balancing, client proximity load balancing, or
active/passive load balancing.
• Citrix ADC appliances in a GSLB configuration are independently configured from each
other. To ensure that the GSLB configuration is properly configured on all participatory
sites, the GSLB synchronization command can be used to synchronize the GSLB parts of
the configuration with other sites. The synchronization process uses the system the
176
command is issued from as the source (authoritative) configuration and then

synchronization will override the target site or sites.
• In order for GSLB synchronization to work, the GSLB feature must be enabled on all
participant nodes, and GSLB sites must already be created on each node for themselves
and the partner locations (each site must know about all other sites). The site names
must be configured the same across Citrix ADC appliances for synchronization to work.
Exercise 6-2: Testing GSLB with DNS Proxy Configuration (CLI)
Introduction:
In this exercise, you will learn to integrate the GSLB configuration with the DNS resolution
process. You will use the command-line interface to perform this exercise.
For this exercise, the existing DNS load balancing virtual server will be used as a DNS Proxy
configuration. The DNS load balancing virtual server VIP will be set as the workstation DNS
server IP address. As a result, all DNS lookups requested by the client will be directed to the
load balancing virtual server.
Once domain names are bound to the GSLB virtual server, the Citrix ADC will recognize these
FQDNs as GSLB-based resolutions. Requests for non-GSLB entities will be handled by the DNS
load balancing virtual server. Requests for name resolution of FQDNs associated with GSLB
virtual servers will be intercepted by the Citrix ADC and handled as a GSLB resolution and not
sent to the DNS services for the domain.
• Testing GSLB with DNS Proxy Configuration.
Testing GSLB with DNS Proxy Configuration

Step Action
1. Attempt to resolve globalweb.training.lab from the Student Desktop:
Open a cmd prompt: Right-click Start and select Command Prompt.
ping -n 2 globalweb.training.lab
This will currently fail, as the request is currently trying to be resolved by the client's local DNS
name resolver.
177
2. Configure the Student Desktop with the DNS Proxy load balancing virtual server on the Citrix
ADC (lb_vsrv_dns).
Open the Windows Network and Sharing Center Control Panel. Right-click on the Network icon
in the system tray or use the detailed steps below.
• Open Control Panel: Start > All Apps > Windows System > Control Panel.
• Click Network and Sharing Center.
Update the DNS Settings on the lab interface:
• Click Change Adapter Settings.

• Right-click Ethernet Network X and click Properties.
• Select internet Protocol Version 4 (TCP/IPv4) and click Properties. (Be sure you leave
the check box clear).
• Change the Preferred DNS Server from 192.168.30.11 to 172.21.10.102. (This is the VIP
assigned to the lb_vsrv_dns.)
• Click OK.
• Click Close to close the Local Area Connection 2 Properties.
3. Test that DNS resolution for internal training.lab FQDNs is working.
Webred.training.lab should resolve to 192.168.30.51.
Repeat the command multiple times and verify that the results alternate between IP addresses
172.21.10.122 and 172.22.15.231. Verify that the GSLB is working.
5. Switch to the SSH session for NSHA MGMT (192.168.10.103).
Enable MIR (Multiple IP Address Response) on the GSLB virtual server:
set gslb vserver gslb_vsrv_global -MIR Enabled
6. NSHA MGMT (192.168.10.103) - Save the Citrix ADC Configuration:
save ns config
178
NOTE: This time nslookup returns with both possible IP addresses for the name resolution,
though the preferred order still alternates.
The MIR (Multiple IP Address Response) requires the GSLB configuration to return all available IP
addresses during a name resolution. Every GSLB service in an UP state will be returned. The
current preferred load balancing service will be listed first, but other available IP addresses are
returned as well. When MIR is disabled, only a single IP address is returned for each lookup,
which is the current preferred GSLB decision for that transaction.
The MIR option is used to help mitigate some of the effects of an intermediate device caching a
DNS query. If a previous query was cached, then one or more potential alternate IP addresses
are included, in case the primary IP address is DOWN by the time the cached result goes into
use.
8. Test GSLB in the Web Browser:
• Open Firefox and connect to http://globalweb.training.lab/remote.php

• Open Chrome and connect to http://globalweb.training.lab/remote.php
Between the two browsers, remote.php should display GREEN and German content when served
from the Frankfurt Citrix ADC HA Pair, and it should display RED and Japanese content when
served from the Tokyo Citrix ADC.
The browsers will tend to cache the DNS resolution and not update the IP address for each
refresh. Alternatively, you can flush the DNS cache on the Student Desktop between tests. From
the cmd prompt run:
ipconfig /flushdns
Key Takeaways:
• DNS requests for GSLB-based names have to get to the Citrix ADC to be resolved, using a
GSLB-based process.
• Citrix ADC GSLB can integrate with DNS through sub-delegation, ADNS configurations, or
the DNS Proxy configuration illustrated in the exercise.
• Normal GSLB behavior defaults are; Multiple IP Response (MIR) is Disabled and Empty
Down Response (EDR) is Disabled. When multiple GSLB services are UP, only a single IP
address is returned during the GSLB resolution. The IP address returned is the preferred
IP address given the current load balancing method. If all services are DOWN, then GSLB
will return all IP addresses associated with all services as a potential connection point,
179
though they are all currently DOWN. The MIR and EDR settings can be adjusted to
override this behavior in order to mitigate some of the impacts of an intermediate
device caching a previous DNS query.
• If Empty Down Response (EDR) is enabled, then the behavior when all services are
DOWN changes so that no IP address is returned. When no services are available, GSLB
returns no results to avoid a situation in which an intermediate device would cache a
DOWN response and force a new DNS lookup to be performed later to find an available
service.
• If Multiple IP Response (MIR) is enabled, then when multiple services are UP, instead of
returning a single IP address in the DNS resolution response, the Citrix ADC will return all
available services in an UP state in a preferred order. If an intermediate device were to
cache this DNS resolution, then it at least has the preferred service available at the time
the request was cached and a list of other potential IP addresses if the preferred service
is DOWN at a later time.
Exercise 6-3: Configuring GSLB for Active/Passive Scenario

(CLI)
Introduction:
In this exercise, you will learn to configure GSLB in an Active/Passive configuration for use as a
data center failover solution. You will use the command-line interface to perform this exercise.
The configuration will use the existing GSLB configuration and add an additional GSLB virtual
server to it. The Citrix ADC HA pair (ADC_VPX_01 and ADC_VPX_02) will host the primary data
center using the Frankfurt resource (lb_vsrv_ffm). ADC_VPX_03 will act as the backup data
center using the Tokyo resource (lb_vsrv_tok). Only when the Frankfurt web server or the Citrix
ADC HA pair is offline should traffic fail over to the Tokyo web server.
• Configure GSLB for Active/Passive Failover.

• Test the Active/Passive Configuration.
Configure GSLB for Active/Passive Failover

Step Action
1. ADC_HA_ MGMT (192.168.10.103) - Create a new GSLB virtual server as a backup virtual server:
add gslb vserver gslb_vsrv_backup HTTP
180
2. Bind the Tokyo service to the backup GSLB virtual server:
bind gslb vserver gslb_vsrv_backup -serviceName gslb_svc_tok
3. Configure the GSLB virtual server gslb_vsrv_global with a backup virtual server using
gslb_vsrv_backup:
set gslb vserver gslb_vsrv_global -backupvServer gslb_vsrv_backup
4. Update the Frankfurt service, so that it only points to the Frankfurt GSLB service by unbinding
the Tokyo service:
unbind gslb vserver gslb_vsrv_global -serviceName gslb_svc_tok
5. Verify the GSLB virtual server configuration:
show gslb vserver

show gslb vserver gslb_vsrv_backup
• Both gslb virtual servers are UP.

• Each gslb virtual server has only one gslb service bound.
save ns config
7. NSHA MGMT (192.168.10.103) -
Synchronize the GSLB configuration with the Tokyo Site:
sync gslb config -forceSync site_tok

• Enter Y to confirm.
NOTE: This will synchronize the new Active/Passive GSLB configuration with the Tokyo site.
8. Switch to ADC_VPX_03 (172.22.15.201) -
Save the Citrix ADC Configuration:
save ns config
Test the Active/Passive Configuration

Step Action
181
NOTE: This time nslookup only returns a single IP address for the Frankfurt virtual server:
172.21.10.122.
2. Switch NSHA MGMT (192.168.10.103):
Disable the Frankfurt load balancing virtual server to simulate an outage:
disable lb vserver lb_vsrv_ffm
This will cause the gslb service gslb-svc_ffm to go DOWN, which will result in the GSLB virtual
server gslb_vsrv_global going DOWN. The backup virtual server will be used and traffic will now
fail over to lb_vsrv_tok on the Tokyo Citrix ADC.
NOTE: This time nslookup only returns a single IP address for the Tokyo virtual server:
172.22.15.231.
Key Takeaways:
• Multiple GSLB virtual servers can be associated with a single GSLB site configuration.
• GSLB services can represent entities on remote Citrix ADCs, and they can report an UP
or DOWN status via MEP.
• GSLB virtual servers can be configured with backup virtual servers, which will only be
used when services on the primary virtual server fail.
182
GSLB Troubleshooting Tips

If the procedure for testing the GSLB configuration does not produce the expected results, use
the following tips to troubleshoot the lab configuration.
Unable to resolve globalweb.training.lab

Step Action
1. Ensure that you are pointing to the correct DNS server. For this exercise, the Student Desktop
should be configured to point to the DNS load balancing virtual server IP Address.
2. Ensure that you set the DNS setting on the correct network connection if multiple networks are
present. Consult with your instructor if required.
3. Ensure that your web browser does not have a proxy server configured.
4. Ensure that you are not connecting from a workstation behind a firewall that is blocking UDP
port 53 (DNS).
Load Balancing Between Citrix ADC Systems Not Occurring

Step Action
1. If the issue exists during the browser test, clear the cache between test runs. For best results,
close and re-open the browser between each test.
2. If the issue occurs during the ping response from the workstation and only one (1) IP address is
being returned, verify that the GSLB sites, services, and virtual servers appear as UP and that
MEP status shows as UP/Active.
3. Multiple browser instances can also affect the results. Close all open browsers and start a new
session. Close and open browsers between tests.
4. Conduct tests from only one hosted workstation at a time.
5. Ensure that the GSLB and load balancing (LB) features are ENABLED on both Citrix ADC systems.
6. Verify on the Citrix ADC system that the resolution is alternating between GSLB services.
Example: From the command-line interface on a given Citrix ADC system, ping
globalweb.training.lab; stop and re-ping. Verify that you receive the two expected IP addresses.
Other Issues
Step Action
1. Verify that the correct IP addresses are used for the load balancing virtual server, GSLB services
and GSLB virtual server. Confirm that sites, virtual servers, services, and domains are bound
appropriately.
2. Verify that MEP is functioning, and that both sites and services show as UP on both Citrix ADC
systems. Using the Configuration Utility instead of the command-line interface may make quickly
verifying the configured settings easier.
Using dig
183
APPENDIX A: Citrix ADC Counters
Troubleshooting Citrix ADC issues become easier with Citrix ADC counters:
• Authentication policies and session policies applied on the Citrix ADC Gateway virtual
server:
nsconmsg –d current –g pol_hits
When you specify pol_hits it is limiting the output to session policy. Instead, you can use
just _hit and get ALL policy hits (including route, ACL, VLAN, session, CS, rewrite, etc):
nsconmsg –d current –g _hits

• Rewrite policy bound at a global level or to a load balancing, content switching, or Citrix
ADC Gateway virtual server:
nsconmsg –d current | egrep –i rewrite
• Responder policy bound at a global level or to a load balancing, content switching, or
Citrix ADC Gateway virtual server:
nsconmsg –d current | egrep –i responder
2] Using newnslog commands:
Use the following syntax to read a historical file:

/netscaler/nsconmsg -K /var/nslog/newnslog -d event
To view the time span covered by a given newnslog file, use the syntax as in the following
example:
/netscaler/nsconmsg -K /var/nslog/newnslog -d setime
184
APPENDIX B: Citrix Gateway Configuration
Citrix Gateway (previously SWG)

Introduction:
Secure Web Gateway is traffic management feature, which combines the functionality of the
content witching virtual server and forward proxy mode.
A Citrix ADC appliance at the edge of the network acts a proxy. The appliance can operate in
transparent proxy mode or explicit proxy mode and offers controls to intercept internet traffic,
including HTTPS. A decision to intercept, bypass, drop, or block any requests is made on the
basis of the policies configured on the appliance
Citrix ADC Secure Web Gateway enables us to do the following:
• Gain visibility into the otherwise bypassed secure traffic.

• Block access to malicious sites and avoid infecting users within the enterprise.
• Control access to some websites, such as personal mail, social networking, and job search
websites, from the enterprise network.
It can be implemented in the transparent mode or the explicit mode.
The Citrix ADC Secure Web Gateway requires a separate platform license. This feature is NOT
included in the Citrix ADC ADC platform license.

For this module, connect to your assigned XenCenter console and verify that the following
virtual machines are running. If any of the virtual machines are not running, use XenCenter to
turn them on. Otherwise, XenCenter will not be needed for the rest of the module.
• ADC_CG • WebGreen
• WebBlue • Ad.training.lab
• WebRed • AD02.training.lab
185
Exercise 1: Configuring Secure Web Gateway (Explicit Mode)

(GUI)
Introduction:
In this exercise, you will learn to implement Citrix ADC Secure Web Gateway in the explicit
proxy mode to perform the URL filtering using URL set.
Scenario
The Citrix Administrator of ABC corp. the users are user data is increasingly becoming
vulnerable to identity thefts and having their data compromised. To counter the threats,
company now needs to deploy Citrix ADC Secure Web Gateways to safeguard their network.
• Intercept all outbound and incoming traffic (HTTP and HTTPS) by configuring an
explicit proxy.
• Import the URL set to identify the blacklisted urls.
Step Action
1. Perform Test:
• In the Internet explorer open a new window and browse for https://youtube.com/
• Observe that the URL is being permitted.
2. Open Google Chrome and Click on the bookmark for NS_SWGto connect to the MGMT NSIP at
http://192.168.10.104.
User Name: nsroot

Password: nsroot
3. Install the Citrix Gateway license on the Citrix ADC:
• Browse to System > Licenses.

• Click Manage Licenses.
• Click Add New License.
• Select Upload license files.
• Click Browse.
• Browse to C:\Users\localuser\Desktop\Resources\Citrix ADC License.
• Select file CNS_WEBF_SSERVER_Retail.lic and Click Open.
• Click Add New License.
• Select Upload license files.
• Click Browse.
• Browse to C:\Users\localuser\Desktop\Resources\Citrix ADC License.
• Select file CNS_V1000_SERVER_SWG_Retail.lic and Click Open.
• Click Reboot and confirm by clicking Yes.
186
NOTE: Sometimes after installing the licenses, the GUI will be delayed in displaying the options on
the system. If necessary, reboot one more time to allow them to refresh.
Add a Default route:
• Browse to System > Network > Routes.

• Click Add.
• In the Network field, enter 0.0.0.0.
• In the Netmask field, enter 0.0.0.0.
• In the Gateway field, enter 192.168.10.1.
• Click Create.
4. Install Root CA Certificate:
• Browse to Secure Web Gateway > SSL > Certificates > Server Certificates.
• Click Install.
• Enter the Certificate-Key Pair Name as SWG_CA_Cert.
• In the Certificate File Name field, Click Choose File.
• The File Browser will display the content of the Directory /nsconfig/ssl/.
• Select swg_ca_cert, Click Open.
• In the Key File Name field, Click Choose File.
• The File Browser will display the content of the Directory /nsconfig/ssl/.
• Select swg_ca_cert_key.key, Click Open.
• Click Install.
• Browse to Secure Web Gateway > SSL > Certificates > CA Certificates.
• Verify that the Root the Certificate SWG_CA_Cert is present under the CA Certificates list.
5. Configure URL sets:
• Browse to AppExpert > URL Sets.

• Click Import.
• In the Name filed Enter Blacklist_URL_Set.
• Enter URL as http://192.168.30.11/top15k.txt
• Let the settings be default.
• Click OK.
• Click Add.
• In the Name field, enter Blacklist_URL_Set.
• Click Create.
• Observe that the Pattern count has non-zero value.
6. Create Responder Action:

• Click Add.
• In the Name field, enter SWG_Block_Act.
• In the Type field, select Respond with.
"HTTP/1.1 451 Unavailable For Legal Reasons\r\n\r\nURL is NOT authorized\n"
• Click Create.
NOTE: Quotes are required in the expression.

187

• Click Add.
• In the Name field, enter SWG_Block_Pol
• In the Action field, select SWG_Block_Act
HTTP.REQ.HOSTNAME.APPEND(HTTP.REQ.URL).URLSET_MATCHES_ANY("blacklist_url_se
t")||HTTP.REQ.URL.URLSET_MATCHES_ANY("blacklist_url_set")
• Click Create.
NOTE: If you get a feature not licensed error, a reboot of the Secure Web Gateway may be required
to continue.
8. Configure Explicit Forward Proxy Vserver:
• Browse to Secure Web Gateway > Proxy Virtual Servers.

• Click Add.
• In the Basic Settings section:
• In the Name field, enter SWG_VS.
• In the IP Address Type field, select IP Address.
• In the IP Address field, enter 192.168.10.106.
• In the Port field, enter 80.
• Click OK.
• Click OK again under Content Switching Policy Binding if needed.
• In the Advanced Settings section, Click Policies.

• The Policies Section will be created in the bottom of the page.
• To add, click the + icon.
• In the Choose Policy field, select Responder.
• In the Choose Type field, select Request.
• Click Continue.
• In the Select Policy field, Click Click to select.
• Select the policy SWG_Block_Pol, Click Select.
• Let the priority and other settings be default.
• Click Bind > Done.
10. Configure SSL Interception:
• Browse to Secure Web Gateway > 1 Proxy Virtual Servers > SWG_VS.
• In the Advanced Settings section, click Certificate.
• In the Certificate section, click No CA Certificate.
• In the Select CA Certificate field, Click Click to select.
• Select SWG_CA_Cert, click Select.
• Click Bind.
• Click Continue.
• In the Advanced Settings section, click SSL Profile.
• In the SSL Profile section, click the Edit icon, then click + icon, to add the SSL Profile.
• In the Name field, enter SSL_Profile_Interception.
• In the SSL Interception section, check SSL Sessions Interception.
• Confirm that the Verify Server Certificate For Reuse On SSL Interception is enabled
• In the Maximum SSL Sessions Per Server, enter 100.
• Click OK.
• Click Done.
188
• Click OK under SSL Profile.

• Click Done.
11. Change Syslog parameter:
• Browse to System > Auditing.

• In the Settings section, click Change Auditing Syslog Settings.
• Enable User Configurable Log Messages.
• Enable SSL Interception.
Click OK.
12. Save Configuration:
• Click Save icon.

13. Configure Client Settings:
• On the Student Desktop, Open Internet Explorer.

• Click Tools (Gear like Icon).
• Click Internet Options.
• Go to Connections window.
• Click LAN settings.
• In the Proxy Server Section,
• Check the box for Use a proxy server for your LAN.
• Enter Address as 192.168.10.106
• Enter Port as 80.
• Click Advanced.
• In the Exceptions section, under Do not use proxy server for addresses beginning
with, enter 192.168.10.103
• Click OK.
• Click OK
• Click OK.
14. Perform Test:
• Observe that the URL is being blocked and the page is not displayed.
15. Remove the Proxy Configuration:

• Click LAN settings:
• In the Proxy Server Section, Uncheck the box for Use a proxy server for your LAN.
• Click OK.
• Click OK.
Key Takeaways:
189
• The features Responder, AAA-TM, content switching, SSL, forward proxy, SSL
interception, and URL filtering are used while configuring the Secure Web Gateway.
• The Citrix ADC SWG appliance emulates the origin server certificate. This server
certificate must be signed by a trusted CA certificate, which must be installed on the
clients’ devices so that the client can trust the regenerated server certificate.
Exercise 1: Configuring Secure Web Gateway (CLI)
Overview
In this exercise, you will learn to implement Citrix ADC Secure Web Gateway in the explicit
proxy mode to perform the URL filtering using URL set.
Scenario
The Citrix Administrator of ABC corp. the users are user data is increasingly becoming
vulnerable to identity thefts and having their data compromised. To counter the threats,
company now needs to deploy Citrix ADC Secure Web Gateways to safeguard their network.
• Intercept all outbound and incoming traffic (HTTP and HTTPS) by configuring an
explicit proxy.
• Import the URL set to identify the blacklisted urls.
Step Action
1. Perform Test:
• Observe that the URL is being permitted.
• In the Saved session section, click ADC_SWG.
• Click Open.
Login as: nsroot
Password : nsroot
190
Note: Start the SWG in XenCenter if needed.
3. Upload a license file to the Citrix ADC:

• Open WinSCP using the shortcut on the Desktop. Connect to NS_SWG (192.168.10.104).
• Click Yes on the Security Warning if needed and login with nsroot/nsroot.
• In the left pane, browse to C:\Users\localuser\Desktop\Resources\Citrix ADC r License.
• In the right-pane, browse to /nsconfig/license/.
Copy the license file CNS_V1000_SERVER_SWG_Retail.lic and CNS_WEBF_SSERVER_Retail.lic from
C:\Users\localuser\Desktop\Resources\NetScaler License to /nsconfig/license/ on the Citrix ADC.
4. Perform a warm restart to apply license file changes:

reboot –warm
Enter “Y” to confirm reboot.

5. Log on Citrix ADC Command Line Interface
• In the Saved session section, click ADC_SWG.
• Click Open.
Login as: nsroot
Password : nsroot
6. Add a default route to the Citrix ADC Secure Web Gateway.
add route 0.0.0.0 0.0.0.0 192.168.10.1

7. Add the DNS server.
add dns nameserver 192.168.30.11

8. Verify the DNS Name Server is configured and the state is UP.
show dns nameServer

9. Install Root CA Certificate
add ssl certKey SWG_CA_Cert -cert swg_ca_cert -key swg_ca_cert_key.key

10. Configure URL sets
• Import the URL SET to Citrix ADC

import policy urlset blacklist_url_set -url http://192.168.30.11/top15k.txt -interval 5
• Add URL Set Policy
add policy urlset blacklist_url_set
• Verify the that url set policy show updated pattern count
show urlset
11. Enable Features
enable ns feature RESPONDER CS SSL

add responder action SWG_Block_Action respondwith q{"HTTP/1.1 451Unavailable for legal

Reasons \r\n\r\nURL is NOT authorized\n"}
191
add responder policy SWG_Block_Pol

"HTTP.REQ.HOSTNAME.APPEND(HTTP.REQ.URL).URLSET_MATCHES_ANY(\"blacklist_url_set\")
||http.REQ.URL.URLSET_MATCHES_ANY(\"blacklist_url_set\")" SWG_Block_Action
NOTE: If you get a feature not licensed error, a reboot of the Citrix ADC may be required to continue.
14. Configure Explicit Forward Proxy Vserver
add cs vserver SWG_VS PROXY 192.168.10.106 80
bind cs vserver SWG_VS -policyName SWG_Block_Pol -priority 100 -gotoPriorityExpression END

-type REQUEST
16. Change Syslog parameter
set syslogparams -sslInterception ENABLED
17. Configure SSL Interception:
• Bind CA Certificate to SWG Vserver

bind ssl vserver SWG_VS -certkeyName SWG_CA_Cert -CA -ocspCheck Optional
• Configure SSL Profile
add ssl profile SSL_Profile_Interception -sessReuse ENABLED -sessTimeout 120 -
sslInterception ENABLED -ssliMaxSessPerServer 100
• Bind SSL Profile to the Vserver
set ssl vserver SWG_VS -sslProfile SSL_Profile_Interception
18. Save Configuration:

Save ns config

• Click LAN settings.
• Check the box for Use a proxy server for your LAN.
• Enter Address as 192.168.10.106.
• Enter Port as 80
• Click OK
• Click OK
20. Perform Test
• Observe that the URL is being blocked and the page is not displayed.
192

• Click Tools (Gear like Icon)
• Click Internet Options
• Go to Connections window
• Click LAN settings
• Uncheck the box for Use a proxy server for your LAN
Key Takeaways:
• The features Responder, AAA-TM, content switching, SSL, forward proxy, SSL
interception, and URL filtering are used while configuring the Secure Web Gateway.
• The Citrix ADC SWG appliance emulates the origin server certificate. This server
certificate must be signed by a trusted CA certificate, which must be installed on the
clients’ devices so that the client can trust the regenerated server certificate.
193

CNS 2

Uploaded by

Copyright:

Available Formats

CNS 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CNS 2

Uploaded by

Copyright:

Available Formats

CNS-219-3i Citrix ADC 12.

Lab Manual v1.4

Lab Manual Overview

Before You Begin:

• For SFTP access: WinSCP

Lab Environment Overview

Virtual Machine Name Domain FQDN IP Address Description

AD.training.lab ad.training.lab 192.168.30.11 Domain Controller (training.lab)

CITRIX ADC LIST

Virtual NSIP Address Subnet IP (SNIP) Address Description

ADC_VPX_01 192.168.10.101 SNIP1: 192.168.10.111 (traffic) ADC_VPX_01 is the principal Citrix

CREDENTIALS LIST: Training Domain Users and Groups

User Name Groups Password Description

administrator Domain Admins Password1 Domain administrator account which can

CREDENTIALS LIST: Citrix ADC Local Accounts

User Name Delegated Admin Password Description

nsroot superuser nsroot Built-in Citrix ADC account that will be

Module 1: Classic Policies

ADD - Adds the specified HTTP header.

After completing this lab module, you will be able to:

• Enable the Content Filtering feature.

• Exercise: Configuring Content Filtering with Classic Policies.

Before you Begin:

Virtual Machines required for this module

Exercise 1-1: Configuring Content Filtering with Classic Policies

• Requests for /red.php to the lb_vsrv_rbg (http://172.21.10.101) should be dropped.

• Configure Content Filtering with Classic Policies.

Configuring Content Filtering with Classic Policies

Log on using the following credentials:

User Name: nsroot

• Open a web browser and find http://172.21.10.101/red.php

• Browse to System > Settings.

Create Classic Policy Expressions:

• Browse to AppExpert > Expressions > Classic Expressions.

5. Create the Expression using the Expression Editor (Classic syntax):

Basic structure for classic expressions are:

• Browse to Security > Protection Features > Filter.

Configure the policy with the following settings:

• Enter cf_red_url in the Filter Name field.

7. Bind the policy cf_red_url to the virtual server lb_vsrv_rbg.

• Browse to Traffic Management > Load Balancing > Virtual Servers.

Choose Policy Type and Flow:

• Select Filter from the Choose Policy drop-down list box.

Bind the policy to the virtual server:

• Click Click to Select Policy under select policy.

Open a Web browser and test the following URLs on lb_vsrv_rbg:

NOTE: Requests to /red.php are dropped from lb_vsrv_rbg.

• Browse to Security > Protection Features > Filter.

• Browse to Traffic Management > Load Balancing > Virtual Servers.

11. Save the Citrix ADC configuration and confirm.

• Click the Save icon (floppy disk) in the upper-right corner.

Exercise 1-1: Configuring Content Filtering with Classic

Requirements for the scenario in this exercise:

• Requests for /red.php to the lb_vsrv_rbg (http://172.21.10.101) should be dropped.

• Configure Content Filtering with Classic Policies

Configuring Content Filtering with Classic Policies

• Use the PuTTY shortcut on the desktop of your Student Desktop OR

Log on to PuTTY using the following credentials:

User Name: nsroot