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
|