Hello Lukas,


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?



RGM: This is reproducible anywhere production/lab but when we see this behavior 
is a questions as I said out of so many large number of requests only for some 
we will observe this behavior(but can be caught very quickly in less than 
30mins span of time).
Initiate some larger numbers of requests (with some basic setup frontend with 
backend using send proxy and some backend servers) and perform an easy way of 
catching this on first hand using ' tcpdump -i <interface> -nn -A net 
<net/prefix-len> and port <port> | grep PROXY | cut -c9- | awk '/^PROXY/ && $4 
!~ /^10\.10\./ && $4 !~ /^10\.11\./ && $4 !~ /^10\.12\./ {print $0 }'  (adjust 
the awk command according to your frontend/backend network) so this command 
will only result when data is wrong for destination IP (like below),
Below is just an illustration,
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 262144 bytes
PROXY TCP4 100.100.100.100 100.100.100.100 41135 41135
PROXY TCP4 100.100.100.100 100.100.100.100 11547 11547



You can try if you have your test setup , if not I can show you live in my 
staging if you are open for a webex call.



Thanks very much for your help and support.



-Roobesh G M



-----Original Message-----
From: lu...@ltri.eu <lu...@ltri.eu>
Sent: Wednesday, December 26, 2018 3:09 PM
To: Mohandass, Roobesh <roobesh_mohand...@mcafee.com>; haproxy 
<haproxy@formilux.org>
Subject: Re: Send-proxy not modifying some traffic with proxy ip/port details 
instead retaining same client ip port



This email originated from outside of the organization. Do not click links or 
open attachments unless you recognize the sender and know the content is safe.



Hello Roobesh,



On Wed, 26 Dec 2018 at 08:31, Mohandass, Roobesh 
<roobesh_mohand...@mcafee.com<mailto: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-ds

> t-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