How can I obtain the original client IP address? All connections from Total Uptime come from the same few IP addresses

NOTE: This article covers obtaining the original client IP for logging purposes. If you need to obtain it for use in your code, check out this article.

Because the Total Uptime ADC-as-a-Service acts as a proxy between the client and your device or server(s), you will no longer see the client’s IP address but one of our cloud node IP addresses instead (not the IP you published your config on either, one of the IPs linked on the dashboard).

This is by design because it allows essential return traffic to come back through to our network to a) complete a 3-way TCP handshake, b) properly cloak your server, and c) to monitor session and connection state. If you require the client IP for logging, filtering, authentication or other purposes, consider the easiest and industry-standard option below.

CLIENT IP HEADER (X-FORWARDED-FOR)

We can pass through the original client IP address by inserting it into the HTTP header request passed from the client to your server(s). The web server may be modified to read the X-Forwarded-For header and write the Client IP address in the appropriate environment variable or Web server data structure. For example, it is possible to insert an ISAPI filter into IIS to read the Client IP from the HTTP header and write this client IP into the appropriate field in a data structure. Downstream server software (for example, the logging module) would then access the Client IP from this Request Object. As another example, an Apache module may be linked into an Apache Web server to write the Client IP into an environment variable, which is accessed by a downstream process.

There are three limitations to keep in mind.

a) This only works with HTTP traffic (and SSL, see c). It cannot work with TCP, FTP, UDP or anything else. Sorry : (

b) We require that the downstream web server read the X-Forwarded-For on a per GET basis rather than on a per connection basis. Usually the client IP address remains constant once a connection is established and as a result the downstream server might read and remember the client IP for the duration of the connection. But to be on the safe side, the server should look at the X-Forwarded-For on each GET to be certain it has not changed.

c) The only way to insert the X-Forwarded-For into the header of an SSL session is for us to decrypt it and re-encrypt it. If you use SSL PROXY mode to pass SSL traffic through the Cloud Load Balancer to your server(s), you will need to change this to regular SSL mode which requires that you upload an SSL certificate and assign it to your ALF Pack configuration.

Configuring the Pass-Through Client IP Header
To configure the IP address pass-through header, log into the management portal and edit your device(s). In the settings dialog, you will see the “Use client IP header” option. Enable it and then specify a header name. “X-Forwarded-For” is our recommendation, but sometimes it can be something else, depending on your web server. In our examples, we will use “X-Forwarded-For”.

That’s about it! check out this article

Retrieving the Client IP Header for logging purposes

Sometimes you may wish to obtain the Client IP for logging purposes. It is important to note that if you use a third party analytics solution, such as Google Analytics, you don’t need to do anything. Their javascript-based include will capture the visitor’s IP without issue since it is out-of-band.

If you use IIS, Apache or something similar and want your local server logs to contain the original Client IP, you can retrieve the X-Forwarded-For you enabled above by following one of these articles below. These are rarely used, and these articles are now quite outdated, but maybe it will point you in the right direction.

Apache 2.0 and 2.2: Please follow the steps in this knowledge base article.

IIS 6 or lower: Please follow the steps in this knowledge base article.

IIS 7.0 or 7.5 on Windows 2008: Please follow the steps in this knowledge base article.

NGINX: See the HttpRealipModule on the NGINX WIKI

I don’t want any of that, I just want the source IP to be the actual source IP of the traffic!

Sometimes nothing above solves the issue. Perhaps you’re running a FTP, SFTP or some other TCP or UDP based application where having the original client source IP is the only solution you will accept. In this case, contact us. It is possible for us to send the source IP, but it is an extremely complex setup and generally will require an IPSEC VPN between one or more Total Uptime POPs and your network plus it will require that you gateway the traffic back to us to properly complete the path OR (if you have a very advanced firewall that supports it), ensure that traffic arriving via our VPN to you returns back to the same VPN regardless of the source IP. Again, contact us, we will need to discuss your technical capabilities here.

Consider BGP over GRE as an Option

One last option you may want to consider if high availability is critical, but you do not necessarily need load balancing or can handle load balancing in-house. You could simply use BGP over GRE where you can still use a Total Uptime public IP, but we route the IP across a GRE tunnel (or IPSEC tunnel or both) to your site. With this concept all traffic would contain the source IP as you expect, and you actually handle the NAT on your device and routing and load balancing to the appropriate servers at the site just like you would any other WAN IP or IP block provided by an ISP.

For high availability, we can create multiple tunnels to the same site over two different ISPs, or we can configure a tunnel to another site for DR purposes too where you can control the BGP announcement and failover. Again, this is a more complex config, so contact us for some further discussion. I’m sure we can come up with a solution for you.