On Sat, Oct 14, 2023 at 9:58 PM Minh Le Hoang <minh.lehoang@xxxxxxxxxxxxx> wrote: > > Hi Vincent, > Thank you for your reply. I have now changed the setup a little bit by > making network namepace ns2 as a firewall to use iptable. I run these > command for iptable configuration: > sysctl -w net.ipv4.tcp_syncookies=2 > sysctl -w net.ipv4.tcp_timestamps=1 > sysctl -w net.netfilter.nf_conntrack_tcp_loose=0 > > iptables -t raw -I PREROUTING -i veth3 -p tcp -m tcp --syn --dport 80 > -j CT --notrack > iptables -t filter -A INPUT -i veth3 -p tcp -m tcp --dport 80 -m state > --state INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale > 7 --mss 1460 > iptables -t filter -A INPUT -i veth3 -m state --state INVALID -j DROP > > ./xdp_synproxy --iface veth3 --ports 80 --single --mss4 1460 --mss6 > 1440 --wscale 7 --ttl 64 > > The result is really confusing because the xdp program drops all the > tcp SYN packets. Below is the wireshark file I capture by using > xdpdump program in veth3: > Kind regards, > Minh I suggest you not do top posting in the mailing list because it is not easier to follow. I have not tried namespace myself so I am not sure if there is any particular setup requirement, in a firewall scenario, what I noticed is that the target IP that the XDP SYNPROXY is protecting for needs to be a destination IP on the firewall itself (the firewall could do DNAT to backend server IP after SYNPROXY processing), not IP on the backend server behind the firewall, at least that is my observation, I maybe missing something. > > On Wed, Oct 11, 2023 at 4:32 PM Vincent Li <vincent.mc.li@xxxxxxxxx> wrote: > > > > On Sun, Oct 1, 2023 at 10:11 AM Minh Le Hoang > > <minh.lehoang@xxxxxxxxxxxxx> wrote: > > > > > > Hi everyone, currently I am trying to make the xdp synproxy work from > > > the sample of linux kernel repository. I take the xdp kernel code from > > > here: https://github.com/torvalds/linux/blob/master/tools/testing/selftests/bpf/progs/xdp_synproxy_kern.c > > > , and the xdp synproxy userspace program from here: > > > https://github.com/torvalds/linux/blob/master/tools/testing/selftests/bpf/xdp_synproxy.c > > > . > > > I set up my testing environment with 3 network namespaces: ns1 as a > > > server, ns2 as a router and ns3 as a client. I set 4 virtual > > > ethernets: veth1 with peer veth2, veth3 with peer veth4 and add them > > > to the different namespaces. To be specific, I use veth1 > > > (192.168.1.1/24) for namespace ns1, veth2(192.168.1.2/24) and > > > veth3(192.168.2.1/24) for namespace ns2, and veth4(192.168.2.2/24) for > > > namespace ns3. For the namespace ns1, I enable tcp syncookie, tcp > > > loose contract by using these command: > > > sysctl -w net.ipv4.tcp_syncookies=2 > > > sysctl -w net.ipv4.tcp_timestamps=1 > > > sysctl -w net.netfilter.nf_conntrack_tcp_loose=0 > > > Then I upload the xdp synproxy program to the veth1 using this command: > > > ./xdp_synproxy --iface veth1 --ports 80 --single --mss4 1460 --mss6 > > > 1440 --wscale 7 --ttl 64 > > > and upload the xdp dummy kernel program, which is just simple xdp_pass > > > to the veth2 interface of namespace ns2 with this command: > > > ip link set veth2 xdp object xdp_dummy_kern.bpf.o section xdp > > > . Most of my setup is taken from the test program from linux kernel repository: > > > https://github.com/torvalds/linux/blob/master/tools/testing/selftests/bpf/prog_tests/xdp_synproxy.c > > > > > > After that, I run the a simple http server at port 80 in namespace > > > ns1. I use the netcat in network namespace ns3 to check for the tcp > > > connect: > > > # nc -v 192.168.1.1 80 > > > nc: connect to 192.168.1.1 port 80 (tcp) failed: Connection reset by peer > > > > > > . I debug using tcpdump and xdpdump in both interface veth1 and veth2 > > > and discover that the xdp synproxy program allow tcp ack packet to > > > passthrough but does not notify the host which causes invalid tcp > > > state and causes the server to respond with tcp reset flag. For more > > > detail, here are the link to the Wireshark files of veth1 and veth2: > > > > I did not look at your capture, this problem sounds familiar and I > > guess you probably missed the iptables rules for SYNPROXY, if you look > > at bpf selftest, it has iptables rules setup for synproxy, I am > > porting xdp synproxy to bpf-examples repo and here are the iptables > > rules for example > > > > https://github.com/vincentmli/bpf-examples/tree/vli-dev/xdp-synproxy > > > > > > > > https://www.dropbox.com/scl/fo/26kgk8sfozme1d6cc9zn4/h?rlkey=s1y9klybryilk5btylnp0dttg&dl=0 > > > > > > Why does this problem happen? What should I do to fix this problem? In > > > addition, I notice that if the veth2 interface does not attach the xdp > > > dummy program, it does not recognise the tcp syn-ack packet generated > > > by xdp synproxy program. What could be the solution for this? > > > > > > Kind regard > > > > > > Minh.
|