Support for PROXY protocol (ELB, HAproxy, etc)

[checkmypi]

This is a feature request to add support for ELB proxy protocol

Last year there were few people who expressed interest in this feature.

https://groups.google.com/forum/#!searchin/rabbitmq-users/ELB$20proxy$20protocol/rabbitmq-users/bZbPDrTrnoc/6JcsR3VxC4oJ

More about ELB Proxy Protocol
http://aws.amazon.com/about-aws/whats-new/2013/07/30/elastic-load-balancing-now-supports-proxy-protocol/

Thanks & regards
m

[michaelklishin]

From what I see in the docs, it would require client library modifications. I'm afraid we can't do it for every client library and every protocol we support.

[damoxc]

@michaelklishin It doesn't require any client library modifications, it's only server side in the communication between loadbalancer -> backend, the client -> loadbalancer connection doesn't include any modification in how the connection works. It would prevent a client from directly connecting to the server, although you could delegate how the connection is handled based on the actual source IP of the connection, configure proxy_ips that will then read the proxy header.

[carlhoerberg]

It should be a server option, eg. {proxy_protocol, true}, normal clients should not be able to use the PROXY protocol, only load balancers. If the proxy protocol is enabled no normal client connections should be allowed, that could be a security issue.

[carlhoerberg]

Yes, no client lib modification is required, this is a server-side-only thing. http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt

The server has to be configured to be behind a proxy and then accept the PROXY protocol, otherwise the IP could be spoofed, if any client could connect. From the spec:

The receiver MUST be configured to only receive the protocol described in this
specification and MUST not try to guess whether the protocol header is present
or not. This means that the protocol explicitly prevents port sharing between
public and private access. Otherwise it would open a major security breach by
allowing untrusted parties to spoof their connection addresses. The receiver
SHOULD ensure proper access filtering so that only trusted proxies are allowed
to use this protocol.

(And this is not ELB only, HAProxy, Nginx, Stunnel, Stud etc all implement the PROXY protocol)

[ajwdev]

Has there been anymore discussion about this feature? I think this would be really useful for those of us running Rabbits behind any kind of proxy.

[michaelklishin]

@williamsandrew not on our team. I trust @carlhoerberg's judgement that no client modifications will be necessary. We will consider this for 3.7.x or 3.8.0.

[michaelklishin]

We have a working prototype, looks like this can go into 3.7.0 with little risk (and no delays).

[michaelklishin]

We have contributed a couple of fixes upstream and they were accepted, this is approaching the finish line.

[michaelklishin]

PRs for AMQP 0-9-1, MQTT, STOMP are merged. AMQP 1.0 is left to be done.

[uvzubovs]

I am not skilled with the proxy protocol. Will this work with F5 LTM (local traffic manager, a.k.a. the load balancer/IP-sprayer)?

[jakauppila]

@uvzubovs At a preliminary glance it looks like you can use an iRule on the Virtual Server to implement Proxy Protocol v1; but there isn't anything baked into the appliance to enable the functionality.

[michaelklishin]

At this point the Proxy Protocol is supported by enough popular vendors/projects (from HAproxy and Nginx to AWS ELB) that it's on F5 to add support to their products.

@jakauppila thank you, your input is very helpful as always. May I ask you to share a small example, either here or on rabbitmq-users? :) I'd happily add a note for F5 users to our docs.

[uvzubovs]

How would this work with client auth SSL? Proxy needs to terminate SSL to add client info to the connect frame, but it does not have client's SSL cert when connecting to Rabbit; it will present it's own. Will Rabbit's client auth SSL logic be updated to recognize certain client SSL cert as that of a proxy, and so then get the true client SSL cert name from the client info in the connect frame?

[michaelklishin]

Not all proxies terminate TLS. This protocol sends a bit of data before any other protocol-specific data, at that point TLS upgrade has been completed. The protocol only relays some basic client information such as the real IP address. No certificate information is exchanged and the goal of this issue is to only obtain the real IP address, nothing else.