netdev - Re: : getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes returning the source IP instead the destination IP

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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