lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 12 Jan 2019 19:01:34 +0100 From: Lukas Tribus <lists@...i.eu> To: Willy Tarreau <w@....eu>, Mohandass Roobesh <Roobesh_Mohandass@...fee.com> Cc: Florian Westphal <fw@...len.de>, netdev@...r.kernel.org Subject: Re: : getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes returning the source IP instead the destination IP Hello! On Sat, 12 Jan 2019 at 18:26, Willy Tarreau <w@....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
Powered by blists - more mailing lists