Hello!
On Sat, 12 Jan 2019 at 18:26, Willy Tarreau <w...@1wt.eu> wrote: > > One case where this can happen is when nf_conntrack_tcp_loose > > (mid-stream pickup) is enabled. > > Very interesting case indeed, I hadn't thought about it! I think we > don't have enough info from the original reporter's setup but it > would definitely make sense and explain why it's the other end which > is retrieved! > > I'm seeing one possibility to explain this : Let's say the OP's setup > has a short conntrack timeout and a longer haproxy timeout. If the > address is only retrieved for logging, it will be retrieved at the > end of the connection. Let's assume haproxy receives a request from > a client, a conntrack entry is created and haproxy forwards the request > to a very slow server. Before the server responds, the conntrack entry > expires, then the server responds and haproxy forwards to the client, > re-creating the entry and hitting this case before the address is > picked up for logging. > > Roobesh, do you use the destination address only for logging or > anywhere else in the request path ? And could you check if you have > nf_conntrack_tcp_loose set as Florian suggests ? I really think he > figured it right. It's about what we send with the PROXY protocol to the backend server, Roobesh reported things like that (src and dst is the same): PROXY TCP4 192.220.26.39 192.220.26.39 45066 45066 PROXY TCP4 192.220.26.39 192.220.26.39 45075 45075 So the call would actually happen at the beginning of the TCP connection. Initial report is here: https://discourse.haproxy.org/t/send-proxy-not-modifying-some-traffic-with-proxy-ip-port-details/3336 Let's see if disabling nf_conntrack_tcp_loose changes things. Thanks, Lukas
