From: Vincent Li <vincent.mc.li@gmail.com>
To: Minh Le Hoang <minh.lehoang@novoserve.com>
Cc: xdp-newbies@vger.kernel.org,
Jeroen van Ingen Schenau <jeroen.vaningenschenau@novoserve.com>
Subject: Re: Bug in xdp synproxy kernel code
Date: Fri, 8 Dec 2023 10:57:27 -0800 [thread overview]
Message-ID: <CAK3+h2z1r69Z5g+qTwCaJzgnD5sv93x67TLJ3gVQ70_nFE0AqQ@mail.gmail.com> (raw)
In-Reply-To: <CAAi1gX5O3TpTdryKkfxT7Xp0dqJzkNu8KCuJTJSREPJ1cBC9_A@mail.gmail.com>
On Fri, Dec 8, 2023 at 4:42 AM Minh Le Hoang <minh.lehoang@novoserve.com> wrote:
>
> ---------- Forwarded message ---------
> From: Minh Le Hoang <minh.lehoang@novoserve.com>
> Date: Fri, Dec 8, 2023 at 1:40 PM
> Subject: Re: Bug in xdp synproxy kernel code
> To: Vincent Li <vincent.mc.li@gmail.com>
>
>
> Hi Vincent,
> I think the reason why the xdp synproxy works with and without the
> changing of the code is that in my setup lab, only 1 interface in the
> filter node is responsible for dealing with the incoming packet from
> both client and server. If you look in the mailing list naming "XDP
> synproxy causes tcp reset" which I finally made the code work by
> creating an iptable FORWARD chain, I set up a different lab containing
> 3 different network namespaces. The namespace ns2 which is both router
> and firewall, I upload the XDP synproxy program to the interface
> against the client's interface. When the XDP synproxy program triggers
> the conntrack table to establish TCP connection with the server, the
> interface containing XDP synproxy program is not involved in that
> operation. Thus, the bug in the code does not react. Only when I set
> up this network topology containing client, server, router, and filter
> node, my colleague Jeroen and I discovered this bug.
> Kind regards
> Minh
>
Thanks, I understand that. I could not get your filter scenario
working in the lab probably due to my lab setup issue. I thought
letting synproxy handle SYNACK from the backend server is kind of an
extra workload in my humble opinion :), filtering only on
client/internet side should be good enough, but I don't know your
environment.
> On Fri, Dec 8, 2023 at 1:56 AM Vincent Li <vincent.mc.li@gmail.com> wrote:
> >
> > On Thu, Dec 7, 2023 at 2:19 AM Jeroen van Ingen Schenau
> > <jeroen.vaningenschenau@novoserve.com> wrote:
> > >
> > > Hi Vincent, list,
> > >
> > > >> iptables -t filter -A FORWARD \
> > > >> -i eth1 -p tcp -m tcp --dport 80 -m state --state INVALID,UNTRACKED \
> > > >> -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
> > > >> iptables -t filter -A FORWARD \
> > > >> -i eth1 -m state --state INVALID -j DROP
> > > >
> > > > I have been unable to get it working by attaching xdp synproxy to
> > > > firewall/router without having target/protected destination IP on
> > > > firewall/router by adding rules in filter table INPUT chain, your idea
> > > > of adding rules in filter FORWARD chain solves my puzzle :)
> > >
> > > Glad that that helped! It was something that Minh struggled with too,
> > > for a while.
> > >
> > > Indeed you need to use the INPUT chain for traffic destined to the host
> > > itself (eg when you run this code on a webserver, reverse proxy or
> > > something like HAproxy in TCP mode). The FORWARD chain should be used
> > > when the host is just a hop in the path, so when it's bridging or
> > > routing the traffic, as is the case with a firewall placed in front of
> > > one or more servers.
> > >
> > > Our use case is a transparent firewall that can be placed in line with
> > > traffic to clean it, so probably similar to what you were trying.
> > >
> > > On a side note: the presentation [0] that you reference in your repo [1]
> > > also gives an example with the FORWARD chain, see pages/slides 12 & 13.
> > >
> > >
> > > >> I use the curl command in the client to get the web page from the
> > > >> server for testing. It is strange for me that after the synproxy code
> > > >> completes the 3 way handshake tcp with the client, it sends the syn
> > > >> packet to the server but it drops the SYNACK packet from the server.
> > > >>
> > > > I guess maybe originally the synproxy code is not expected to handle
> > > > SYNACK from the backend server?
> > >
> > > Looking through the code, we thought that it was actually designed to
> > > handle this (but not sure how it was tested then, and why this issue
> > > hadn't been identified yet).
> > >
> > >
> > > >> Now the xdp synproxy kernel code does not drop the SYNACK tcp packet
> > > >> from the server.
> > > >
> > > > Thanks for the analysis, if this is right and confirmed by other
> > > > expert, I guess I should also fix it up in the xdp synproxy code I
> > > > ported to bpf-samples repo
> > > > https://github.com/xdp-project/bpf-examples/tree/master/xdp-synproxy.
> > >
> > > Well, it would be nice if you can also test and validate our patch -
> > > having read through the code numerous times and after several tests in
> > > our VM setup (as Minh describes), this change makes the code do what we
> > > expect.
> > >
> >
> > Thank you for your detailed explanation, I tried Minh's lab setup
> > but for some reason I could not get it
> > working, I suspect it is my lab setup issue, I also tried a simple
> > firewall/router setup and attach
> > the xdp synproxy program directly to the firewall/router interface, no
> > standalone filter box involved to handle SYNACK from backend server
> > it works with and without your patch.
> >
> > > It has been accepted into bpf-next [2], so hopefully it will propagate
> > > to the relevant upstream repos - and maybe make it into Linux kernel 6.8.
> > >
> >
> > I will add your fix to the bpf-examples repo, and thank you for having
> > a real world working example xdp synproxy from kernel bpf selftest :)
> >
> > >
> > > Kind regards,
> > >
> > > Jeroen van Ingen Schenau
> > >
> > > [0]:
> > > https://netdevconf.info/0x15/slides/30/Netdev%200x15%20Accelerating%20synproxy%20with%20XDP.pdf
> > > [1]: https://github.com/xdp-project/bpf-examples/tree/master/xdp-synproxy
> > > [2]:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=b6a3451e0847
>
prev parent reply other threads:[~2023-12-08 18:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-24 17:30 Bug in xdp synproxy kernel code Minh Le Hoang
2023-12-01 4:51 ` Vincent Li
2023-12-07 10:19 ` Jeroen van Ingen Schenau
2023-12-08 0:56 ` Vincent Li
[not found] ` <CAAi1gX4iUmdd=uZpoBAVxYohX629g7RDw_Qs44bKD9XFW_qP1w@mail.gmail.com>
2023-12-08 12:41 ` Fwd: " Minh Le Hoang
2023-12-08 18:57 ` Vincent Li [this message]
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=CAK3+h2z1r69Z5g+qTwCaJzgnD5sv93x67TLJ3gVQ70_nFE0AqQ@mail.gmail.com \
--to=vincent.mc.li@gmail.com \
--cc=jeroen.vaningenschenau@novoserve.com \
--cc=minh.lehoang@novoserve.com \
--cc=xdp-newbies@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).