CNS-219-2i Citrix NetScaler Traffic Management Lab Guide

Education
CNS-219-2i Citrix NetScaler Traffic Management
Lab Guide Version 1.6

Credits Page
Title Name
Architects Jesse Wilson
Product Managers Lissette Jimenez
Technical Solutions Developer Aman Sharma
Anton Mayers
Shruti V. Dhamale
Ravindra G. Hunashimarad
Layna Hurst
Rhonda Rowland
Offering Manager Jessica Hayner
Instructional Designer Elizabeth Diaz
Graphics Designer Ryan Flowers
Publication Services Nicole Tacher
Special Thanks Layer8 Training
Contents
Credits Page ...................................................................................................................................................................2
Lab Guide Overview .......................................................................................................................................................5
Lab Environment Overview ...........................................................................................................................................6
Citrix Hands-On Labs......................................................................................................................................................8
Module 1: Classic Policies ..............................................................................................................................................9
Exercise 1-1: Configuring Content Filtering with Classic Policies (GUI) ...................................................................11
Exercise 1-1: Configuring Content Filtering with Classic Policies (CLI) ...................................................................14
Module 2: Default Policies with HTTP callout and Rate limiting .................................................................................17
Exercise 2-1: Configuring HTTP Callout (GUI) ..........................................................................................................18
Exercise 2-2: Configuring Rate Limiting (GUI) .........................................................................................................22
Exercise 2-1: Configuring HTTP Callout (CLI) ...........................................................................................................25
Exercise 2-2: Configuring Rate Limiting (CLI) ...........................................................................................................28
Module 3: Advanced Policies with Responder, Rewrite, and URL Transform .............................................................30
Exercise 3-1: Rewrite Policy - Modify a URL (GUI)...................................................................................................32
Exercise 3-2: Rewrite Policy - Delete HTTP Headers (GUI) ......................................................................................36
Exercise 3-3: Rewrite Policy - Insert HTTP Headers (GUI) .......................................................................................40
Exercise 3-4: Rewrite Policy - Convert URL Paths to Lowercase (GUI) ....................................................................43
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) ...........................................................................................56
Exercise 3-8: Responder Policy - Redirect Using String Maps (GUI) ........................................................................61
Exercise 3-9: Responder Policy - Redirect to Imported Maintenance Page (GUI)...................................................66
Exercise 3-10: Responder Policy- Respond to the DNS request (GUI).....................................................................72
Exercise 3-1: Rewrite Policy - Modify a URL (CLI) ....................................................................................................75
Exercise 3-2: Rewrite Policy - Delete HTTP Headers (CLI) .......................................................................................79
Exercise 3-3: Rewrite Policies - Insert HTTP Headers (CLI) ......................................................................................82
Exercise 3-4: Rewrite Policy - Convert URL Paths to Lowercase (CLI) .....................................................................84
Exercise 3-5: Rewrite Policy – Modify the DNS Response (CLI) ...............................................................................88
Exercise 3-6: Rewrite Policy – Rewrite TCP header (CLI) .........................................................................................90
Exercise 3-7: Responder Policies to Redirect to SSL (CLI) .......................................................................................94
Exercise 3-8: Responder Policy - Redirect using String Maps (CLI)..........................................................................98
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
Exercise 4-2: Configure Content Switching by Content Type (GUI).......................................................................119
Exercise 4-1: Configuring Content Switching by User Agent(CLI)..........................................................................124
Exercise 4-2: Configure Content Switching by Content Type (CLI) ........................................................................128
Module 5: Secure Web Gateway (SWG) ....................................................................................................................132
Exercise 5-1: Configuring Secure Web Gateway (Explicit Mode) (GUI) .................................................................133
Exercise 5-1: Configuring Secure Web Gateway (CLI) ...........................................................................................137
Module 6: Optimization .............................................................................................................................................140
Exercise 6-1: Configuring Compression Policies (GUI)...........................................................................................141
Exercise 6-1: Configuring Compression Policies (CLI) ............................................................................................145
Module 7: Global Server Load Balancing (GSLB) .......................................................................................................150
Exercise 7-1: Configuring Active/Active GSLB (GUI) ..............................................................................................152
Exercise 7-2: Testing GSLB with DNS Proxy Configuration (GUI)...........................................................................164
Exercise 7-3: Configuring GSLB for Active/Passive Scenario (GUI) ........................................................................167
Exercise 7-4: Configuring Active/Active GSLB (Using Wizard) ...............................................................................171
Exercise 7-1: Configuring Active/Active GSLB (CLI) ...............................................................................................178
Exercise 7-2: Testing GSLB with DNS Proxy Configuration (CLI) ............................................................................185
Exercise 7-3: Configuring GSLB for Active/Passive Scenario (CLI) .........................................................................189
GSLB Troubleshooting Tips ....................................................................................................................................192
APPENDIX. NetScaler Counters .............................................................................................................................193
Lab Guide Overview
In this lab guide, you will get hands-on experience with NetScaler 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 Secure Web 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.
• NetScaler (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 NetScaler 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.111 Web server
Student Desktop -- 192.168.10.10 Student lab workstation; landing
workstation. All labs performed
from this system.
6
NETSCALER LIST
Virtual NSIP Address Subnet IP (SNIP) Address Description

Machine Name
NS_VPX_01 192.168.10.101 SNIP1: 192.168.10.111 (traffic) NS_VPX_01 is the principal NetScaler

SNIP2: 192.168.10.103 (mgmt.) for most exercises. It will be in an HA
Pair with NS_VPX_02, and they will
be managed via the shared SNIP
192.168.10.103.
NS_VPX_02 192.168.10.102 HA Pair: shared configuration Secondary member of HA Pair with
with NS_VPX_01. NS_VPX_01.
NS_VPX_03 172.22.15.201 SNIP1: 172.22.15.211 Standalone NetScaler participating in
the remote-site network. It will be
used as the GSLB partner NetScaler
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 NetScaler
delegated administration exercise.
trainNSOperator Training_NSOperators Password1 Domain account used in NetScaler
delegated administration exercise.
trainADUser Domain Users Password1 Domain account used as LDAP BindDN
service account.
Contractor Contractors Password1 Domain account available for NetScaler
demonstrations.
CREDENTIALS LIST: NetScaler Local Accounts
User Name Delegated Admin Password Description

Role
nsroot superuser nsroot Built-in NetScaler 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
Citrix Hands-On Labs
What are Hands-On Labs?

Hands-On Labs from Citrix Education allows you to revisit, relearn, and master the lab exercises
covered during the course. This offer gives you 25 days of unlimited lab access to continue your
learning experience outside of the classroom.
Claim introductory pricing of $500 for 25 days of access.

Contact your Citrix Education representative or purchase online here.
Why Hands-On Labs?

Practice outside of the classroom You will receive a fresh set of labs, giving you the
opportunity to recreate and master each step in
the lab exercises.
Test before implementing Whether you are migrating to a new version of a

product or discovered a product feature you
previously did not know about, you can test it out
in a safe sandbox environment before putting in
live production.
25 days of access Get unlimited access to the labs for 25 days after
you launch, giving you plenty of time to sharpen
your skills.
Certification exam preparation Get ready for your Citrix certification exam by
practicing test materials covered by lab exercises.
8
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 NetScaler Configuration Utility GUI and NetScaler CLI:
• Exercise: Configuring Content Filtering with Classic Policies.
Before you Begin:

Estimated time to complete this lab module: 15 minutes
Virtual Machines required for this module
9
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.
• NS_VPX_01
• NS_VPX_02
• WebBlue
• WebRed
• WebGreen
10
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 NS_HA_MGMT to connect to the NSMGMT
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.
11
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 Response Action drop-down list box.
• Click Create.
• Click OK on the Warning.
12
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 NetScaler.
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.
13
11. Save the NetScaler configuration and confirm.
• Click the Save icon (floppy disk) in the upper-right corner.
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
Configuring Content Filtering with Classic Policies

Step Action
14
1. Connect to NetScaler HA Pair using the NSMGMT 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 NetScaler.
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.
10. Save the NetScaler configuration:
save ns config
Takeaways:
15
• 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 a determined by both the bind point and the policy expression.
• Policies must be bound with the feature enabled to be in effect.
16
Module 2: Default Policies with HTTP callout and
Rate limiting
Introduction:
This module demonstrates the use of the default policy syntax, default policy bind points with HTTP call out and
rate limiting.
Default 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

• NS_VPX_01 • WebBlue
• NS_VPX_02 • WebRed
• HTTP_Callout • WebGreen
17
Exercise 2-1: Configuring HTTP Callout (GUI)
Overview:
This exercise demonstrates the configuration of an HTTP callout.
When the NetScaler 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 NetScaler 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:
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.111)
As a NetScaler 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.
18
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.
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.111.
• 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"/check_client.pl".
(**The quotes are required.)
• 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 NetScaler.
• 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.
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.
20
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.
Takeaways:
• HTTP Callouts can be used to make HTTP or HTTPS requests against a remote agent and retrieve and parse
the web response.
• 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.
21
Exercise 2-2: Configuring Rate Limiting (GUI)
Overview:
The NetScaler 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 NetScaler 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 NetScaler 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
• Reload the page in quick succession by hitting the reload button multiple times.
SNIP at http://192.168.10.103.
User Name: nsroot

