On Fri, Dec 8, 2023 at 4:42 AM Minh Le Hoang <minh.lehoang@xxxxxxxxxxxxx> wrote: > > ---------- Forwarded message --------- > From: Minh Le Hoang <minh.lehoang@xxxxxxxxxxxxx> > Date: Fri, Dec 8, 2023 at 1:40 PM > Subject: Re: Bug in xdp synproxy kernel code > To: Vincent Li <vincent.mc.li@xxxxxxxxx> > > > 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@xxxxxxxxx> wrote: > > > > On Thu, Dec 7, 2023 at 2:19 AM Jeroen van Ingen Schenau > > <jeroen.vaningenschenau@xxxxxxxxxxxxx> 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 >
|