Re: HAProxy proxy protocol support

[Paul B. Henson]

On 12/22/2020 2:19 AM, Ondřej Kuzník wrote:

Thanks so much for working on this and sorry haven't had much time to
give it a proper look yet. Will test a bit and review the load balancer
side properly in the new year. A brief look found only some formatting
(whitespace) inconsistencies so far.


Cool, thanks for the update. No rush, don't mean to be pushy :), just 
wanted to make sure it didn't fall through the cracks. Happy holidays as 
well, and looking forward to following up with you next year, thanks…

Re: HAProxy proxy protocol support

[Ondřej Kuzník]

On Mon, Dec 21, 2020 at 08:41:26PM -0800, Paul B. Henson wrote:
> Haven't heard anything on my pull request since my last update:
> 
>   https://git.openldap.org/openldap/openldap/-/merge_requests/209
> 
> Just wanted to touch base and see if there was anything else in need of
> fixing/changing with it.

Hi Paul,
Thanks so much for working on this and sorry haven't had much time to
give it a proper look yet. Will test a bit and review the load balancer
side properly in the new year. A brief look found only some formatting
(whitespace) inconsistencies so far.

Thanks again and wishing you nice holidays,

-- 
Ondřej Kuzník
Senior Software Engineer
Symas Corporation   http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP

Re: HAProxy proxy protocol support

[Paul B. Henson]

Haven't heard anything on my pull request since my last update:

https://git.openldap.org/openldap/openldap/-/merge_requests/209

Just wanted to touch base and see if there was anything else in need of
fixing/changing with it.

Thanks...

Re: HAProxy proxy protocol support

[Paul B. Henson]

On Sat, Dec 05, 2020 at 02:44:12PM -0800, Quanah Gibson-Mount wrote:

> Also looks like I need to make further edits to the devel page on 
> submissions, since this info is at the very bottom, and outdated info 
> preceeds it.

Ah, yah; I just saw the part about submitting patches in git
format-patch format :).

Merge request submitted, thanks...

Re: HAProxy proxy protocol support

[Quanah Gibson-Mount]

--On Saturday, December 5, 2020 2:40 PM -0800 Quanah Gibson-Mount 
 wrote:



I'd like to backport this to OPENLDAP_REL_ENG_2_4 if/when it's accepted,
hopefully that will be ok.



Also looks like I need to make further edits to the devel page on 
submissions, since this info is at the very bottom, and outdated info 
preceeds it.


--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: HAProxy proxy protocol support

[Quanah Gibson-Mount]

--On Friday, December 4, 2020 5:08 PM -0800 "Paul B. Henson" 
 wrote:



I've attached my first pass at adding proxy protocol support to slapd. I
haven't updated any documentation/man pages yet, I'll start taking a
look at that while you all eviscerate my code and let me know what needs
to be fixed before merging :).

I'd like to backport this to OPENLDAP_REL_ENG_2_4 if/when it's accepted,
hopefully that will be ok.


You should:

a) sign up for an account in gitlab if you haven't already: 
https://git.openldap.org


b) fork the master OpenLDAP repo

c) Create a development branch in your fork, generally named after the ITS. 
I.e.: git clone -b its# master


d) Apply your patch

e) Submit a merge request for review.  You can mark it WIP if you feel like 
it may need additional work and is not yet ready for integration.


Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: HAProxy proxy protocol support

[Paul B. Henson]

I've attached my first pass at adding proxy protocol support to slapd. I
haven't updated any documentation/man pages yet, I'll start taking a
look at that while you all eviscerate my code and let me know what needs
to be fixed before merging :).

I'd like to backport this to OPENLDAP_REL_ENG_2_4 if/when it's accepted,
hopefully that will be ok.

Thanks...
>From b35e7b6ec736f4ad0ed6c1774482b34aed4eac33 Mon Sep 17 00:00:00 2001
From: "Paul B. Henson" 
Date: Fri, 4 Dec 2020 16:59:48 -0800
Subject: [PATCH] Add support for HAProxy proxy protocol v2