Password: nsroot
22
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.
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.
• 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.

• 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.
23
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.
Takeaways:
• The Rate Limiting feature is another protection feature of the NetScaler 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.
24
Exercise 2-1: Configuring HTTP Callout (CLI)
Overview
This exercise demonstrates the configuration of an HTTP callout.
When the NetScaler 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 NetScaler 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.111)
25
As a NetScaler 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 NetScaler Command Line Interface
• Open PuTTY.exe from the student desktop.
• In the Saved session section, click NS_HA_MGMT.
• 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.111 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\""[SD1]
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 parameters cip(CLIENT.IP.SRC) –headers

callout("negate")
26
9. Set the return type (return value) of the result from the HTTPCallout server.
• set policy httpCallout Callout_Blacklist -returnType TEXT

10. Specify how the NetScaler should extract the response from the HTTP Callout server.
• set policy httpCallout Callout_Blacklist resultExpr "HTTP.RES.BODY(1000)"

• add responder action Blacklist_redirect_Act respondwithhtmlpage Error_Page -

responseStatusCode 200
12. Create Responder Policy
• add responder policy Blacklist_redirect_Pol

"HTTP.REQ.HEADER(\"172.21.10.101\").EXISTS &&
SYS.HTTP_CALLOUT(Callout_Blacklist).CONTAINS(\"IP Matched\")"
Blacklist_redirect_Act
13. Bind Responder Policy
• bind lb vserver lb_vsrv_rbg policyName Blacklist_redirect_Pol -priority 100

14. Test HTTP Callout

• Go to http://172.21.10.101/
• Verify that you are redirected to the error page.
15. 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
Takeaways:
• HTTP Callouts can be used to make HTTP or HTTPS requests against a remote agent and retrieve and parse
the web response.
• 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.
27
Exercise 2-2: Configuring Rate Limiting (CLI)
This exercise demonstrates the use of the Rate Limiting using NetScaler Command Line Interface.
Overview
The NetScaler 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 NetScaler 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 NetScaler 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
SNIP at http://192.168.10.103.
User Name: nsroot

Password: nsroot
3. Create a Limit Selector:
add stream selector Limit_Sel HTTP.REQ.URL CLIENT.IP.SRC
28
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
Takeaways:
• The Rate Limiting feature is another protection feature of the NetScaler 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.
29
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.
This module contains the following exercises, using the NetScaler Configuration Utility GUI and NetScaler 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

• Responder Exercises 3.5-3.7: 30-45 minutes
30
• NS_VPX_01 • WebGreen
• NS_VPX_02 • Ad.training.lab
• WebBlue • AD02.training.lab
• WebRed
31
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 NetScaler 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.
• 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.
32
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
SNIP at http://192.168.10.103.
User Name: nsroot

Password: nsroot
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.
33
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.
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
34
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
NetScaler 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.
Takeaways:
• Rewrite policies can be used to modify a request URL and rewrite the request between the NetScaler 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.
• 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.
35
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 NetScaler 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.
36
• 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 NetScaler 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
SNIP at http://192.168.10.103.
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.
37
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.
38
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.
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.
39
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.
• 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
SNIP at http://192.168.10.103.
User Name: nsroot

Password: nsroot
40
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.
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.
41
• 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.
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
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 server will be compared against this
policy. To avoid running the policy for every request and forcing the NetScaler 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:
43
NetScaler 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 NetScaler 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.
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.
44
• 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.
45
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.
46
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 NetScaler. When needed, though,
the NetScaler 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.
47
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 NetScaler 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.
Step Action
1. Connect to NetScaler HA Pair using the NSMGMT 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
48
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 NetScaler 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.
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.
49
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 NetScaler appliance is configured as a DNS proxy
server and there is a cache miss.
11. Switch to the NetScaler 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.
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, NetScaler 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 NetScaler 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 NetScaler HA Pair using the NSMGMT Snip (192.168.10.103) using SSH (PuTTY). Log on
using the following credentials:
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. Download Trace file:
• Open WinSCP and connect to NetScaler SNIP (NS_HA_MGMT) 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.
7. Open Trace file:
• Browse to C:\Resources\ on the Student Desktop.
• Open the file nstrace1.cap in Wireshark.
53
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.11

• Go to Follow > TCP Stream.
• WireShark Follow TCP Stream window will appear. Observe that the Client ip has been
inserted.
9. Close Wireshark.
54
10. 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.
12. Save NetScaler configuration and confirm.
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.
55
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
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
1. View the current state of lb_vsrv_rbg_sslredirect.
• View the lb_vsrv_rbg_sslredirect state.
Verify the following:

• State is DOWN.
• Effective State is DOWN.
56
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 NetScaler 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 an 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.
57
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 an 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.
58
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.
59
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.
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.
60
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
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"
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"
61
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 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.
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.
62
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.
63
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.
64

• 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 NetScaler 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
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.
65
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 NetScaler. You will use the Configuration Utility to
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 NetScaler 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.

• Configure Responder Actions.
• Configure Responder Policies.
• Test the Responder Policies.
• Restore the Virtual Server.
66
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 NetScaler 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.
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.
67
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.)
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.
68
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.
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.
69
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.

