7

From experimenting with Azure load-balancing set, it seems that x-forwarded-for header is not used (as it would be expected in regular load-balancer), rather they preserve the original client IP.

E.g.:

app.get('/my-ip', function(req, res) {
    winston.log('/my-ip', 'x-forwarded', req.headers['x-forwarded-for'] || 'none', 'remoteAddress', req.connection.remoteAddress || 'none');
    res.end();
});

With the result:

/my-ip x-forwarded none remoteAddress MY_CORRECT_IP

Can this behavior be confirmed and relied upon?

SyBer
  • 5,407
  • 13
  • 55
  • 64
  • // , What research did you do before posting this question? The fourth result here seems to explain that it does: https://duckduckgo.com/?q=does+azure+lb+preserve+ip+address&t=h_&ia=web `When the flow arrives on the virtual machine, the original source IP address is also preserved.` – Nathan Basanese Oct 15 '18 at 21:27

1 Answers1

14

You are confusing proxies with load balancing. Proxies use x-forwarded, load balancers do not (by default). Load balancers work at a lower level in the OSI stack (although you might find all kinds of things calling themselves load balancers that really aren't).

The key difference here is that a proxy actually interprets your HTTP request, typically caching it in the process, before forwarding it with it's altered headers. A load balancer doesn't have to (though it can). They just re-route packets. Some more advanced load balancers support adding this header, but it's never the default configuration. Proxies typically have this header on by default, and support removing it.

The reason load balancers don't typically need this header is that a load balancer is basically a router, as such it maintains the original source ip information of the packets by default. A proxy, on the other hand acts as destination for the original request, then it issues a new request to the new destination, thus the original packet information is typically lost. Like, if you worked at a mail forwarding facility, and you opened peoples mail, read it, then put it in a new envelope with your return address.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
  • +1 It's not a proxy. Here's some additional useful information: https://azure.microsoft.com/en-us/documentation/articles/load-balancer-overview/ – Mårten Wikström Jun 02 '15 at 05:05
  • Thanks for the clarification, I got used to Amazon ELB where it does use x-forwarded – SyBer Jun 02 '15 at 15:03
  • @SyBer - Amazon ELB only uses X-Forwarded-for when you configure the load balance to translate between different types of protocols.. for instance, HTTPS to HTTP. See: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html "When you use TCP (layer 4) for both front-end and back-end connections, your load balancer forwards the request to the back-end instances without modifying the headers." and then "Using this configuration, you will not receive cookies for session stickiness or the X-Forwarded headers.", or if you enable it explicitly. – Erik Funkenbusch Jun 02 '15 at 15:12
  • 1
    @Erik Funkenbusch Note though - the TCP forwarding with AWS is not a direct comparison in this case since it is _still_ a proxy, it's just acting as a port forwarder in that case. You _still_ lose the originating IP in both cases w/ AWS ELB unless you configure and use the PROXY protocol support, which requires support in your backend. – Nathan Neulinger Oct 21 '16 at 14:51