* Xdp synproxy causes tcp resest
@ 2023-10-01 17:01 Minh Le Hoang
2023-10-11 14:32 ` Vincent Li
0 siblings, 1 reply; 4+ messages in thread
From: Minh Le Hoang @ 2023-10-01 17:01 UTC (permalink / raw
To: xdp-newbies
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:
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Xdp synproxy causes tcp resest
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
0 siblings, 1 reply; 4+ messages in thread
From: Vincent Li @ 2023-10-11 14:32 UTC (permalink / raw
To: Minh Le Hoang; +Cc: xdp-newbies
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Xdp synproxy causes tcp resest
2023-10-11 14:32 ` Vincent Li
@ 2023-10-15 4:58 ` Minh Le Hoang
2023-10-16 17:17 ` Vincent Li
0 siblings, 1 reply; 4+ messages in thread
From: Minh Le Hoang @ 2023-10-15 4:58 UTC (permalink / raw
To: Vincent Li; +Cc: xdp-newbies
[-- Attachment #1: Type: text/plain, Size: 4230 bytes --]
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
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.
[-- Attachment #2: veth3cap_xdp.pcapng --]
[-- Type: application/octet-stream, Size: 4484 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Xdp synproxy causes tcp resest
2023-10-15 4:58 ` Minh Le Hoang
@ 2023-10-16 17:17 ` Vincent Li
0 siblings, 0 replies; 4+ messages in thread
From: Vincent Li @ 2023-10-16 17:17 UTC (permalink / raw
To: Minh Le Hoang; +Cc: xdp-newbies
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-10-16 17:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.