• 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.
70
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 NetScaler. Response code is
also 503 Service Unavailable.
Restore the Virtual Server (lb_vsrv_rbg)

Step Action
1. Re-enable the load balancing virtual server lb_vsrv_rbg:

• Select lb_vsrv_rbg, click Enable and confirm.
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
NetScaler), 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.
71
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 NetScaler 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.
72
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

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 NSMGMT 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.
73
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 NetScaler 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
74
14. Unbind the policy to lb_vsrv_dns:
• Switch to the NetScaler 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
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 NetScaler 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.
• 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.
75
• 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
• 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
76
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
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
NetScaler 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 NS_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
77
4. On NS_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 NetScaler 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.
78
Exercise 3-2: Rewrite Policy - Delete HTTP Headers (CLI)
Introduction:
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 NetScaler 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 NetScaler CLI and Firefox.
79
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.
80
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
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.
81
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.
• 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
82
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.
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.
83
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
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
84
policy. To avoid running the policy for every request and forcing the NetScaler 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:
NetScaler 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 NetScaler 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 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.
85
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
5. Save NetScaler 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.
86
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 NetScaler. When needed,
though, the NetScaler 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.
87
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
• 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
17. Enter the shell prompt

shell
88
18. 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
19. Exit the shell prompt
exit
20. 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)"
21. Configure Rewrite Policy
add rewrite policy rw_set_aa_pol true rw_set_aa_act

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

