Hello Roobesh,

On Wed, 26 Dec 2018 at 08:31, Mohandass, Roobesh
<roobesh_mohand...@mcafee.com> wrote:
>
> Hello,
>
>
>
> We are using haproxy version 1.8.14-1 in a docker container running ubuntu 
> 14.04 / kernel: 4.15.0-39-generic (Base host where container is running 18.04 
> / kernel 4.15.0-39-generic)
>
> getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes 
> returning the source IP instead the destination IP.
>
> Using getsockname() instead looks like solving the issue.
>
>
>
> https://stackoverflow.com/questions/11417187/getsockopt-so-original-dst-occasionally-returns-client-address
>
> For example: Out of 6569124 requests , 4 requests were wrong 0.000060891 %
>
>
>
> Can we file this as bug ? Get the fixed version in next release ?
>
> Also getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is used only for 
> send-proxy feature (for connected proxy IP) or any other feature in haproxy 
> also using this ?

For the record, the initial thread with you is on discourse:
https://discourse.haproxy.org/t/send-proxy-not-modifying-some-traffic-with-proxy-ip-port-details/3336

Martin Zielinski mentioned the hint that SO_ORIGINAL_DST sometimes
fails and omitting that call (returning the result of getsockname())
works around the issue. You confirmed this by compiling with
USE_TPROXY= which disables the code path in question
(SO_ORIGINAL_DST).


SO_ORIGINAL_DST is certainly a feature that is required when haproxy
binds to redirected sockets, otherwise we don't know the correct
destination IP, so I don't think we can simply drop the call. Looking
some further in into the root cause is what is required to get a
better understanding of this.


What I would ask you is to clarify how this can be reproduced? Do you
only see this in production, or can you reproduce this also in a lab?
If so, how do you reproduce it?



Thanks,
Lukas

Reply via email to