Re: tproxy bug in haproxy-1.5.10
On Thu, Jan 15, 2015 at 08:21:05PM +0100, U.Mutlu wrote: > global >maxconn 512 > > defaults >timeout connect 1m >timeout client 2m >timeout server 2m >#option redispatch > > frontend MyFrontend >bind192.168.100.101:5678 Here you need "transparent" on the "bind" line to enable tproxy. But I agree with Lukas that your setup is overly complicated, makes no sense at all, and does not reflect what you'd use in production. I didn't even know that tproxy used to support the options you were using, so probably you're not the only one to seek complications... Regards, Willy
Re: tproxy bug in haproxy-1.5.10
Lukas Tribus wrote, On 01/15/2015 09:06 PM: Imagine the 192.168.100.100 is a public IP (for example 1.2.3.4), and the others are private IPs as they indeed are (192.168.*). The reason for me is to use internally (ie. between the proxy server and the backend server) only the private IPs. The remote IP that your backend sees will be the client ip anyway, not your internal IP, so whats the point? True, but that's not the issue here. As said the idea and the setup works, but haproxy has a problem with it, and therefore there is a bug in haproxy. Yet you did not explain what the actual bug is. You keep saying there is a bug, but you don't explain it. I think I already explained it completely. If you still have a question on this specific setup scenario let me know.
RE: tproxy bug in haproxy-1.5.10
> Imagine the 192.168.100.100 is a public IP (for example 1.2.3.4), > and the others are private IPs as they indeed are (192.168.*). > The reason for me is to use internally (ie. between the proxy server > and the backend server) only the private IPs. The remote IP that your backend sees will be the client ip anyway, not your internal IP, so whats the point? > As said the idea and the setup works, but haproxy has a problem with it, > and therefore there is a bug in haproxy. Yet you did not explain what the actual bug is. You keep saying there is a bug, but you don't explain it.
Re: tproxy bug in haproxy-1.5.10
Lukas Tribus wrote, On 01/15/2015 08:31 PM: As said in the inital posting, the IP of the proxy server is 192.168.100.100 and public port 1234; it needs to be forwarded to the 2nd IP 192.168.100.101 port 5678, and from there to the backend server 192.168.100.102:. The key question is: what is the reason you don't bind to 192.168.100.100:1234? Imagine the 192.168.100.100 is a public IP (for example 1.2.3.4), and the others are private IPs as they indeed are (192.168.*). The reason for me is to use internally (ie. between the proxy server and the backend server) only the private IPs. As said the idea and the setup works, but haproxy has a problem with it, and therefore there is a bug in haproxy. I unfortunately lost much time for finding the reason for this mysterious behavior of haproxy, so I just wanted to inform you of the bug. The bug is localized as having to do with the TPROXY forwarding even before haproxy gets the packet. As said, with an other transparent proxy (test-) program this scenario works fine.
RE: tproxy bug in haproxy-1.5.10
> As said in the inital posting, the IP of the proxy server is 192.168.100.100 > and public port 1234; it needs to be forwarded to the 2nd IP 192.168.100.101 > port 5678, and from there to the backend server 192.168.100.102:. The key question is: what is the reason you don't bind to 192.168.100.100:1234?
Re: tproxy bug in haproxy-1.5.10
Lukas Tribus wrote, On 01/15/2015 07:24 PM: Portforwarding to a different IP on the same haproxy-box causes haproxy behave buggy. This error happens when one uses the TPROXY target for portforwarding, ie. like this: Let's say the IP of the main interface is 192.168.100.100, and traffic from outside to port 1234 shall be forwarded to a virtual IP 192.168.100.101 and port 5678 on the same host, ie: I don't understand what you are trying to do and why. Can you elaborate what you are trying to do (in production, not in a lab) and can you also share the haproxy configuration? Ok, let me explain: Internet clients (let's say using generic tcp protocol) do connect to a public port on the proxy server. The proxy server forwards the packets to the (internal) backend server. Now, suppose you have two IP's on the proxy server (in my case both in the same /24-subnet), and you want accept public clients only on the first IP and from there on route the packets via the 2nd IP to the backend server (in my case the backend server too is in the same subnet). The question is: how can one forward to the second IP:port? One of the possible solutions is to use the iptables TPROXY target for that (it works). But if done so, then haproxy has a problem. And that's the whole point of this bug report. As said in the inital posting, the IP of the proxy server is 192.168.100.100 and public port 1234; it needs to be forwarded to the 2nd IP 192.168.100.101 port 5678, and from there to the backend server 192.168.100.102:. Of course the backend server needs the originating IP of the client, hence the transparent proxy requirement. Here's my minimal haproxy cfg: global maxconn 512 defaults timeout connect 1m timeout client 2m timeout server 2m #option redispatch frontend MyFrontend bind192.168.100.101:5678 default_backend Transparent_tcp backend Transparent_tcp mode tcp source 0.0.0.0 usesrc client server MyServer 192.168.100.102: TPROXY is used to intercept TCP connections of non-local IPs. Using TPROXY IPs that configured on your local machine makes no sense. Yes of course true; I'm using TPROXY to pass the original IP of the client to the backend server. Regards, Uenal
RE: tproxy bug in haproxy-1.5.10
Hi, > Portforwarding to a different IP on the same haproxy-box causes haproxy behave > buggy. > This error happens when one uses the TPROXY target for portforwarding, > ie. like this: > > Let's say the IP of the main interface is 192.168.100.100, > and traffic from outside to port 1234 shall be forwarded > to a virtual IP 192.168.100.101 and port 5678 on the same host, ie: I don't understand what you are trying to do and why. Can you elaborate what you are trying to do (in production, not in a lab) and can you also share the haproxy configuration? TPROXY is used to intercept TCP connections of non-local IPs. Using TPROXY IPs that configured on your local machine makes no sense. Lukas
tproxy bug in haproxy-1.5.10
Hi, I wanted to report a nasty bug I discovered today: Portforwarding to a different IP on the same haproxy-box causes haproxy behave buggy. This error happens when one uses the TPROXY target for portforwarding, ie. like this: Let's say the IP of the main interface is 192.168.100.100, and traffic from outside to port 1234 shall be forwarded to a virtual IP 192.168.100.101 and port 5678 on the same host, ie: auto eth0 allow-hotplug eth0 iface eth0 inet static address 192.168.100.100 netmask 255.255.255.0 broadcast 192.168.100.255 gateway 192.168.100.254 metric1 up ip addr add 192.168.100.101/32 dev eth0 label eth0:101 down ip addr del 192.168.100.101/32 dev eth0 label eth0:101 ... iptables -t mangle -A PREROUTING -p tcp --dport 1234 -j TPROXY --tproxy-mark 666 --on-ip 192.168.100.101 --on-port 5678 When REDIRECT instead of TPROXY is used then it works, but with that one can forward only to another port of the main IP (192.168.100.100) of the interface, ie. here eth0. I can confirm this bug because putting a different transparent proxy program (actually my own test program) at the same IP:Port works fine with such portforwardings. My environment: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux, ie. Debian 8 I compiled haproxy myself w/o any modifications: # ./haproxy -vv HA-Proxy version 1.5.10 2014/12/31 Copyright 2000-2014 Willy Tarreau Build options : TARGET = linux26 CPU = x86_64 CC = gcc CFLAGS = -g -fno-strict-aliasing OPTIONS = USE_LINUX_TPROXY=1 USE_STATIC_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built without zlib support (USE_ZLIB not set) Compression algorithms supported : identity Built without OpenSSL support (USE_OPENSSL not set) Built with PCRE version : 8.35 2014-04-04 PCRE library supports JIT : no (USE_PCRE_JIT not set) Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll.