shell
89
dig yahoo.com @172.21.10.102
Observe that the DNS resolution is successful. and the flags set are : qr aa rd
exit
26. Unbind Policy to the vserver
unbind lb vserver lb_vsrv_dns -policyName rw_set_aa_pol -priority 10 -type RESPONSE
27. Save NetScaler 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.
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, NetScaler does not
90
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 NetScaler HA Pair using the NSMGMT Snip (192.168.10.103) using SSH (PuTTY). Log on
using the following credentials:
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

5. Perform Test
• Start NetScaler Trace
start nstrace -size 0 -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 NetScaler Trace

stop nstrace
91
6. Download Trace file
• Open WinSCP and connect to NetScaler SNIP (NS_HA_MGMT) 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.
7. Open Trace file
• Browse to C:\Resources\ on the Student Desktop.
• Open the file nstrace1.cap in Wireshark.
92
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.11

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
93
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
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.
94
Prepare the HTTP Load Balancing Virtual Server
Step Action
13. 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.
14. 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 NetScaler loopback address
(127.0.0.1).
15. 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
16. 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.
95
17. 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
96
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
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.
97
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
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

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
98
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 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.
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.
99
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
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.
100
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
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/media.php
• http://172.21.10.101/dist_red.php
• http://172.21.10.101/home.php
101
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.
102
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 NetScaler. 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:
1. Create a Backup vserver 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 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 NetScaler 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
103
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
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.)
104
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.
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
NetScaler. 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
105
Step Action
1. Open Firefox.
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 NetScaler. Response code is
also 503 Service Unavailable.
Restore the Virtual Server

Step Action
106
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
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 NetScaler), 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. So 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.
107
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 NetScaler 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.
As a NetScaler administrator you need to
Configure Responder policy to check if the Request is over UDP
If yes, send response to client requesting the data over TCP
108
Step Action
1. Test the original behavior
Browse to Start > Command Prompt
Observe that the request resolves to 192.168.30.51

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, tr

ue, 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
109
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 NetScaler enter shell prompt

shell
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
110
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
111
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:
• 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

• 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.
Scenario:
112
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
SNIP at http://192.168.10.103.
User Name: nsroot

Password: nsroot
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.
113
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.
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.
114
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.
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.
115
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.
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.
116
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.
5. View the content-switching policy statistics after the test cases:
• Switch to the NetScaler 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:
• Click Default Load Balancing Virtual Server under Content Switching Policy Binding.
• View hits.
Click Close.
7. Click Done.
Takeaways:
• Content Switching is evaluated before Load Balancing.
• Content-switching policies are used to direct matching traffic to specific load balancing virtual servers.
117
• 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 NetScaler 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.
118
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.
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")
119
• Create Pattern Sets for Content Types.

• 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.
120
Create Content-Switching Policies Using Pattern Sets
Step Action
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 NetScaler 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.
Identify how many content requests were handled by the default destination (Green).
Click Close.
4. Click Done.
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.
123
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.
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
124
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")'
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
125
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
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.
126
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.
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.
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 NetScaler 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.
127
Exercise 4-2: Configure Content Switching by Content Type
(CLI)
Introdcution:
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
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 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")
128
• Create Pattern Sets for Content Types.

• 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:
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")'
129
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:

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
130
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.
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.
• 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.
131
Module 5: Secure Web Gateway (SWG)
Introduction:
Secure Web Gateway is traffic management feature which combines the functionality of the content witching
virtual server and forward proxy mode.
A NetScaler 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
NetScaler 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 NetScaler Secure Web Gateway requires a separate platform license. This feature is NOT included in the
NetScaler ADC [SD3]platform license.

• WebRed
132
Exercise 5-1: Configuring Secure Web Gateway (Explicit Mode)
(GUI)
Introduction:
In this exercise you will learn to implement NetScaler 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 NetScaler 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.
SNIP at http://192.168.10.103.
User Name: nsroot

Password: nsroot
3. Install the SWG license on the NetScaler:
• Browse to System > Licenses.