---
 include/ldap_pvt.h   |   3 +
 libraries/libldap/ldap-int.h |   4 +
 libraries/libldap/url.c  |  42 +++--
 servers/lloadd/daemon.c  |   2 +
 servers/lloadd/lload.h   |   1 +
 servers/slapd/Makefile.in|   4 +-
 servers/slapd/daemon.c   |  11 +++
 servers/slapd/proxyp.c   | 159 +++
 servers/slapd/proxyp.h   |  21 +
 servers/slapd/slap.h |   1 +
 10 files changed, 239 insertions(+), 9 deletions(-)
 create mode 100644 servers/slapd/proxyp.c
 create mode 100644 servers/slapd/proxyp.h

diff --git a/include/ldap_pvt.h b/include/ldap_pvt.h
index 01220d00a..54f9a13d4 100644
--- a/include/ldap_pvt.h
+++ b/include/ldap_pvt.h
@@ -32,6 +32,9 @@ ldap_pvt_url_scheme2proto LDAP_P((
 LDAP_F ( int )
 ldap_pvt_url_scheme2tls LDAP_P((
 	const char * ));
+LDAP_F ( int )
+ldap_pvt_url_scheme2proxied LDAP_P((
+	const char * ));
 
 LDAP_F ( int )
 ldap_pvt_url_scheme_port LDAP_P((
diff --git a/libraries/libldap/ldap-int.h b/libraries/libldap/ldap-int.h
index db019f4b7..c8adbc1c6 100644
--- a/libraries/libldap/ldap-int.h
+++ b/libraries/libldap/ldap-int.h
@@ -123,8 +123,12 @@ LDAP_BEGIN_DECL
 
 #define LDAP_URL_PREFIX "ldap://";
 #define LDAP_URL_PREFIX_LEN STRLENOF(LDAP_URL_PREFIX)
+#define PLDAP_URL_PREFIX"pldap://";
+#define PLDAP_URL_PREFIX_LENSTRLENOF(PLDAP_URL_PREFIX)
 #define LDAPS_URL_PREFIX	"ldaps://"
 #define LDAPS_URL_PREFIX_LEN	STRLENOF(LDAPS_URL_PREFIX)
+#define PLDAPS_URL_PREFIX	"pldaps://"
+#define PLDAPS_URL_PREFIX_LEN	STRLENOF(PLDAPS_URL_PREFIX)
 #define LDAPI_URL_PREFIX	"ldapi://"
 #define LDAPI_URL_PREFIX_LEN	STRLENOF(LDAPI_URL_PREFIX)
 #ifdef LDAP_CONNECTIONLESS
diff --git a/libraries/libldap/url.c b/libraries/libldap/url.c
index a84935e78..858613c13 100644
--- a/libraries/libldap/url.c
+++ b/libraries/libldap/url.c
@@ -20,7 +20,7 @@
 
 /*
  *  LDAP URLs look like this:
- *ldap[is]://host[:port][/[dn[?[attributes][?[scope][?[filter][?exts]]
+ *[p]ldap[is]://host[:port][/[dn[?[attributes][?[scope][?[filter][?exts]]
  *
  *  where:
  *   attributes is a comma separated list
@@ -59,7 +59,7 @@ int ldap_pvt_url_scheme2proto( const char *scheme )
 		return -1;
 	}
 
-	if( strcmp("ldap", scheme) == 0 ) {
+	if( strcmp("ldap", scheme) == 0 || strcmp("pldap", scheme) == 0 ) {
 		return LDAP_PROTO_TCP;
 	}
 
@@ -67,7 +67,7 @@ int ldap_pvt_url_scheme2proto( const char *scheme )
 		return LDAP_PROTO_IPC;
 	}
 
-	if( strcmp("ldaps", scheme) == 0 ) {
+	if( strcmp("ldaps", scheme) == 0 || strcmp("pldaps", scheme) == 0 ) {
 		return LDAP_PROTO_TCP;
 	}
 #ifdef LDAP_CONNECTIONLESS
@@ -86,7 +86,7 @@ int ldap_pvt_url_scheme_port( const char *scheme, int port )
 	if( port ) return port;
 	if( scheme == NULL ) return port;
 
-	if( strcmp("ldap", scheme) == 0 ) {
+	if( strcmp("ldap", scheme) == 0 || strcmp("ldap", scheme) == 0 ) {
 		return LDAP_PORT;
 	}
 
@@ -94,7 +94,7 @@ int ldap_pvt_url_scheme_port( const char *scheme, int port )
 		return -1;
 	}
 
-	if( strcmp("ldaps", scheme) == 0 ) {
+	if( strcmp("ldaps", scheme) == 0 || strcmp("pldaps", scheme) == 0 ) {
 		return LDAPS_PORT;
 	}
 
@@ -116,7 +116,19 @@ ldap_pvt_url_scheme2tls( const char *scheme )
 		return -1;
 	}
 
-	return strcmp("ldaps", scheme) == 0;
+	return strcmp("ldaps", scheme) == 0 || strcmp("pldaps", scheme) == 0;
+}
+
+int
+ldap_pvt_url_scheme2proxied( const char *scheme )
+{
+	assert( scheme != NULL );
+
+	if( scheme == NULL ) {
+		return -1;
+	}
+
+	return strcmp("pldap", scheme) == 0 || strcmp("pldaps", scheme) == 0;
 }
 
 int
@@ -150,7 +162,7 @@ ldap_is_ldaps_url( LDAP_CONST char *url )
 		return 0;
 	}
 
-	return strcmp(scheme, "ldaps") == 0;
+	return strcmp(scheme, "ldaps") == 0 || strcmp(scheme, "pldaps");
 }
 
 int
@@ -228,6 +240,14 @@ skip_url_prefix(
 		return( p );
 	}
 
+	/* check for "pldap://"; prefix */
+	if ( strncasecmp( p, PLDAP_URL_PREFIX, PLDAP_URL_PREFIX_LEN ) == 0 ) {
+		/* skip over "pldap://"; prefix and return success */
+		p += PLDAP_URL_PREFIX_LEN;
+		*scheme = "pldap";
+		return( p );
+	}
+
 	/* check for "ldaps://" prefix */
 	if ( strncasecmp( p, LDAPS_URL_PREFIX, LDAPS_URL_PREFIX_LEN ) == 0 ) {
 		/* skip over "ldaps://" prefix and return success */
@@ -236,6 +256,14 @@ skip_url_prefix(
 		return( p );
 	}
 
+	/* check for "pldaps://" prefix */
+	if ( strncasecmp( p, PLDAPS_URL_PREFIX, PLDAPS_URL_PREFIX_LEN ) == 0 ) {
+		/* skip over "pldaps://" prefix and return su

Re: HAProxy proxy protocol support

[Ozgur]

  20.11.2020, 23:11, "Paul B. Henson" :On 11/20/2020 4:52 AM, Howard Chu wrote: client and the proxy server. But nobody says the proxy server can't talk to the backend server using its own TLS session. Unless you can point out anywhere in the HAproxy spec that explicitly forbids this.Eee I don't think it explicitly forbids it, but that's just nothow it says the protocol works :). Hello, obviously you can be set Haproxy as a reverse proxy. ın this case all TLS communication and SSL termination is provided with background OpenLDAP server. The proxy server will only act as a reverse-proxy. You can also provide this with Nginx, set TCP mode and configuring Haproxy will only have reverse proxy. For example: frontend ldaps    bind *:636    option tcplog    mode tcp    default_backend ldapserver    backend ldapserver    mode tcp    balance roundrobin    option ssl-hello-chk    server ldap1 10.10.10.2:636 check    server ldap2 10.10.10.3:636 check backup "Another approach consists in prepending each connection with a headerreportingthe characteristics of the other side's connection. This method issimpler toimplement, does not require any protocol-specific knowledge on eitherside, andcompletely fits the purpose since what is desired precisely is to know theother side's connection endpoints. It is easy to perform for the sender(justsend a short header once the connection is established) and to parse for thereceiver (simply perform one read() on the incoming connection to fill inaddresses after an accept). The protocol used to carry connectioninformationacross proxies was thus called the PROXY protocol."The intention is to be "simple", not require any "protocol specificknowledge" (such as whether or not the connection being proxied usesTLS), and is implemented as "just send a short header", which doesn'texplicitly forbid doing a bunch of other stuff, but that's not what isspecified.Another excerpt:"In both cases, the protocol simply consists in an easily parsableheader placedby the connection initiator at the beginning of each connection. Theprotocolis intentionally stateless in that it does not expect the sender to wait forthe receiver before sending the header, nor the receiver to sendanything back."Negotiating its own TLS session would not be stateless…

Re: HAProxy proxy protocol support

[Paul B. Henson]

On 11/20/2020 4:52 AM, Howard Chu wrote:

client and the proxy server. But nobody says the proxy server can't
talk to the backend server using its own TLS session. Unless you can
point out anywhere in the HAproxy spec that explicitly forbids this.


Eee I don't think it explicitly forbids it, but that's just not
how it says the protocol works :).

"Another approach consists in prepending each connection with a header
reporting
the characteristics of the other side's connection. This method is
simpler to
implement, does not require any protocol-specific knowledge on either
side, and
completely fits the purpose since what is desired precisely is to know the
other side's connection endpoints. It is easy to perform for the sender
(just
send a short header once the connection is established) and to parse for the
receiver (simply perform one read() on the incoming connection to fill in
addresses after an accept). The protocol used to carry connection
information
across proxies was thus called the PROXY protocol."

The intention is to be "simple", not require any "protocol specific 
knowledge" (such as whether or not the connection being proxied uses 
TLS), and is implemented as "just send a short header", which doesn't 
explicitly forbid doing a bunch of other stuff, but that's not what is 
specified.


Another excerpt:

"In both cases, the protocol simply consists in an easily parsable 
header placed
by the connection initiator at the beginning of each connection. The 
protocol

is intentionally stateless in that it does not expect the sender to wait for
the receiver before sending the header, nor the receiver to send 
anything back."


Negotiating its own TLS session would not be stateless…

Re: HAProxy proxy protocol support

[Michael Ströder]

On 11/20/20 1:52 PM, Howard Chu wrote:
> Paul B. Henson wrote:
>> On 11/19/2020 1:37 PM, Howard Chu wrote:
>>
>>> This would require that you actually read and process the proxy header
>>> immediately after the accept call. It strikes me that this is the wrong
>>> thing to do, if you also want to support TLS.
>>
>> Unless I'm misunderstanding the specification, that is the only way it would 
>> work. The TLS negotiation, barring TLS interception by the proxy, is between 
>> the
>> client and the backend server, not between the proxy and the backend server.
> 
> Yes, I understand that any TLS session initiated by the client is only 
> between the
> client and the proxy server.

No, this is not necessarily the case. HA proxy can act as
application-level proxy for some protocols (IIRC HTTP and SMTP) or as a
TCP relay.

Paul mentioned the latter case where slapd is the TLS server end-point
also from the client's perspective and HA proxy does *not* break up TLS
connection.

Ciao, Michael.

Re: HAProxy proxy protocol support

[Howard Chu]

Paul B. Henson wrote:
> On 11/19/2020 1:37 PM, Howard Chu wrote:
> 
>> This would require that you actually read and process the proxy header
>> immediately after the accept call. It strikes me that this is the wrong
>> thing to do, if you also want to support TLS.
> 
> Unless I'm misunderstanding the specification, that is the only way it would 
> work. The TLS negotiation, barring TLS interception by the proxy, is between 
> the
> client and the backend server, not between the proxy and the backend server.

Yes, I understand that any TLS session initiated by the client is only between 
the
client and the proxy server. But nobody says the proxy server can't talk to the
backend server using its own TLS session. Unless you can point out anywhere in
the HAproxy spec that explicitly forbids this.

> This does seem to make it susceptible to man in the middle attacks where 
> someone could swap out the proxy protocol data, but I think the general 
> assumption is
> that the connection between the proxy/load balancer and the backend server is 
> within a trusted network where such an attack is not a concern.

This assumption is not wise.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: HAProxy proxy protocol support

[Paul B. Henson]

On 11/19/2020 1:37 PM, Howard Chu wrote:


This would require that you actually read and process the proxy header
immediately after the accept call. It strikes me that this is the wrong
thing to do, if you also want to support TLS.


Unless I'm misunderstanding the specification, that is the only way it 
would work. The TLS negotiation, barring TLS interception by the proxy, 
is between the client and the backend server, not between the proxy and 
the backend server. The proxy would have no way to inject encrypted data 
into that communication. The "proxy" protocol is also used not just for 
application level proxies, but also for basic network level 
load-balancing. Those systems have no idea if TLS is in use are not, 
they are just shuffling packets back and forth between two endpoints, so 
again would have no way to insert encrypted data into the TLS layer.


The proxy protocol data is always shimmed in at the very beginning of 
the connection before the initial data supplied by the client, the 
server sucks it out and then passes the client data and the rest of the 
connection traffic to the protocol level.


This does seem to make it susceptible to man in the middle attacks where 
someone could swap out the proxy protocol data, but I think the general 
assumption is that the connection between the proxy/load balancer and 
the backend server is within a trusted network where such an attack is 
not a concern.

Re: HAProxy proxy protocol support

[Howard Chu]

Paul B. Henson wrote:
> On 11/19/2020 10:02 AM, Howard Chu wrote:
> 
>>> 1. Config directives for specifying IP address(es) and network(s) expected 
>>> and trusted to send proxy protocol header.
>>
>> Sounds like unnecessary work. Just use an ACL.
> 
> I don't think an ldap level ACL would work for what he means? I think he
> wants to control what source IP addresses are allowed to connect to the
> proxy protocol port and arbitrarily say what the client IP address is
> which is passed down to the underlying ldap access control to be
> processed by ACLs. If you are using IP address based access control, you
> wouldn't want arbitrary clients to be able to connect and send a proxy
> header claiming to be somebody else.
> 
> However, given that the proxy protocol and regular access will be on
> different ports, this seems better handled at the network firewall level.

It sounded to me like he is not passing the client address transparently,
which means that the actual peer address is still known, and would be
governed by the current peer-based ACL mechanisms already, while introducing
a new term to represent the proxied client address.

Anyway yes, controlling this at the firewall level would be better too.

>>> 3. Log the proxied peername separately, similar how session
>>> tracking control is logged.
>>
>> Again, kind of defeats the purpose of transparently relaying the
>> client's address.
> 
> I'm not completely sure what he meant by this, but I was planning on 
> modifying the initial connection log to indicate it was proxied, including 
> both the address
> of the proxy and the proxied address.
> 
> so for a normal connection something like:
> 
> Nov 15 19:21:18 themis slapd[22846]: conn=482386 fd=89 ACCEPT from 
> IP=134.71.247.3:54401 (IP=0.0.0.0:389)
> 
> and for a proxied connection something like:
> 
> Nov 15 19:21:18 themis slapd[22846]: conn=482386 fd=89 ACCEPT from 
> IP=134.71.247.3:54401 proxyIP=10.128.1.0:34323 (IP=0.0.0.0:389)

This would require that you actually read and process the proxy header
immediately after the accept call. It strikes me that this is the wrong
thing to do, if you also want to support TLS. I.e., that means the proxy
header travels in the clear before you do a TLS handshake, which is
probably not what one would want if they're using TLS. I suppose you
would need to check what the proxy server actually supports, if it
actually supports connecting to the target server using TLS.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: HAProxy proxy protocol support

[Michael Ströder]

On 11/19/20 5:04 PM, Howard Chu wrote:
> Paul B. Henson wrote:
>> 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.
> 
> Yeah, that agrees with my read of the document. I think "ldapp://" and 
> "ldapsp://"
> would be usable.

My suggestions:

1. Config directives for specifying IP address(es) and network(s)
expected and trusted to send proxy protocol header.

2. Separate who peernamestyle for explicitly using the proxied IP
addresses in ACLs. This would allow to specify ACLs with client-proxy
relationship.

3. Log the proxied peername separately, similar how session tracking
control is logged.

Ciao, Michael.

Re: HAProxy proxy protocol support

[Paul B. Henson]

On 11/19/2020 10:02 AM, Howard Chu wrote:

1. Config directives for specifying IP address(es) and network(s) 
expected and trusted to send proxy protocol header.


Sounds like unnecessary work. Just use an ACL.


I don't think an ldap level ACL would work for what he means? I think he
wants to control what source IP addresses are allowed to connect to the
proxy protocol port and arbitrarily say what the client IP address is
which is passed down to the underlying ldap access control to be
processed by ACLs. If you are using IP address based access control, you
wouldn't want arbitrary clients to be able to connect and send a proxy
header claiming to be somebody else.

However, given that the proxy protocol and regular access will be on
different ports, this seems better handled at the network firewall level.


3. Log the proxied peername separately, similar how session
tracking control is logged.


Again, kind of defeats the purpose of transparently relaying the
client's address.


I'm not completely sure what he meant by this, but I was planning on 
modifying the initial connection log to indicate it was proxied, 
including both the address of the proxy and the proxied address.


so for a normal connection something like:

Nov 15 19:21:18 themis slapd[22846]: conn=482386 fd=89 ACCEPT from 
IP=134.71.247.3:54401 (IP=0.0.0.0:389)


and for a proxied connection something like:

Nov 15 19:21:18 themis slapd[22846]: conn=482386 fd=89 ACCEPT from 
IP=134.71.247.3:54401 proxyIP=10.128.1.0:34323 (IP=0.0.0.0:389)

Re: HAProxy proxy protocol support

[Paul B. Henson]

On 11/19/2020 12:55 AM, Michael Ströder wrote:


Aaargh! I've missed the binary header part. So forget my former comments.


Version 1 of the protocol is ASCII, version 2 is binary. However, in 
both cases the proxy protocol data is removed and processed before the 
connection is handed down to the regular application logic, so it should 
be compatible with any server protocol.

Re: HAProxy proxy protocol support

[Paul B. Henson]

On 11/19/2020 8:04 AM, Howard Chu wrote:

Yeah, that agrees with my read of the document. I think "ldapp://" and 
"ldapsp://" would be usable.


Cool.


Doesn't seem too problematic. I would only support the version 2 (binary) 
header,
seems silly to implement the version 1 support for such an old spec.


I agree. I will put something together and come back when I have an 
initial diff for review, thanks…

Re: HAProxy proxy protocol support

[Howard Chu]

Michael Ströder wrote:
> On 11/19/20 5:04 PM, Howard Chu wrote:
>> Paul B. Henson wrote:
>>> 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.
>>
>> Yeah, that agrees with my read of the document. I think "ldapp://" and 
>> "ldapsp://"
>> would be usable.
> 
> My suggestions:
> 
> 1. Config directives for specifying IP address(es) and network(s)
> expected and trusted to send proxy protocol header.

Sounds like unnecessary work. Just use an ACL.

> 2. Separate who peernamestyle for explicitly using the proxied IP
> addresses in ACLs. This would allow to specify ACLs with client-proxy
> relationship.

Yeah, maybe. Although I see this adding extra burden: if you have an
existing deployment with peer-based ACLs, you will have to rewrite all
of them after the proxy server is in place. I thought the entire point
of adopting HAproxy protocol was so that you could continue operating
with the client's addresses *transparently*. If you have to rewrite all
of the rules regardless, I don't see any reason to bother with HAproxy.

> 3. Log the proxied peername separately, similar how session tracking
> control is logged.

Again, kind of defeats the purpose of transparently relaying the client's 
address.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: HAProxy proxy protocol support

[Howard Chu]

Paul B. Henson wrote:
> 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.

Yeah, that agrees with my read of the document. I think "ldapp://" and 
"ldapsp://"
would be usable.

> 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.

Doesn't seem too problematic. I would only support the version 2 (binary) 
header,
seems silly to implement the version 1 support for such an old spec.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: HAProxy proxy protocol support

[Michael Ströder]

On 11/19/20 9:52 AM, Michael Ströder wrote:
> On 11/19/20 2:49 AM, Paul B. Henson wrote:
>> 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,
> 
> AFAICS this only works with HTTP and SMTP.

Aaargh! I've missed the binary header part. So forget my former comments.

Ciao, Michael.

Re: HAProxy proxy protocol support

[Michael Ströder]

On 11/19/20 2:49 AM, Paul B. Henson wrote:
> 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,

AFAICS this only works with HTTP and SMTP.

> openLDAP does not support the protocol, and I was unable to find any
> past discussion of it.

LDAP uses BER-encoded ASN.1, not ASCII.

The LDAP session tracking extended control [1] can be used to pass the
client's IP address of a proxied connection to the LDAP server.
Currently slapd only logs the content of this control.

But it would have to be implemented in the proxy, here the AWS
load-balancer. *And* slapd's ACLs would have to be extended to evaluate
this.

Would be a nice feature for lloadd [2].

[1] https://tools.ietf.org/html/draft-wahl-ldap-session-03

[2] https://bugs.openldap.org/show_bug.cgi?id=8747

Ciao, Michael.

HAProxy proxy protocol support

[Paul B. Henson]

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…