Client IP issue over HTTPS - Cloud Load Balancer

There are some points to consider at the moment when configuring a cloud load balancer, in this article we are going to split it in small parts.

SSL termination is not recommended for a Cloud Load Balancer that has external nodes. The types of data in point A should not be passed along to an external node with SSL Termination, and the reason the data is not secure can be seen in point B:

A) Sensitive data classified as Personally Identifiable Information (PII); i.e.

Information protected by the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and Gramm-Leach-Bliley
Credit card information or any data that might result in identity theft if it is disclosed.

B) A load balancer receives a user request and forwards it to the nodes in plain text. When the node processes the request and replies, the load balancer encrypts the data before sending it back to the user. The user perceives the entire transaction as secure due to HTTPS termination. However, during the process, the data, including sensitive customer information, is transmitted unencrypted between the load balancer and the nodes. This exposes the data to potential security breaches, making it vulnerable to interception by sniffers.

Disabling SSL Termination:

via Rackspace Cloud Portal:

Log in to the Cloud Control Panel.
In the top navigation bar, click Select a Product > Rackspace Cloud.
Select Networking > Load Balancers.
Select the desired Load Balancer.
Scroll down to Optional features
*Click on the pencil next to HTTPS Redirect and disable it.

With the API

DELETE /v1.0/{account}/loadbalancers/{loadBalancerId}/ssltermination

Where:
{account} String The ID for the tenant or account in a multi- tenancy cloud.
{loadBalancerId} String The ID for the load balancer.

**Note**: If you are using **Ligjttpd**  to polish up the traffic, in the case that current external node is to far away of the Load balancer region, your users won't feel any positive change, because the distance between the node being balanced and the region of the Load Balancer can impact the performance of the load balancer, to solved this the rule of thumb is choose the region that is geographically closest to the external node.

Example:

It is possible to configure a pool of servers to receive the original client IP address, but this is typically used only for the HTTP protocol. In cloud servers, it is not possible to do this with the HTTPS protocol when the traffic is arriving from a Cloud Load Balancer due to the encryption.

Instead, to achieve this, we can use the X-Forwarded-For (XFF) directive, which identifies the origin IP address of the client connecting to the server.

XFF Header Example Collapse source

create ltm profile http HTTP-XFF insert-xforwarded-for enabled defaults-from http save sys config
list ltm profile http HTTP-XFF

(lb-965415)(cfg-sync In Sync)(Active)(/Common)(tmos)# list ltm profile http HTTP-XFF
ltm profile http HTTP-XFF

{ app-service none defaults-from http insert-xforwarded-for enabled }

(lb-965415)(cfg-sync In Sync)(Active)(/Common)(tmos)#

Finally, the directive X-Forward Proto, helps with SSL offloading within the server, but is not configured in Cloud Load Balancer.

**Note**: At the end of the day, if you still want to see the source IP, is strongly recommended to use Apache.

In the Apache configuration file, this line:

LogFormat "%h %l %u %t \"%r\" %&gt;s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

Should be modified to:

LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %&gt;s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

And also, the Vhost configuration needs to be changed to something as follows:

ServerAdmin [email protected]
DocumentRoot /var/www/html/example.com
ServerName example.com
ErrorLog logs/example.com-error_log
CustomLog logs/example.com-access_log combined

Updated 3 months ago