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