• Click Manage Licenses.
• Click Add New License.
• Select Upload license files.
• Click Browse.
• Browse to C:\Users\localuser\Desktop\Resources\NetScaler License.
• Select file CNS_WEBF_SSERVER_Retail.lic and Click Open.
133
• Click Add New License.
• Select Upload license files.
• Click Browse.
• Browse to C:\Users\localuser\Desktop\Resources\NetScaler License.
• Select file CNS_V1000_SERVER_SWG_Retail.lic and Click Open.
• Click Reboot and confirm by clicking Yes.
NOTE: Sometimes after installing the licenses they GUI will be delayed in displayed the files on the
system. If necessary, reboot one more time to allow them to refresh.
4. Verify the DNS Name Server Configuration:
• Browse to Traffic Management > DNS > 1 Name Servers.

• Confirm that the Effective State of the Name Server 192.168.30.11 is UP.
5. Install Root CA Certificate:
• Browse to Traffic Management > SSL > Certificate > 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 Traffic Management > SSL > CA Certificates.
• Verify that the Root the Certificate SWG_CA_Cert is present under the CA Certificates list.
6. 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.
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.
7. Create Responder Action:

• Click Add.
• In the Name field, enter SWG_Block_Act.
• In the Type field, select Respond with.
134
"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.


• 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.
9. Configure Explicit Forward Proxy Vserver:
• Browse to Secure Web Gateway > No 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.105.
• In the Port field, enter 80.
• Click OK.
• 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.
11. 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.
• In the Advanced Settings section, Click SSL Profile.
• In the SSL Profile section, 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 is enabled
• In the Maximum SSL Sessions Per Server, enter 100.
• Click OK.
135
• Click Done.
12. Change Syslog parameter:
• Browse to System > Auditing.

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

14. 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.105
• 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.
15. Perform Test:
• In the Internet explorer open a new window and browse for https://youtube.com/
• Observe that the url is being blocked and the page is not displayed.
16. 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.
Takeaways:
• The features Responder, AAA-TM, content switching, SSL, forward proxy, SSL interception, and URL
filtering are used while configuring the Secure Web Gateway.
136
• The NetScaler 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 5-1: Configuring Secure Web Gateway (CLI)
Overview
In this exercise you will learn to implement NetScaler 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 NetScaler 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. Log on NetScaler Command Line Interface
• Open PuTTY.exe from the student desktop.
• In the Saved session section, click NS_HA_MGMT.
• Click Open.
• Log on with following credentials:
Login as: nsroot
Password : nsroot
137
2. Upload a license file to the NetScaler:
• Open WinSCP using the shortcut on the Desktop. Connect to NS_VPX_01 (192.168.10.101).
• Click Yes on the Security Warning if needed and login with nsroot/nsroot.
• In the left pane, browse to C:\Users\localuser\Desktop\Resources\NetScaler 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 NetScaler.
3. Save the NetScaler Configuration:

save ns config
4. Perform a warm restart to apply license file changes:

reboot -warm
5. Verify the DNS Name Server Configuration
• show dns nameServer

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

7. Configure URL sets
• Import the URL SET to NetScaler

import policy blacklist_url_set ssl -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
• add responder action SWG_Block_Action respondwith q{"HTTP/1.1 451Unavailable for

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

"HTTP.REQ.HOSTNAME.APPEND(HTTP.REQ.URL).URLSET_MATCHES_ANY(\"blacklist_url_s
et\")||http.REQ.URL.URLSET_MATCHES_ANY(\"blacklist_url_set\")" SWG_Block_Action
10. Configure Explicit Forward Proxy Vserver
• add cs vserver SWG_VS PROXY 192.168.10.105 80
• bind cs vserver SWG_VS -policyName SWG_Block_Pol -priority 100 -gotoPriorityExpression

END -type REQUEST
12. Change Syslog parameter
• set syslogparams -sslInterception ENABLED
13. Configure SSL Interception:
138
• 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
14. Save Configuration:

• Save nsconfig

• Click LAN settings.
• Check the box for Use a proxy server for your LAN.
• Enter Address as 192.168.10.105.
• Enter Port as 80
• Click OK
• Click OK
16. Perform Test
• In the Internet explorer open a new window and browse for

https://youtube.com/,category2,
• Observe that the url is being blocked and the page is not displayed.

• 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
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 NetScaler 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.
139
Module 6: Optimization
Introduction:
Company ABC wants to ensure that the NetScaler 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 NetScaler.
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 NetScaler Configuration Utility GUI and NetScaler CLI:
• Exercise: Configuring Compression Policies
Before you Begin:

140
• NS_VPX_01 • WebRed
• WebBlue • Ad.training.lab
Exercise 6-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 NetScaler 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
SNIP at http://192.168.10.103.
User Name: nsroot

Password: nsroot
141
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 > Policies.

• Click Add.
• Enter cmp_pol_javascript in the Policy Name field.
• Select Compress in the Response Action field.
Configure the policy expression:
• Click Switch to Default Syntax under the Expression box.

• 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.
142
5. Bind the compression policy to lb_vsrv_rbg:
• Click 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
143
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.
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 NetScaler 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).
144
Exercise 6-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 NetScaler 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
1. Enable the Compression feature:
enable ns feature cmp
145
2. 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
3. View compression engine to using the classic policy engine:
show cmp parameter
Verify that the compression policy type is set to Classic.
4. 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).
5. 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:
• http://172.21.10.101/home.php
• http://172.21.10.101/media.php
NOTE: stylesheets (.css) will be compressed in MSIE and not in Firefox.

