How to achieve client source IP transparency with your load balancer

Working with our pre-sales customers, there is a misconception that you always need source IP transparency - which is not always the case. Source IP transparency does not affect the client seeing the server, or how the traffic has to be routed. In fact, there are still many flexible ways to route traffic with or without source IP transparency. So a lot of the time, it isn't even needed for any logging. It just sounds like you need to have it.

What is source IP transparency?

So what does it mean if you do not have source IP transparency? It will simply mean, in the logs of the real server, the traffic will appear as though its coming from the load balancer's address as opposed to the client's original IP address. So when the real server is responding to a request, it's being done straight to the load balancer appliance. The load balancer will then forward the traffic back to the client.  

An example of traffic without source IP transparency:

1. The client will connect to the VIP from their IP
2. The virtual service will then connect to the real server
3. Once the real server has the connection, the real server will pass the connection back to the load balancer
4. Finally, the load balancer will pass it back to the client.

In other words......

1. (Client)84.15.184.60 -> (VIP)192.168.90.10
2. (VIP)192.168.90.10 -> (Real server)192.168.90.6
3. (Real server)192.168.90.6 -> (VIP)192.168.90.10
4. (VIP)192.168.90.10 -> (Client)84.15.184.60

As you can see, the real server then only ever talks to the virtual server's IP address.

Do I really need to see the clients source IP?

A simple question to ask yourself is, do you need the IP address of the client requests to appear in the logs?

If no.....you can use a simple layer 7 proxy for most cases, which requires no real server changes and is super easy to set up! You can also use our other methods of load balancing, including layer 4 if you require UDP support. If you're not sure which load balancing method is right for you, we have a handy blog here.

If yes.....then you're in the right place! I've detailed below the range of different ways to achieve source IP transparency on our appliance at both Layer 4 and 7.

Setting up source IP transparency

So, in numerical order, let's start at layer 4 (this also happens to be the simpler method of setting up a source IP transparent deployment!) and use our loadbalancer.org appliance as an example.

Layer 4 DR mode:

So. Layer 4 DR (Direct route) mode. You may have heard this called DSR (Direct server return) or (if you're from F5 land) n-path routing. By default our layer 4 DR mode is source IP transparent and supports TCP and UDP traffic. It is also hugely scalable thanks to the direct return of the traffic from the server bypassing the load balancer. This means your load balancer's network interfaces are being saturated purely by throughput traffic.

We also offer Layer 4 TUN mode which is extremely similar to our layer 4 DR mode, but it works through encapsulated tunnels (similar to L3 n-path routing but it's very niche and often too complex for the majority of deployments I've come across).

As you can see in the above diagram, the direct route comes straight from the application servers back to the switch, bypassing the load balancer on the return.

Layer 4 DR mode will need a layer 4 VIP (Virtual IP) on the load balancer appliance and a loopback adapter to be added on the real server pointing to the VIP address on a /32 network. This is called solving the ARP problem and more information can be found here in our manual.

Layer 4 NAT mode:

Again, NAT mode is source IP transparent by default. This is extra useful if you wish to load balance across different subnets and allow the load balancer to do the Network Address Translation for you. All layer 4 NAT mode needs is the gateway of the real servers to point to a floating IP on the load balancers. This can be the VIP or a separate floating IP.

A floating IP must be used so in case of a failover between Primary and Secondary nodes of the loadbalancer.org appliance, the gateway will also fail over.

You can find out more about NAT mode considerations here.

Layer 7  with X-Forwarded-For headers:

Here is where it gets a bit more complicated. By default our layer 7 method of load balancing is not simply being able to deploy and have source IP address transparency. There are a few things that need to be done to achieve this...

So, you need to use a layer 7 reverse proxy for load balancing, but you still want client source addresses to appear on the real servers. Can you use X-Forwarded-For headers?

1. Firstly, you will need to create a virtual service at layer 7 in HTTP mode.
2. Navigate the WebUI to "Cluster Configuration" -> "Layer 7 Virtual Services" -> Select "Modify" on the virtual service you wish to enable source IP transparency.
3. When on the modify page,  scroll down to the grey bar that says "Other", and selects "Advanced" on the right of that grey bar.
4. Make sure "Set X-forwarded-for header" is enabled.

We then have a few changes to make on the real server i.e. we need to ensure the real server is recording the X-Forwarded-For header.

Here are some handy guides on how to do this so please check out the relevant blog for your server:

Apache: https://www.loadbalancer.org/blog/apache-and-x-forwarded-for-headers/

IIS: https://www.loadbalancer.org/blog/iis-and-x-forwarded-for-header/

NGINX: https://www.loadbalancer.org/blog/nginx-and-x-forwarded-for-header/

Layer 7 Transparent proxy:

Okay, so X-Forwarded-For isn't an option for you? Maybe you're using a legacy app that doesn't support it. No problem: you can still use TPROXY to get real source IP transparency at layer 7. Where our load balancer does not allow layer 7 connections to preserve source IP address transparency, you can achieve it with use of our in-built TPROXY (transparent proxy).

Using the same place as before (in the modify page of the VIP in question), scroll down to the bottom again and press "Advanced" on the "Other" option, and enable to "Transparent proxy" checkbox.

The benefit of transparent proxy is that it can be used in TCP and HTTP mode. TPROXY works by modifying the source address field of the IP packets and replacing the IP address of the load balancer with the IP address of the client.

Layer 7 XFF headers and TPROXY can be used in conjunction with each other or separately. To find out more information and for a more detailed explanation of transparency at layer 7 please read this page of our manual.

If you have set up anything I have spoken about in this blog, and you are experiencing problems or have any questions, please contact support@loadbalancer.org or leave a comment below.