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 <>
To:     Willy Tarreau <>,
        Mohandass Roobesh <>
Cc:     Florian Westphal <>,
Subject: Re: : getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is
 in fact sometimes returning the source IP instead the destination IP


On Sat, 12 Jan 2019 at 18:26, Willy Tarreau <> 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 45066 45066
PROXY TCP4 45075 45075

So the call would actually happen at the beginning of the TCP connection.

Initial report is here:

Let's see if disabling nf_conntrack_tcp_loose changes things.


Powered by blists - more mailing lists