We currently run our openLDAP service on our campus behind an F5 load balancer which preserves the IP address of the connecting client through to the backend servers, which we rely on for a small amount of IP address based authorization differentiating between on-campus and off-campus access.
However, management is strongly pushing us to migrate the service to the Amazon cloud, using Amazon's load balancer. Unfortunately, Amazon's load balancer only supports client NAT for directing connections to the back end servers, so they have no idea who the actual client is, it just appears to be the load balancer itself.
Amazon's solution for that is to support HAProxy's proxy protocol in their load balancer:
https://www.haproxy.com/blog/haproxy/proxy-protocol/
Basically, this is an in band signaling mechanism that inserts an additional header in the initial connection data containing the original client IP address/source port and destination IP address/source port, allowing the server to utilize that information for the connection rather than the actual details of the network connection from the proxy itself.
This requires support from the application running on the server, as it must remove and process that proxy header from the connection data before moving on with whatever data would normally be passed on the connection.
There are some fair number of services that support this proxy, including of course HAProxy itself, such as the apache web server and the postfix mail server.
openLDAP does not support the protocol, and I was unable to find any past discussion of it.
I was wondering if this feature would be something acceptable for inclusion to openLDAP, or if from an architectural perspective it would be considered undesirable.
In general, I believe applications listening on a specific port are either expecting the proxy protocol header, or not, I do not think it is dynamically determined. As such, from an implementation perspective, my initial thought is that it would be implemented in terms of configuration as an additional URL specified via the -h option, something like "ldapp://" or "ldap_p://", "ldapsp://" or "ldaps_p://" or whatever seems most desirable. A server might listen on the standard ports accepting only proxied connections, or it might listen for normal connections on the standard ports and for proxy connections on alternative ports.
When a connection is accepted on a port marked as requiring the proxy protocol, it would read and process the proxy header to populate the appropriate data structures regarding connection, and then move on as it normally would to deal with the connection.
If this feature is of interest, I will probably spend a little time poking at it and seeing how much trouble it will be to implement.
Thanks…