6. View current policy hits:
show cmp policy -summary
Notice that all the policy hits up to this point are with the classic policies only.
7. Change compression engine to using the default (Advanced) policy engine:
set cmp parameter -policyType ADVANCED
146
8. Generate additional compression data.
Open a web browser and access the following URLs from Firefox, Chrome, or Internet Explorer:
• http://172.21.10.101/home.php
• http://172.21.10.101/media.php
9. View current policy hits:
This time, the policy hits occur with the default policy engine. This is all the policies named
ns_adv_.
10. 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
11. 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

147
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
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 NetScaler 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.
148
• 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).
149
Module 7: Global Server Load Balancing (GSLB)
Introduction:
In the GSLB, NetScaler 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 NetScaler 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 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:
NetScaler Appliances:
• NS_VPX_01 and NS_VPX_02 will remain in an HA Pair and will make up the Frankfurt location and its
resources.
• NS_VPXP_03 will be a standalone NetScaler in the Tokyo site, hosting the Tokyo resources. Redundancy
will not be implemented for the Tokyo location at this time.
Web Resources:
150
• 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 NetScaler 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 NetScaler, 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.
• 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 NetScaler Configuration Utility GUI and NetScaler 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 NetScaler GSLB Wizard)
NOTE: The exercsie 7-4 , we will be using NetScaler 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.
151
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:


• NS_VPX_03 • AD02.training.lab
• WebBlue • WebRemote
• WebRed
Exercise 7-1: Configuring Active/Active GSLB (GUI)
152
Introduction:
In this exercise, you will learn to configure Global Server Load Balancing on NetScaler 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 NetScaler appliances.
• Prepare for GSLB on the NetScaler HA Pair for Frankfurt.

• Create the GSLB Site on the NetScaler HA Pair for Frankfurt.
• Create the GSLB Site on the NetScaler for Tokyo.
• Configure GSLB Services and Virtual Server on the NetScaler HA Pair for Frankfurt.
• Synchronize the GSLB Configuration between Frankfurt and Tokyo sites.
NOTE: In this exercise, you will be required to switch between NetScaler appliances to make configurations. You
will be told which NetScaler 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.
2. Take snapshot of NS_VPX_01
• Right Click on NS_VPX_01 and click Take a snapshot…

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

153

Prepare for GSLB on the NetScaler HA Pair for Frankfurt

• Before this lab begins please ensure the following vms have been started:
• WebRemote.
Step Action
5. Connect to the NetScaler HA Pair for Frankfurt using NSHA MGMT 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 NetScaler view.
154
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 NetScaler 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 NetScaler. 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
NetScaler.
• Metric Exchange is enabled but the MEP status is DOWN. This is expected behavior until
the Tokyo NetScaler is configured in a later exercise.
155
3. Verify that the GSLB site IP address function is running on a NetScaler-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 NetScaler for Tokyo

Step Action
1. Connect to the NS_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 NetScaler HA Pair and NS_VPX_03. Exercises
will indicate when to switch between systems.
2. NS_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 NetScaler. 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 NetScaler.

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

• Metric Exchange is enabled.
• MEP status is now Active.
Once both GSLB sites have been configured with valid IP addresses on both NetScaler
appliances, Metric Exchange Protocol (MEP) is successful and the MEP status for the REMOTE
site on each respective NetScaler 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 NetScaler-owned IP address for the
Tokyo NetScaler:
• Browse to System > Network > IPs.

• Confirm that the SNIP 172.22.15.211 is being used for both SNIP and GSLB functions.
6. NS_VPX_03 (172.22.15.201) - Save the NetScaler 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 NetScaler HA Pair as well.
The following details should be displayed:
• site_ffm should be identified as the LOCAL site for this NetScaler.

• site_tok should be identified as the REMOTE site for this NetScaler. MEP Status is now
ACTIVE.
9. NSHA MGMT (192.168.10.103) - Save the NetScaler configuration and confirm.
Configure GSLB Services and Virtual Server on the NetScaler HA Pair for
Frankfurt
Step Action
1. Remain on NSHA MGMT (192.168.10.103). Do not configure NS_VPX_03 (172.22.15.201) until
instructed to do so.
157
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 NetScaler 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 NetScaler 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 NetScaler 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.
158
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 [SD4]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 NetScaler view.

