HAProxy not being transparent. ???

mastermindpro

I setup a HAProxy enviroment for a couple of webservers using transparent ClientIP mode, and it works great. I'm trying to setup a second environment, also as just a TCP proxy, but not to a web server. I've configured the backend with Transparent ClientIP enabled. The proxy passes traffic through as I'd expect, but not with the client IP. The receiving server sees the "source" as being the IP of the proxy.

Now, this second environment is a bit different than the first in that the pfSense box is one-armed (only one network interface). Hence, the client traffic is coming into HAProxy and being proxied to the servers on the same network interface. I'm assuming this is the reason for the Transparent ClientIP function not working, but does anyone know a work-around?

jimp

If the client and servers are on the same interface, what you are asking is not possible.

If the server saw the client's true IP address and it's in the same subnet, the server would not send the return traffic back to the firewall/haproxy.

mastermindpro

@jimp:

…If the server saw the client's true IP address and it's in the same subnet, the server would not send the return traffic back to the firewall/haproxy.

That's the entire point of Transparent ClientIP in HAProxy. The only way the server would send the return traffic back to the proxy is if it didn't know the client IP, or more correctly, believed the client IP was the IP of the proxy. That's what I need to avoid, though, hence my attempted use of Transparent ClientIP.

Oh well…on to other potential solutions.

jimp

It's not a pfSense or HAProxy thing. If the client and server are in the same subnet, you can't proxy that TCP traffic, period.

Client x.x.x.4 -> Proxy x.x.x.1
Proxy faking source x.x.x.4 -> Server x.x.x.2
Server x.x.x.2 -> Client x.x.x.4

Client will drop the connection because it connected to x.x.x.1 NOT x.x.x.2, so the reply is invalid.

mastermindpro

This is an example site that shows how DSR works, in HAProxy even.
https://www.haproxy.com/blog/layer-4-load-balancing-direct-server-return-mode/

I've seen other such documents about other load balancers that work in a DSR (direct server return) mode. This one is from Barracuda:
https://campus.barracuda.com/product/loadbalanceradc/article/ADC/DSRDeployment/

Neither seem to require the client to be out-of-subnet or list that as a shortcoming. Seems like it would be a gigantic omission to leave that out. Here's a blog post from F5 decrying many disadvantages of DSR, and it doesn't list the in-subnet client as a problem, either:
https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return

I'm not trying to argue, but I am trying to understand if all of the above people are simply omitting this truth…or something else? I do understand that the reply from server to client could be confusing. Is that due to the source MAC being "different" or due to the source IP being "different"? I would assume that most OS' reply "from" the IP address of the proxy, since that's what address they accepted the session on.

jimp

Now you're moving the goal posts. DSR is not a proxy.

HAProxy the software doesn't do DSR, HAProxy the company sells (or used to sell) ALOHA, which is an appliance which can leverage Linux LVS to perform DSR

HAProxy the software is a reverse proxy. A client makes a 3-way TCP handshake to the proxy, the proxy processes the request, then the proxy makes a separate 3-way handshake to the server (this is where transparent client addresses breaks a proxy in the same subnet)

In DSR, the load balancer (can't call it a proxy!) does not actually accept a connection from the client, it rewrites the MAC to the actual target server and hands it off. IIRC this requires some very Linux-specific things that wouldn't apply to pfSense.

mastermindpro

Ooohhhhh…Well, at least it was an honest mistake. Thanks for pointing me to the correct playing field. Just makes me question my day 1 logic class reflexivity principle.

HAProxy != HAProxy

:o

I do believe, though, that you could still legitimately call DSR products "proxies", they're just L2 proxies. I mistakenly assumed that checking the Transparent ClientIP box in pfSense's HAProxy implementation turned it into the L2 magician I'm looking for.