NetScaler Responder

NetScaler Responder allows administrators to control how the system responds to incoming client requests. By using responder policies, administrators can intercept, redirect, or drop requests based on specific conditions. This capability helps improve security, manage traffic, and optimize user experience without making changes to the backend server.

Responder supports protocols such as TCP, DNS (UDP), and HTTP. By avoiding the invocation of more complex features, it reduces CPU cycles and time spent in handling requests that do not require complex processing.

Key Functions of NetScaler Responder:

1. HTTP Redirection: Responder can redirect traffic from one URL or domain to another based on conditions, such as:

   • Redirecting HTTP traffic to HTTPS for secure communication.
   • Redirecting requests to a maintenance page or a different application version during server upgrades.

2. Blocking Requests: With Responder, administrators can block specific types of requests, such as:

   • Blocking access from specific IP addresses or countries.
   • Denying access to certain URLs or resources, such as administrative pages.
   • Blocking requests with certain patterns in headers, like invalid User-Agent strings, or suspicious query parameters.

3. Custom Responses: Responder can send custom responses, including status codes and custom HTML pages, in cases like:

   • Sending a custom “403 Forbidden” or “404 Not Found” page.
   • Displaying a “503 Service Unavailable” page during planned maintenance.
   • Sending security warnings for blocked or unauthorized actions.

4. URL Rewriting and Redirection: Similar to the Rewrite feature, Responder can modify URLs based on conditions and can:

   • Redirect specific URL patterns to another path.
   • Modify query strings in URLs before the requests are processed by the backend.

5. Rate Limiting and Traffic Management: Responder can help control the load on servers by blocking or redirecting requests that exceed certain thresholds, preventing Denial of Service (DoS) attacks or abusive traffic.

Common Responder Use Cases:

• HTTP to HTTPS Redirection: Automatically redirect all HTTP requests to HTTPS to enforce secure connections.

• Block Access to Specific Paths: Prevent access to certain URLs, such as /admin or /login, unless the request comes from an authorized IP.

• Geolocation-based Blocking: Block traffic from specific countries or regions for security reasons.

• Maintenance Page: Respond with a custom “503 Service Unavailable” page during maintenance windows.

• Bot Protection: Identify and block bot traffic based on specific request patterns, such as suspicious User-Agent strings.

• Rate Limiting: Limit the number of requests per second from a particular client or IP, and block requests exceeding this rate to prevent abuse.

Benefits of NetScaler Responder:

• Enhanced Security: By blocking suspicious or unwanted traffic at the ADC level, Responder helps mitigate security threats before they reach the backend infrastructure.

• Traffic Optimization: Responder allows fine-grained control over traffic redirection and request blocking, helping optimize how users interact with the application.

• Simplified User Experience: Redirect users seamlessly to appropriate resources or pages, enhancing usability and maintaining consistent service delivery.

• Custom Error Handling: Improve the user experience by displaying friendly error messages or redirects during outages, maintenance, or blocked access attempts.

NetScaler Responder is a vital tool for managing incoming traffic efficiently and securely. It allows for real-time handling of requests by enforcing rules that govern how traffic is responded to, blocked, or redirected. This flexibility helps maintain the balance between security, performance, and user experience without the need for backend server modifications.

NetScaler Rewrite

NetScaler Rewrite allows administrators to modify or manipulate HTTP requests and responses on-the-fly. This capability is useful for altering content or URLs without making changes to the backend server, which can improve flexibility, performance, and security. NetScaler performs data rewriting in both directions: when sending requests to the server and when sending responses back to the user.

Key Functions of NetScaler Rewrite:

1. URL Rewriting: Modify URLs in requests or responses before they reach the client or the backend server. This is often used for:

   • Redirecting users to a different domain or subdomain.
   • Changing query parameters in a URL.
   • Masking internal server details for security.

2. Header Modification: Adjust headers in HTTP requests or responses. This helps:

   • Add, modify, or delete headers like Host, User-Agent, Cookie, etc.
   • Modify headers to reflect different content types, security settings, or cache rules.

3. Content Rewriting: You can change the content within the HTTP response. This is used for:

   • Altering response body content such as HTML, JavaScript, or CSS.
   • Implementing branding changes without altering the application.
   • Inserting or modifying inline JavaScript for analytics or tracking purposes.

