vADC Docs

IP Transparency: Preserving the Client IP address in Stingray Traffic Manager

by on ‎05-09-2013 03:32 AM - edited on ‎07-08-2015 03:26 PM by PaulWallace (9,283 Views)

Stingray Traffic Manager operates as a full network proxy.  Incoming TCP and UDP traffic is terminated on the traffic manager, and new TCP or UDP sessions are initiated from the traffic manager to the selected target server.

 

This approach has the benefit that Stingray can apply a range of TCP optimizations (such as independent window scaling) and higher-level optimizations (HTTP connection reuse), and it's an architectural necessity for any complex content inspection and rewriting (including compression, SSL decryption and all manner of TrafficScript-based solutions).

 

However, the approach has the side effect that the target servers observe the connection as originating from the Stingray device, not from the remote client.  There are several situations where this may be a problem:

 

  • Security and access control measures that need to observe the source IP address of a connection will not work
  • Access logs will identify the Stingray IP address as the source of the connection, and compliance requirements may mandate that the true origin is recorded

 

There are a number of steps you can take to address problems that arise from this situation.

 

Offload the task that requires the IP address on to the Stingray device

 

In many cases, it's possible to move the task that requires access to the IP address from the back-end servers and deploy it on the traffic manager instead:

 

  • Access Logging: Stingray provides full webserver-style access logging.  Another advantage of logging transactions on Stingray rather than the webserver cluster is that you don't need to worry about merging log files from multiple servers
  • Security: You can implement a range of IP-based security measures on Stingray, such as Checking IP addresses against a DNS blacklist with Stingray Traffic Manager

 

Modify the behavior of the Server Application

 

When Stingray manages an HTTP connection, it adds an X-Cluster-Client-Ip header to the request that identifies the true source address. A web based application that wishes to know the source address of the connection could inspect the value of this header instead.

 

For example, if you are logging transactions using the common log format in a server such as Apache:

 

LogFormat "%h %l %u %t \"%r\" %>s %b"

 

... you can replace the %h macro with a macro that records the value of the custom header that Stingray inserts:

 

LogFormat "%{X-Cluster-Client-Ip} %l %u %t \"%r\" %>s %b"

 

If you are using Apache, you should consider using the mod_remoteip - Apache HTTP Server module (thanks to Julian Midgley for the following).  Enable it as follows:

 

LoadModule remoteip_module modules/mod_remoteip.so

RemoteIPHeader X-Cluster-Client-Ip

RemoteIPTrustedProxy 1.2.3.4

 

... where 1.2.3.4 is the trusted source of the traffic (i.e. the IP address of the Stingray device).  If you want to trust the header even if it points to a private IP (e.g. 192.168.0.1), then use RemoteIPInternalProxy instead of RemoteIPTrustedProxy.

 

Note that Apache will continue to log the Stingray IP address when using %h in the log file; replace this with %a to get the client IP address.

 

If you're using iPlanet, SunONE or a related webserver, you can look at this alternative: Preserving the Client IP address to iPlanet/SunONE/Sun Java System Web Server servers and apps.

 

Use Stingray's IP Transparency Feature

 

Stingray's IP Transparency Feature is used to rewrite the source IP address in the server-side connection so that the TCP and UDP traffic appears to originate from the remote client.

 

It is a very effective solution, but it requires careful network configuration and it incurs an additional workload on the Stingray host because it needs to maintain a large NAT table for the rewritten connections.

 

On the Stingray Virtual Appliance, the ztrans kernel module that provides IP Transparency is pre-installed; if you are using the Stingray software on a Linux host, you will need to install the Stingray Kernel Modules for Linux Software.  The feature is not available for Solaris.

 

Once installed, you enable IP Transparency on a per-pool basis:

 

Screen Shot 2013-05-09 at 11.21.32.png

 

Please refer to the Stingray Product Documentation for more information.

 

Read more

 

Contributors