• Verify that the virtual server state is UP.
159
9. Test that GLSB is resolving the FQND to the correct service from the NetScaler.
• 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).
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 NSHA MGMT 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 NetScaler.
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 NSHA MGMT (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.
160
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 NetScaler 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
NetScaler the command is issued on to the designated sites, overwriting their configuration. It is
possible to run this command on the wrong NetScaler and lose settings.
Also, for GSLB synchronization to work, the GSLB sites must be configured on all partner
NetScaler 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 NS_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 NetScaler.
We will manually confirm that the replication completed successfully.

7. Switch to NS_VPX_03 (172.22.15.201).
161
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 NetScaler 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.
Takeaways:
• GSLB Sites are configured to represent the NetScaler appliances participating in the GSLB configuration.
NetScaler appliances in a GSLB configuration communicate to the GSLB Site IP address of partner
NetScaler.
• 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.
• NetScaler 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
162
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 NetScaler appliances for
synchronization to work.
163
Exercise 7-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
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 NetScaler 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 NetScaler 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.
164
2. Configure the Student Desktop with the DNS Proxy load balancing virtual server on the NetScaler
(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 NSHA MGMT 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. NSHA MGMT (192.168.10.103) - Save the NetScaler Configuration and confirm.
8. Return to the CMD prompt on Student Desktop.
165
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 NetScaler HA Pair, and it should display RED and Japanese content when
served from the Tokyo NetScaler.
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
Takeaways:
• DNS requests for GSLB-based names have to get to the NetScaler to be resolved using a GSLB-based
process.
166
• NetScaler GSLB can integrate with DNS through sub-delegation, ADNS configurations, or the DNS Proxy
configuration illustrated in the exercise.
• 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 NetScaler 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 7-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
NetScaler HA pair (NS_VPX_01 and NS_VPX_02) will host the primary data center using the Frankfurt resource
(lb_vsrv_ffm). NS_VPX_03 will act as the backup data center using the Tokyo resource (lb_vsrv_tok). Only when
the Frankfurt Web server or the NetScaler 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

Step Action
167
1. NSHA Mgmt (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.
168
6. NSHA MGMT (192.168.10.103) - Synchronize the GSLB Configuration from NSHA MGMT to
NS_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 NS_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.
169
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 NSHA MGMT (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 NetScaler.

• Right-Click on lb_vsrv_ffm and select Disable.
NOTE: This time nslookup only returns a single IP address for the Tokyo virtual server:
172.22.15.231.
Takeaways:
• Multiple GSLB virtual servers can be associated with a single GSLB site configuration.
• GSLB services can represent entities on remote NetScaler 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.
170
Exercise 7-4: Configuring Active/Active GSLB (Using Wizard)
This is an exercise to demonstrate the use of the GSLB Wizard.
With NetScaler 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.
2. Restore NS_VPX_01
• Click NS_VPX_01
• On the right pane, click Snapshots.
• Click NS_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.
171
• Click NS_VPX_02
• Click Yes.
• Click NS_VPX_03
• Click Yes.

Step Action
1. Connect to the NetScaler HA Pair for Frankfurt using NSHA MGMT 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 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 NetScaler view.
172
4. Enable the GSLB feature:
Method 1:
Method 2:
already enabled.
• Click OK.
Configure GSLB on the NetScaler HA Pair for Frankfurt

Step Action
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.
173
7. Create the GSLB site for the Tokyo NetScaler. 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 NetScaler.
• Metric Exchange is enabled but the MEP status is DOWN. This is expected behavior until
the Tokyo NetScaler 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.
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.
174
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 configured yet.
Configure GSLB on the NetScaler for Tokyo

Step Action
1. Connect to the NS_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.
175
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. . NS_VPX_03 (172.22.15.201) - Enable GSLB Feature:
Method 1:
Method 2:
already enabled.
• Click OK.
5. Create the GSLB Site for the Tokyo HA Pair. Use the management SNIP (172.22.15.211) as 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 172.22.15.211.
• Click Create.
6. Create the GSLB site for the Frankfurt NetScaler. Use the management SNIP (192.168.10.103) as
the site IP address:
• Click Add Sites.

• Click Create.
Click Continue.
176
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.
9. 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.
177
Exercise 7-1: Configuring Active/Active GSLB (CLI)
Introduction:
In this exercise, you will learn to configure Global Server Load Balancing on NetScaler 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 NetScaler appliances.
• Prepare for GSLB on the NetScaler HA Pair for Frankfurt.

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

Step Action
178
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 NetScaler 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
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 metric exchange is enabled.
• site_tok should be identified as the REMOTE site for this NetScaler.
• site_tok metric exchange is enabled, but MEP status is DOWN. This is expected
behavior until the Tokyo NetScaler is configured.
179
5. NSHA MGMT (192.168.10.103) - Save the NetScaler configuration:
save ns config
Create the GSLB Site on the NetScaler for Tokyo

Step Action
1. Connect to NS_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
2. NS_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.
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.
180
7. Verify the GSLB site status:
show gslb site
• site_ffm should be identified as the REMOTE site for this NetScaler.

• site_ffm metric exchange is enabled and MEP Status is now ACTIVE.
• site_tok should be identified as the LOCAL site for this NetScaler.
• site_tok metric exchange is enabled.
8. NS_VPX_03 (172.21.15.201) - Save the NetScaler 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 NetScaler HA Pair as well:
show gslb site

• site_tok should be identified as the REMOTE site for this NetScaler. MEP Status is now
ACTIVE.
11. NSHA MGMT (192.168.10.103) -
Save the NetScaler configuration:
save ns config
Configure GSLB Services and Virtual Server on the NetScaler HA Pair for
Frankfurt
Step Action
1. Remain on NSHA MGMT (192.168.10.103). Do not configure NS_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
181
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
9. Test that GSLB is resolving the FQDN to the correct service from the NetScaler:
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).
182
10. NSHA MGMT (192.168.10.103) -
save ns config
Synchronize the GSLB Configuration between Frankfurt and Tokyo Sites

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

• Connect to NS_VPX_03 at 172.22.15.201 over SSH (using PuTTY).
2. NS_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.
183
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 NetScaler 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
NetScaler. The command is issued on to the designated sites, overwriting their configuration. It
is possible to run this command on the wrong NetScaler and lose settings.
Also, for GSLB synchronization to work, the GSLB sites must be configured on all partner
NetScaler 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 NetScalers, 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 NetScaler.
We will manually confirm that the replication completed successfully.
save ns config
6. Switch to NS_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. NS_VPX_03 (172.22.15.201) -
save ns config
184
Takeaways:
• GSLB sites are configured to represent the NetScaler appliances participating in the GSLB configuration.
NetScaler appliances in a GSLB configuration communicate to the GSLB Site IP address of partner
NetScalers.
• 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.
• NetScaler 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 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 NetScaler appliances for
synchronization to work.
Exercise 7-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
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 NetScaler 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 NetScaler 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
185
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.
2. Configure the Student Desktop with the DNS Proxy load balancing virtual server on the NetScaler
(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
186
6. NSHA MGMT (192.168.10.103) - Save the NetScaler Configuration:
save ns config
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 NetScaler HA Pair, and it should display RED and Japanese content when
served from the Tokyo NetScaler.
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
Takeaways:
• DNS requests for GSLB-based names have to get to the NetScaler to be resolved, using a GSLB-based
process.
• NetScaler 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
187
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 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 NetScaler 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.
188
Exercise 7-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
NetScaler HA pair (NS_VPX_01 and NS_VPX_02) will host the primary data center using the Frankfurt resource
(lb_vsrv_ffm). NS_VPX_03 will act as the backup data center using the Tokyo resource (lb_vsrv_tok). Only when
the Frankfurt web server or the NetScaler 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. NSHA Mgmt (192.168.10.103) - Create a new GSLB virtual server as a backup virtual server:
add gslb vserver gslb_vsrv_backup HTTP
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. 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.
189
save ns config
6. 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.
7. Switch to NS_VPX_03 (172.22.15.201) -
Save the NetScaler Configuration:
save ns config
Test the Active/Passive Configuration

Step Action
NOTE: This time nslookup only returns a single IP address for the Frankfurt virtual server:
17.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 NetScaler.
190
NOTE: This time nslookup only returns a single IP address for the Tokyo virtual server:
172.22.15.231.
Takeaways:
• Multiple GSLB virtual servers can be associated with a single GSLB site configuration.
• GSLB services can represent entities on remote NetScalers, 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.
191
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 NetScaler 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 NetScaler systems.
6. Verify on the NetScaler system that the resolution is alternating between GSLB services.
Example: From the command-line interface on a given NetScaler 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 NetScaler
systems. Using the Configuration Utility instead of the command-line interface may make quickly
verifying the configured settings easier.
Using dig
192
APPENDIX. NetScaler Counters
Troubleshooting NetScaler issues become easier with NetScaler counters:
• Authentication policies and session policies applied on the NetScaler 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 NetScaler Gateway
virtual server:
nsconmsg –d current | egrep –i rewrite
• Responder policy bound at a global level or to a load balancing, content switching, or NetScaler 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
193

CNS-219-2i Citrix NetScaler Traffic Management Lab Guide

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-219-2i Citrix NetScaler Traffic Management Lab Guide

Uploaded by

Copyright:

Available Formats

Education

CNS-219-2i Citrix NetScaler Traffic Management

Lab Guide Version 1.6

Before You Begin:

• For SFTP access: WinSCP

Virtual Machine Name Domain FQDN IP Address Description

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

Virtual NSIP Address Subnet IP (SNIP) Address Description

NS_VPX_01 192.168.10.101 SNIP1: 192.168.10.111 (traffic) NS_VPX_01 is the principal NetScaler

CREDENTIALS LIST: Training Domain Users and Groups

User Name Groups Password Description

administrator Domain Admins Password1 Domain administrator account which can

CREDENTIALS LIST: NetScaler Local Accounts

User Name Delegated Admin Password Description

nsroot superuser nsroot Built-in NetScaler account that will be

What are Hands-On Labs?

Claim introductory pricing of $500 for 25 days of access.

Why Hands-On Labs?

Test before implementing Whether you are migrating to a new version of a

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

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

In this exercise, you will perform the following task:

• 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.

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.

• 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.

• 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.

In this exercise, you will perform the following tasks:

• 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

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

add policy expression red_url "REQ.HTTP.URL == /red.php"

add filter policy cf_red_url -rule red_url -reqAction DROP

bind lb vserver lb_vsrv_rbg -policyName cf_red_url -priority 10

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