All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Tribus <lists@ltri.eu>
To: Willy Tarreau <w@1wt.eu>,
	Mohandass Roobesh <Roobesh_Mohandass@mcafee.com>
Cc: Florian Westphal <fw@strlen.de>, netdev@vger.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
Date: Sat, 12 Jan 2019 19:01:34 +0100	[thread overview]
Message-ID: <CACC_My-0bsFPqSaNCsF2bZhNSo_3o1F+qfy8utKRO7-2CZZqYg@mail.gmail.com> (raw)
In-Reply-To: <20190112172636.GA26639@1wt.eu>

Hello!


On Sat, 12 Jan 2019 at 18:26, Willy Tarreau <w@1wt.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

WARNING: multiple messages have this Message-ID (diff)
From: Lukas Tribus <lists@ltri.eu>
To: Willy Tarreau <w@1wt.eu>,
	Mohandass Roobesh <Roobesh_Mohandass@mcafee.com>
Cc: Florian Westphal <fw@strlen.de>, netdev@vger.kernel.org
Subject: Re: [NETDEV]: getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes returning the source IP instead the destination IP
Date: Sat, 12 Jan 2019 19:01:34 +0100	[thread overview]
Message-ID: <CACC_My-0bsFPqSaNCsF2bZhNSo_3o1F+qfy8utKRO7-2CZZqYg@mail.gmail.com> (raw)
Message-ID: <20190112180134.3CYw0OcoIF1Gj2ZkwLwehEzBkahWxj3er327wOVdBOk@z> (raw)
In-Reply-To: <20190112172636.GA26639@1wt.eu>

Hello!


On Sat, 12 Jan 2019 at 18:26, Willy Tarreau <w@1wt.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

  reply	other threads:[~2019-01-12 18:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <MWHPR16MB1502549F7BAAE102EF1D5DF4EDB50@MWHPR16MB1502.namprd16.prod.outlook.com>
     [not found] ` <MWHPR16MB150233EF69CFD4562BFA65ABEDB60@MWHPR16MB1502.namprd16.prod.outlook.com>
     [not found]   ` <MWHPR16MB1502DC55542EBA8121631B16EDB20@MWHPR16MB1502.namprd16.prod.outlook.com>
2018-12-31  6:20     ` : getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes returning the source IP instead the destination IP Mohandass, Roobesh
2019-01-07 11:17       ` Florian Westphal
2019-01-07 14:57         ` Mohandass, Roobesh
2019-01-12 14:37         ` Lukas Tribus
2019-01-12 14:37           ` [NETDEV]: " Lukas Tribus
2019-01-12 16:04           ` : " Florian Westphal
2019-01-12 16:04             ` [NETDEV]: " Florian Westphal
2019-01-12 17:26             ` : " Willy Tarreau
2019-01-12 17:26               ` [NETDEV]: " Willy Tarreau
2019-01-12 18:01               ` Lukas Tribus [this message]
2019-01-12 18:01                 ` Lukas Tribus
2019-01-12 18:33                 ` : " Willy Tarreau
2019-01-12 18:33                   ` [NETDEV]: " Willy Tarreau
2019-01-17  5:23                   ` Mohandass, Roobesh
2019-01-23  8:07                     ` Mohandass, Roobesh
2019-01-23  8:54                       ` Willy Tarreau
     [not found]     ` <MWHPR16MB1502A336CCB4EF3F0FCB69ECEDB20@MWHPR16MB1502.namprd16.prod.outlook.com>
2019-01-07  7:58       ` : " Mohandass, Roobesh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACC_My-0bsFPqSaNCsF2bZhNSo_3o1F+qfy8utKRO7-2CZZqYg@mail.gmail.com \
    --to=lists@ltri.eu \
    --cc=Roobesh_Mohandass@mcafee.com \
    --cc=fw@strlen.de \
    --cc=netdev@vger.kernel.org \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.