4. Session Persistence and User Experience: Rewrite can help maintain consistent user sessions or personalize experiences by:

   • Ensuring session stickiness by modifying cookies or session identifiers.
   • Altering user-facing content based on user behavior or location.

Benefits:

• Improved Security: Mask internal server structure, remove sensitive headers, or redirect traffic based on security policies.
• Flexibility: You can dynamically adjust content and routing without backend changes.
• User Experience: Personalize or modify responses based on user behavior or other conditions.
• SEO Optimization: By modifying URLs and handling redirects properly, you can enhance search engine performance.

In summary, NetScaler Rewrite is a versatile tool that provides administrators with extensive control over how traffic flows through the Citrix ADC. It allows for the adjustment of both client-facing content and server-facing requests, helping balance security, performance, and user experience.

Rewrite vs Responder

Here’s a clear comparison between NetScaler Rewrite and NetScaler Responder in a table format to highlight their key differences:

One of the main differences between Rewrite and Responder is that Rewrite can apply to both requests and responses whilst Responder can only apply to requests reaching the NetScaler.

In summary, NetScaler Rewrite is used primarily for modifying content within requests or responses, while NetScaler Responder controls how the system responds to requests by redirecting, blocking, or sending customized responses.

• Responder Policies: These policies typically handle requests based on client-side parameters, such as URL patterns, headers, or specific conditions. They decide how the server responds without necessarily forwarding the request to the backend server. For example, a responder policy can be configured to block or redirect a client request based on the URL or headers without contacting the backend server.

• Rewrite Policies: These policies modify the request or response by rewriting URLs, headers, or content. Unlike responder policies, rewrite policies can act on both the client request and the server response. When a request comes in, the rewrite policy examines it (similar to a responder), but it also has the flexibility to modify the response after receiving data from the server. For instance, it can change the URL before forwarding the request to the server, or modify the content of the response before sending it back to the client.

• If you have a client parameter setup you can use responder, and if any other you can use rewrite setup and then in responder policy, it will redirect an Http request to a new website, or it can use a custom response page.

URL Transformation

This feature modifies URLs in requests from external users to internal URLs that are only visible to internal servers. When the response is sent back, NetScaler translates the internal URL back to the original URL requested by the external user. To enable this functionality, the rewrite feature must be enabled. URL transformation and rewrite cannot work on the same HTTP headers during processing.

Content Switching:

When users request a webpage, you may want to provide a different page depending on the user geographical location, browser specification, or languages the browser accepts and the order of preference. You might want to drop the connection if the request is coming from an IP range that has been generating DDoS attacks or initiating hacking attempts.

You might want to present different content to different users. For example, you might want to allow users from the IP range of a customer or partner to have access to a special Web portal. You might want to present content relevant to a specific geographical area to users from that area. You might want to present content in different languages to the speakers of those languages. You might want to present content tailored to specific devices, such as smartphones, to them who use the devices. The NetScaler content switching feature enables the appliance to distribute client requests across multiple servers based on specific content that you want to present to those users.

A content switching configuration consists of a content switching virtual server, a load balancing setup consisting of load balancing virtual servers and services, and content switching policies. To configure content switching, you must configure a content switching virtual server and associate it with policies and load balancing virtual servers. This process creates a content group— a group of all virtual servers and policies involved in a particular content switching configuration.

Content switching can be used with HTTP, HTTPS, TCP, and UDP connections. For HTTPS, you must enable SSL Offload.

When a request reaches the content switching virtual server, the virtual server applies the associated content switching policies to that request. The priority of the policy defines the order in which the policies bound to the content switching virtual server are evaluated. If you are using Advanced policy policies, when you bind a policy to the content switching virtual server, you must assign a priority to that policy. If you are using NetScaler classic policies, you can assign a priority to your policies, but are not required to do so. If you assign priorities, the policies are evaluated in the order that you set. If you do not, the NetScaler appliance evaluates your policies in the order in which they were created.

• If you assign priorities, the policies are evaluated in the order that you set
• If you do not, the NetScaler evaluates your policies in the order in which they were created
• A default virtual server can be bound for all traffic not matched in the previous policy expression and actions
• If the configured default vServer is DOWN, or no default vServer is configured, an HTTP 503 Not Found error message is sent to the client by the default vServer.

Before we configure content switching, you should have a working load balancing vserver or gateway which is attached to the content switching vserver.

