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:
There are a number of steps you can take to address problems that arise from this situation.
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:
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.
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:
Please refer to the Stingray Product Documentation for more information.