Responder

Responder: 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.

Responder supports protocols such as TCP, DNS (UDP), and HTTP. With responder enabled on your appliance, server responses can be based on who sends the request, where it is sent from, and other criteria with security and system management implications. The feature is simple and quick to use. By avoiding the invocation of more complex features, it reduces CPU cycles and time spent in handling requests that do not require complex processing.

Using Responder, we can also direct users to different websites on the fly, or respond with a maintenance page for example. 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.

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.

For handling sensitive data such as financial information, if you want to ensure that the client uses a secure connection to browse a site, you can redirect the request to a secure connection by using https:// instead of http://.

To use a responder, do the following:

• Enable a responder feature on the appliance.
• Configure a responder action. The action can be to generate a custom response, redirect a request to a different webpage, or reset a connection.
• Configure a Responder policy. The policy determines the requests (traffic) on which an action has to be taken.
• Bind each policy to a bind point put it into effect. A bind point refers to an entity at which the Citrix ADC appliance examines the traffic to see if it matches a policy. For example, a bind point can be a load balancing virtual server.

You can specify a default action for requests that do not match any policy, and you can bypass the safety check for actions that would otherwise generate error messages.

Rewrite

The Rewrite feature of Citrix ADC helps in rewriting some information in the requests or responses handled by Citrix ADC. Rewrite refers to the rewriting of some information in the requests or responses handled by the NetScaler appliance. Rewriting can help in providing access to the requested content without exposing unnecessary details about the website’s actual configuration. changing a http site to https, or lets say you created a new site, when users open the old site they should be redirected to new site.

The following section shows some differences between the two features.

Comparison between Rewrite and Responder options

The main difference between the rewrite feature and the responder feature is as follows:

Responder cannot be used for a response or server-based expressions. Responder can be used only for the following scenarios depending on client parameters:

• Redirecting an HTTP request to new websites or webpages
• Responding with some custom response
• Dropping or resetting a connection at the request level

If there is a responder policy, the Citrix ADC examines the request from the client, takes action according to the applicable policies, sends the response to the client, and closes the connection with the client.

If there is a rewrite policy, the Citrix ADC examines the request from the client or response from the server, takes action according to the applicable policies, and forwards the traffic to the client or the server.

In general, it is recommended to use a responder if you want the appliance to reset or drop a connection based on a request-based parameter. Use a responder to redirect traffic, or respond with custom messages. Use rewrite for manipulating data on HTTP requests and responses.

Source

For more information check out:

URL Rewrite and Responder with Citrix NetScaler – JGSpiers.com

NetScaler Use of Rewrite, Responder and URL transformation | Marius Sandbu

One of the features of the rewrite is adding the path to the existing URL whereas responder redirects the page to a different page/site.

Content Switching:

Content Switching enables the Citrix ADC appliance to direct requests sent to the same Web host to different servers with different content. For example, you can configure the appliance to direct requests for dynamic content (such as URLs with a suffix of .asp, .dll, or .exe) to one server and requests for static content to another server. You can configure the appliance to perform content switching based on TCP/IP headers and payload.

Scenario:

You have a single Netscaler VIP (https://company.com) but servers in the backend host different URL paths ie., server1 hosts /home/Web and server2 hosts only /home. In this case, if you configure load balancing directly, when a request for /home/Web goes to server2, users get an error page as sever2 doesn’t have /home/web page.

We need to create content switching policies and actions and apply them to the same Netscaler VIP.

We can create a content switching policy to display an English language page to one set of users coming from a geographical location and another language page to users coming from another geographical location.

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