CS doesn’t need lb vserver to be in up state. Even with nothing bound to CS vserver, it will show as up. If you’d like to change the status of CS vserver based on the target lb vserver bound to it, then you should enable the option “State Update” in the CS configuration.

If you enable state update option by default the CS vserver status will be down. After you add lb vservers to it and their state is up, only then CS vserver status will be up.

Pattern Set, Data Sets and String Maps

In NetScaler (Citrix ADC), Pattern Sets, Data Sets, and String Maps are tools used for efficient data matching and policy execution. They help optimize the configuration by allowing administrators to match patterns, store data, and create mappings for use in policies such as responder, rewrite, or content switching.

Here’s a detailed breakdown of each:

1. Pattern Sets

A Pattern Set is a collection of strings or patterns that you can use in policies to match against incoming requests or responses. These patterns are often used for URL matching, header matching, or other client-side data.

• Purpose: To match multiple patterns (such as strings, URLs, or headers) with fewer configurations.
• Usage: Instead of writing multiple policies to match different strings, you define a pattern set with all relevant patterns and use that in your policy.

Example: If you want to block multiple malicious user agents, you can create a pattern set containing the list of those user agents, and a responder policy can reference this pattern set.

1
2

Pattern Set: "MaliciousUserAgents"
Contains: "BadBot", "MaliciousCrawler", "EvilScraper"

You can then create a policy like:

1

HTTP.REQ.HEADER("User-Agent").CONTAINS_ANY("MaliciousUserAgents")

2. Data Sets

A Data Set is a collection of key-value pairs. You can think of it as a list of values (keys), with each having an associated action or information (value). This is helpful when you need to map different values to specific actions or attributes within a policy.

• Purpose: To store and retrieve key-value pairs dynamically.
• Usage: It allows you to create flexible mappings where you can input data and return the mapped output (the value associated with the key).

Example: You could store a list of country codes and their associated redirection URLs.

1
2
3
4

Data Set: "CountryRedirects"
"US" -> "https://us.example.com"
"IN" -> "https://in.example.com"
"UK" -> "https://uk.example.com"

You can use this dataset in a policy to redirect based on the user’s country code, detected via IP Geolocation:

1

HTTP.REQ.IP.SRC.GEOIP_COUNTRY_CODE.ENTITY.GET("CountryRedirects")

3. String Maps

A String Map is a more flexible and advanced structure compared to pattern sets and data sets. It stores key-value pairs, but the values can be strings, integers, or even expressions. String maps are especially useful for rewriting policies where you want to replace or manipulate data.

• Purpose: To map strings to specific values or expressions for dynamic string manipulation or rewrites.
• Usage: It can be used in complex policies to manipulate request/response headers or URLs dynamically.

Example: If you have different URL rewrites based on hostnames, you can create a string map like this:

1
2
3

String Map: "HostRewriteMap"
"www.oldsite.com" -> "www.newsite.com"
"shop.oldsite.com" -> "shop.newsite.com"

And then in a rewrite policy:

1

HTTP.REQ.HOSTNAME.ENTITY.GET("HostRewriteMap")

This will dynamically replace old hostnames with new ones based on the string map.

Summary:

• Pattern Sets: Used for matching predefined sets of strings or patterns in policies.
• Data Sets: Store key-value pairs for dynamic mapping, particularly useful in geolocation, headers, etc.
• String Maps: Advanced key-value mappings, often used for URL or header rewrites and other dynamic string operations.

These tools make it easier to manage complex configurations in NetScaler by centralizing data and reusing it across multiple policies.

After creating a Pattern Set, Data Set, or String Map in NetScaler (Citrix ADC), the next step is to use them within responder policies, rewrite policies, or other types of policies (like content switching or load balancing policies). These policies are then applied to a Load Balancing (LB) vServer, Citrix Gateway VIP, or other relevant virtual servers.

HTTP Callout

An HTTP callout in NetScaler refers to a mechanism that allows the appliance to make an external HTTP request to a third-party service or server during the processing of a client request. This feature is often used to integrate with external services for tasks such as validation, authentication, or content fetching, based on the incoming client request.

When an HTTP callout is triggered, the NetScaler appliance pauses the flow of the original client request, sends an HTTP request to the specified external server, and then waits for the response. Based on the response from that external server, the appliance can take further actions, such as deciding whether to allow, block, or modify the client request or its response. HTTP callouts are useful in scenarios like querying a database or a web service to validate user credentials, obtaining external information for decisions, or applying dynamic rules.

