Antonio Ojea <antonio.ojea.garcia@xxxxxxxxx> wrote: > I'm puzzled trying to understand the following behavior, appreciate it > if you can help me to understand better how this works. > > The setup is like this: Client --- Router --- Server > > - Router DNATs to a Virtual IP and Port of the Server. > - Client establishes a permanent connection to the Virtual IP. > - Router adds a REJECT rule in the FORWARD hook for the Server IP > > I expect the REJECT to match the established connection, but the > client keeps reaching the Server using the existing connection. > > The packets of the established connection do not show up on the traces > using nftrace. > > Is it possible to "DROP/REJECT" the established connection ? > > I've created a selftest to reproduce this behavior, please find it attached. Are you sure this script works as intended? Doing: socat tcp-listen:12345,fork PIPE & socat PIPE:P tcp:127.0.0.1:12345 & echo foo > P ... causes endless traffic, since listener echoes P back, that gets written to P, socat reads from it, eches foo to server, that sends to client, ... Probably you need to use: socat -u PIPE:P,rdonly ... ? This config change is also needed: --- a/tools/testing/selftests/net/netfilter/config +++ b/tools/testing/selftests/net/netfilter/config @@ -81,6 +81,7 @@ CONFIG_NFT_NUMGEN=m CONFIG_NFT_QUEUE=m CONFIG_NFT_QUOTA=m CONFIG_NFT_REDIR=m +CONFIG_NFT_REJECT=m since thats the kernel feature template used by the netdev ci to build the test kernel to use. Another issue: cwd might be readonly, so creating pipe.test will fail. I suggest to use pipename=$(mktemp -u) so the named fifo is created in /tmp which is writeable.
