From: Vincent Li <vincent.mc.li@gmail.com>
To: Minh Le Hoang <minh.lehoang@novoserve.com>
Cc: xdp-newbies@vger.kernel.org
Subject: Re: Xdp synproxy causes tcp resest
Date: Mon, 16 Oct 2023 10:17:27 -0700 [thread overview]
Message-ID: <CAK3+h2wqYYbJ+pY9stohNe8MSMmByrf2bn-fN6DZg_nuZ_HO6Q@mail.gmail.com> (raw)
In-Reply-To: <CAAi1gX45-41AJdFdAUVNL6KQWvR=MxgJ3xjqu36CFCSj=41YLg@mail.gmail.com>
On Sat, Oct 14, 2023 at 9:58 PM Minh Le Hoang
<minh.lehoang@novoserve.com> 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@gmail.com> wrote:
> >
> > On Sun, Oct 1, 2023 at 10:11 AM Minh Le Hoang
> > <minh.lehoang@novoserve.com> 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.
prev parent reply other threads:[~2023-10-16 17:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-01 17:01 Xdp synproxy causes tcp resest Minh Le Hoang
2023-10-11 14:32 ` Vincent Li
2023-10-15 4:58 ` Minh Le Hoang
2023-10-16 17:17 ` Vincent Li [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK3+h2wqYYbJ+pY9stohNe8MSMmByrf2bn-fN6DZg_nuZ_HO6Q@mail.gmail.com \
--to=vincent.mc.li@gmail.com \
--cc=minh.lehoang@novoserve.com \
--cc=xdp-newbies@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).