Re: netfilter expected behavior for established connections

[Florian Westphal <fw@strlen.de>]

Antonio Ojea <antonio.ojea.garcia@gmail.com> 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.