Common Use Cases:

1. Authentication and Authorization:

   • You can make a callout to an external server to check if a user is authorized based on session information, cookies, or headers. The NetScaler processes this data and decides whether to allow or block the request.

2. Dynamic Content Handling:

   • The callout can fetch data from external sources like databases, web services, or APIs. For example, if you want to dynamically redirect users based on external data, the callout can fetch that data and apply it in a rewrite or responder policy.

3. Geo-location or IP Intelligence:

   • The HTTP callout can check the client’s IP address or any header against an external IP intelligence service to determine if it’s from a suspicious region, and NetScaler can take appropriate actions based on the response.

How It Works:

1. Callout Definition:

   • You first define an HTTP callout on the NetScaler by specifying the external server’s details, including the URL, HTTP method (GET, POST, etc.), and any headers or parameters that should be included in the call.

2. Binding to Policies:

   • The callout is then bound to responder, rewrite, or content switching policies. When a request or response is processed by the NetScaler, the callout makes the external request.

3. Response Handling:

   • Based on the result returned from the external server (e.g., a JSON response or status code), NetScaler can take appropriate action. For instance, it might block, allow, redirect, or rewrite the traffic.

Example Scenario:

Let’s say you want to block certain users based on a list of banned IPs stored on an external server.

1. You create an HTTP callout to the external server, which checks if the client’s IP is on the banned list.
2. The callout sends the client’s IP to the external server.
3. Based on the response (e.g., “allowed” or “banned”), NetScaler takes action. If “banned,” it might use a responder policy to block the traffic or display an error page.

Configuration Steps:

1. Create an HTTP Callout:

   1	add policy httpCallout <callout_name> -IPAddress <external_server_ip> -port <port_number> -hostExpr <server_hostname> -urlStemExpr "/check_ip" -httpMethod GET -fullReqExpr "HTTP.REQ.HEADER(\"client-ip\")"

2. Bind it to a policy:

   1 2	add responder policy <policy_name> "HTTP.REQ.HOSTNAME.EQ(\"example.com\")" RESET bind responder policy <policy_name> -callout <callout_name>

This example would send the client IP to the external server via the HTTP callout, and based on the result (e.g., IP is banned), NetScaler could block or allow the request.

Benefits of HTTP Callouts:

• Flexibility to integrate with external services.
• Customization of traffic handling based on dynamic external data.
• Extend functionality beyond the standard static policies in Citrix ADC.

General Questions on Advanced Policies

Q: Can multiple NetScaler Gateway vServers be deployed behind a single Content Switching vServer?

A: Content Switching is not supported for integration with NetScaler Gateway till NetScaler version 10.5. However, in NetScaler 11.0 the situation changes when using NetScaler with Unified Gateway, which allows using Content Switching. Also, only one NetScaler Gateway can be configured behind a Content Switching vServer. For more information refer to Citrix Documentation - Configuring Unified Gateway.

Q: How does Content Switching handle incoming requests if a Load Balancing vServer is down?

A: CS vServers have multiple policies, each policy directing to a LB vServer. When a request matches a specific policy, the traffic is forwarded to the LB, regardless of the state of the LB (even if the LB is “Out of Service”).

To prevent this from happening, enable the “State Update” in the following path:  Content Switching -> vServer -> Traffic Settings. If you check State Update, the Content Switching (CS) server won’t forward to a LB which is DOWN. The CS won’t continue to evaluate policies once it has hit a policy that matches your criteria, regardless of the state of the vServer.

Q: How does “State Update” under Traffic Settings on a Content Switching vServer work?

A: When State Update is disabled: The status of the content switching virtual server is marked as UP. It remains UP even if there is no bound load balancing virtual server that is UP.

When State Update is enabled: When you add a new Content Switching virtual server, initially, its status is shown as DOWN. When you bind a Load Balancing virtual server whose status is UP, the status of the content switching virtual server becomes UP.If more than one Load Balancing virtual server is bound and if one of them is specified as the default, the status of the Content Switching virtual server reflects the status of the default load balancing virtual server. If more than one Load Balancing virtual server is bound without any of them being specified as the default, the status of the Content Switching virtual server is marked UP only if all the bound load balancing virtual servers are UP.

Source