On Wed, May 26, 2021 at 03:46:36PM -0700, Peter Scott (US 172D) wrote: > > > frontend internal_http_80 > > > bind xxx.xxx.xxx.xxx:80 transparent > > > default_backend internal_http_80_backend > > > > > > backend internal_http_80_backend > > > balance leastconn > > > source 0.0.0.0 usesrc clientip > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > You're running in transparent mode, which means that you're spoofing > > the client's IP address when connecting to it. You cannot do that to > > reconnect to the same node, because the machine definitely sees that > > you're using its own IP address to connect, and even if it would > > accept it, it would respond to itself! > > > > You need to disable this. > > And indeed that was how we had originally configured haproxy, but we > switched to transparent mode because we need the correct client IP logged on > the Apache back ends. We couldn't use send-proxy or forwardfor because > haproxy is not doing SSL termination. We couldn't do SSL termination > because the back ends are serving hundreds of virtual hosts each with their > own SSL certs and the certs change without notice daily as CNAMEs come and > go.
I can undertand that you cannot decrypt SSL if you need to move all virtual hosts there and that for whatever reason it's not convenient, however proxy-protocol is independent on this and ought to have worked. > We tried send-proxy-v2-ssl and got SSL connection failure. Is that a valid > approach and we just didn't get it right? Yes it ought to work (provided you have the proper setup on the Apache side of course). There's "mod_remoteip" for this, however I don't know if it supports PPv2 or only v1 (in which case you'd need to use send-proxy instead of send-proxy-v2). Note that send-proxy-v2-ssl is used to pass extra info related to the front SSL connection. Since haproxy doesn't decrypt SSL in your case, there will be no such info and you only need "send-proxy". > Otherwise we're reduced to asking > whether there is a way to ensure a connection is not routed to a particular > back end if the connection came from there. It will be quite complicate and you'll very easily get into trouble. Quite frankly for having played with this 15 years ago, I can only encourage anyone never to engage into that spiral, because you end up stacking exceptions on top of exceptions still the point where you have to refuse certain applications because they'll end up using mutually incompatible service. So in short: don't do that. If you cannot get the proxy-protocol to work (I don't see why but just in case), then moving your certificates to haproxy and letting it handle the TLS part is the regular way to go. It *will* definitely change some of your processes, which is a pain for the short term, but it will bring you more flexibility for the long term (centralized cert management, independence on the backend technology allowing you to easier mix various solutions, insert components in the middle such as WAFs etc). But this generally is a matter of studying a re-architecture of your platform and must not be done on a whim. Willy
