From: Florian Westphal <fw@strlen.de>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Florian Westphal <fw@strlen.de>,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org
Subject: Re: 6.1: possible bug with netfilter conntrack?
Date: Fri, 13 Jan 2023 13:56:29 +0100 [thread overview]
Message-ID: <20230113125629.GD19463@breakpoint.cc> (raw)
In-Reply-To: <Y8E8uX9gLBBywmf5@shell.armlinux.org.uk>
Russell King (Oracle) <linux@armlinux.org.uk> wrote:
[..]
> Digging through the tcpdump and logs, it seems what is going on is:
>
> public interface dmz interface
> origin -> mailserver SYN origin -> mailserver SYN
> mailserver -> origin SYNACK mailserver -> origin SYNACK
> origin -> mailserver ACK
> mailserver -> origin RST
> mailserver -> origin SYNACK mailserver -> origin SYNACK
> mailserver -> origin SYNACK mailserver -> origin SYNACK
> mailserver -> origin SYNACK mailserver -> origin SYNACK
> mailserver -> origin SYNACK mailserver -> origin SYNACK
> ...
>
> Here is an example from the public interface:
>
> 09:52:36.599398 IP 103.14.225.112.63461 > 78.32.30.218.587: Flags [SEW], seq 3387227814, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
> 09:52:36.599893 IP 78.32.30.218.587 > 103.14.225.112.63461: Flags [S.], seq 816385329, ack 3387227815, win 64240, options [mss 1452,nop,nop,sackOK,nop,wscale 7], length 0
> 09:52:36.820464 IP 103.14.225.112.63461 > 78.32.30.218.587: Flags [.], ack 1, win 260, length 0
> 09:52:36.820549 IP 78.32.30.218.587 > 103.14.225.112.63461: Flags [R], seq 816385330, win 0, length 0
> 09:52:37.637548 IP 78.32.30.218.587 > 103.14.225.112.63461: Flags [S.], seq 816385329, ack 3387227815, win 64240, options [mss 1452,nop,nop,sackOK,nop,wscale 7], length 0
>
> and the corresponding trace on the mailserver:
> 09:52:36.599729 IP 103.14.225.112.63461 > 78.32.30.218.587: Flags [SEW], seq 3387227814, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
> 09:52:36.599772 IP 78.32.30.218.587 > 103.14.225.112.63461: Flags [S.], seq 816385329, ack 3387227815, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
> 09:52:37.637421 IP 78.32.30.218.587 > 103.14.225.112.63461: Flags [S.], seq 816385329, ack 3387227815, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
>
> So, my first observation is that conntrack is reacting to the ACK
> packet on the public interface, and marking the connection established,
> but a firewall rule is rejecting the connection when that ACK packet is
> received by sending a TCP reset. It looks like conntrack does not see
> this packet,
Right, this is silly. I'll see about this; the rst packet
bypasses conntrack because nf_send_reset attaches the exising
entry of the packet its replying to -- tcp conntrack gets skipped for
the generated RST.
But this is also the case in 5.16, so no idea why this is surfacing now.
next prev parent reply other threads:[~2023-01-13 13:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 23:03 6.1: possible bug with netfilter conntrack? Russell King (Oracle)
2023-01-12 23:38 ` Florian Westphal
2023-01-13 0:16 ` Russell King (Oracle)
2023-01-12 23:40 ` Russell King (Oracle)
2023-01-12 23:45 ` Florian Westphal
2023-01-13 11:12 ` Russell King (Oracle)
2023-01-13 12:56 ` Florian Westphal [this message]
2023-01-13 13:36 ` Russell King (Oracle)
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=20230113125629.GD19463@breakpoint.cc \
--to=fw@strlen.de \
--cc=coreteam@netfilter.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@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 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.