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