On 20.05.2015 14:02, Lukas Tribus wrote: >> Hi, >> >> my current traffic flow with "source 0.0.0.0 usesrc clientip" and with >> "source publichaproxyip usesrc clientip": >> >> haproxy receives a SYN from the client and does a normal tcp handshake >> which works fine. Additionally haproxy forwards the SYN to the backend >> with the client ip as source ip, backend sends SYN/ACK back to haproxy, >> haproxy sends this to the client. client is confused because he send one >> SYN but receives two SYN/ACK. >> >> it would be perfect if haproxy would establish a connection with the >> node and a second with the backend, any ideas on how to tell haproxy to >> not forward packets from the backend but to answer them by himself? > You need to take a decision: > > do you want a local source IP (your test) > OR > a remote source IP (which is what you seem to want in the end) > > You cannot have both.
so it is not possible to let haproxy answer backend packets to client ips? If so, I've two solutions: 1) using tproxy and build a real transparent proxy 2) disable transparent stuff/ip spoofing and manipulate the rsyslog message to include the src ip so my logstash backend can get the ip from the message content and doesn't need it as paket source. tproxy support isn't buildin in my kernel so I willl probably choose option2. > > If the former is the case, then disable ip_forwarding in your kernel. > For the latter, you won't have the problem you just mentioned. > > > Lukas > >
