Client IP issue address over https with Rackspace Cloud Load Balancers

Question

We're currently using Lighttpd with FastCGI to serve PHP to our clients. We recently added load balancing through RackSpace Cloud to help us handle our traffic however, the client's IP is now the load balancer IP. All traffic is through HTTPS.

We've enabled mod_extforward and have tried all different configuration for with using our LB IP and the different headers ("X-Forwarded-For","Forwarded-For","X-Cluster-Client-Ip") and we cannot seem to get this to work!

Any ideas? Thank you!

Fragrant

So your question is "In which header RackSpace Cloud sends the client IP?" Should be "X-Forwarded-For", but why not simply dump the headers and look for yourself. – Thrips

I'm not exactly sure how to do this. Any help there? – Fragrant

You already tried looking at the output of phpinfo() for your IP address? Under PHP 5.4 you could use getallheaders(), for earlier versions the easiest way is probably using tcpdump -s 2000 -w dump and then throwing this dump into Wireshark. – Thrips

Thanks for the help. We ended deploying our own load balancing instead of using RackSpace and had the issue solved. For what it's worth, their support closed our ticket and wouldn't help us. :( – Fragrant

have you tried configuring true-client-ip? – Pictogram

Answer 1

If you're using Rackspace's Cloud Load Balancers, you won't be able to get the client's IP address over SSL.

For plain HTTP, the balancers can do intelligent things (the "service unavailable" page, X-Forwarded-for, etc.) However, the load balancers can't do anything other than ferry bytes between the client and server over HTTPS, because, without the private key, there's no way to modify the stream (other than making it invalid.)

Someone asked this question on the Rackspace forums a little while ago.

Sal

That question link is now broken, unfortunately – Slunk

Answer 2

According to Rackspace, SSL Termination should not be used if your web application is transmitting Personal Identifiable Information (PII)

http://www.rackspace.com/knowledge_center/product-faq/cloud-load-balancers

I'm having to resort to setting the client's IP in a cookie. The cookie is set in javascript. The client's IP is obtained by making a jsonp call to a server (not behind a load balancer) that provide's the client's public IP. This is all I can think of where I can still utilize Rackspace's Cloud Load Balancer.

Serosa

This is not a legal disclaimer, but advice. If the unecrypted traffic is going through Rackspace's internal network only, it is pretty secure. According to Rackspace; """Aaron M (26/01/2017, 14:20:29): You would not have to worry about the traffic, the interfaces are configured to not allow packet sniffing/capturing from the hypervisor level so it wouldn't be possible to capture from another server """ – Mizuki

Answer 3

Rackspace added SSL termination, so you can have the load balancer decrypt the traffic and pass the unencrypted traffic to its server nodes. See this for more info. Course, this means that you're sending traffic over what is effectively a public link from the load balancer to your web servers. And, its only available via their API and not the web console, which sucks.

Singlebreasted

Answer 4

You can actually see here:

http://www.rackspace.com/knowledge_center/article/why-does-every-visitor-to-my-cloud-sites-website-have-the-same-ip-address

The correct PHP variable to utilize for SSL is:

$_SERVER['HTTP_X_FORWARDED_FOR']

Cue

Answer 5

I install mod_rpaf for servers under load balancers and Rackspace. Then any PHP code just works the same as before with REMOTE_ADDR

Yi

Link? Example config? Why/how it solves the problem? – Webfoot

mod_rpaf can be easily configured in Apache 2.2 to rewrite REMOTE_ADDR based on the value of X-Forwarded-For or another HTTP header. That will then cause both standard logs as well as interpreters like PHP to receive a corrected REMOTE_ADDR with the client's IP rather than the load balancer's IP. In Apache 2.4, the standard mod_remoteip module does a similar job. – Carrie

Answer 6

One way i found to solve this problem is to use CloudFlare . Beyond all the additional features and benefits it provides, it actually is a proxy itself and will include its own x-forwarded-for header.

This bypasses the problem because the x-forwarded-for header is already present before it gets to the rackspace load balancer, so it doesn't need to add anything. The clients IP address will already be in the header.

Please note: This method is not totally foolproof, even with a list of trusted proxies. It is possible to spoof your IP address by modifying your computer's host file and bypassing cloudflare, connecting to the load balancer directly. I would not use this technique for anything that requires high security.

Myrica