On Thu, Mar 22, 2018 at 01:15:26PM +0000, matei marius wrote: > haproxy -vv > HA-Proxy version 1.8.4-1deb90d 2018/02/08 > Copyright 2000-2018 Willy Tarreau <[email protected]> > > Build options : > TARGET = linux26 > CPU = generic > CC = gcc > CFLAGS = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing > -Wdeclaration-after-statement -fwrapv -Wno-unused-label > OPTIONS = USE_PCRE=1 > > Default settings : > maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200 > > Built with transparent proxy support using: IP_TRANSPARENT IP_FREEBIND > Encrypted password support via crypt(3): yes > Built with PCRE version : 8.32 2012-11-30 > Running on PCRE version : 8.32 2012-11-30 > PCRE library supports JIT : no (USE_PCRE_JIT not set) > Built without compression support (neither USE_ZLIB nor USE_SLZ are set). > Compression algorithms supported : identity("identity") > Built with network namespace support. > > 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. > > Available filters : > [SPOE] spoe > [COMP] compression > [TRACE] trace > > 00000017:fe_frontend_pool_proxy_172_17_232_232_3128.accept(0005)=000d from > [172.17.232.233:54117] ALPN=<none> > 00000018:fe_frontend_pool_proxy_172_17_232_232_3128.accept(0005)=0027 from > [172.17.232.233:54118] ALPN=<none> > 00000017:bk_pool_proxy_172_17_232_232_3128.clicls[adfd:adfd] > 00000017:bk_pool_proxy_172_17_232_232_3128.closed[adfd:adfd] > 00000018:bk_pool_proxy_172_17_232_232_3128.clicls[adfd:adfd] > 00000018:bk_pool_proxy_172_17_232_232_3128.closed[adfd:adfd] > 00000019:fe_frontend_pool_proxy_172_17_232_232_3128.accept(0005)=000d from > [172.17.232.233:54119] ALPN=<none> > 0000001a:fe_frontend_pool_proxy_172_17_232_232_3128.accept(0005)=0027 from > [172.17.232.233:54120] ALPN=<none>
As Mathias said, the problem is unrelated to haproxy but it's the way the network stack works in modern systems : checksums are offloaded to the hardware so the buffers where tcpdump finds the packets have no valid checksum yet (usually 0 but will depend on the OS) and the checks indicate they are invalid. > And the question remains.Why is not working from a client from the same IP > class with 172.17.232.x. ? This is normal, your server wants to respond directly to the client and fails. This is a well-known problem in transparent proxy environments as well as destination-nat ones (eg: LVS). You must always ensure that the server will route the return traffic to the client through the load balancer. If the client comes from the same network as the server, the server believes it's on its local net and will route directly without passing back via the load balancer. If your client on this network has a fixed address, you can add a host route on your servers to join the client via the load balancer. You will also likely have to disable the emission of ICMP redirects on the LB (as it will receive a packet for a destination belonging to the same LAN it received it from). Usually people avoid transparent proxying for all these painful reasons, and it's only enabled for traffic coming from the internet, never for local systems. Hoping this helps, Willy
