Re: Bug#1130336: [regression] Network failure beyond first connection after 69894e5b4c5e ("netfilter: nft_connlimit: update the count if add was skipped")

[Salvatore Bonaccorso <carnil@debian.org>]

Hi Alejandro,

On Sun, Mar 15, 2026 at 02:09:33AM +0100, Fernando Fernandez Mancera wrote:
> On 3/14/26 8:25 PM, Florian Westphal wrote:
> > Fernando Fernandez Mancera <fmancera@suse.de> wrote:
> > > On 3/14/26 5:13 PM, Fernando Fernandez Mancera wrote:
> > > > Hi,
> > > > 
> > > > On 3/14/26 3:03 PM, Salvatore Bonaccorso wrote:
> > > > > Control: forwarded -1
> > > > > https://lore.kernel.org/ regressions/177349610461.3071718.4083978280323144323@eldamar.lan
> > > > > Control: tags -1 + upstream
> > > > > 
> > > > > Hi
> > > > > 
> > > > > In Debian, in https://bugs.debian.org/1130336, Alejandro reported that
> > > > > after updates including 69894e5b4c5e ("netfilter: nft_connlimit:
> > > > > update the count if add was skipped"), when the following rule is set
> > > > > 
> > > > >      iptables -A INPUT -p tcp -m
> > > > > connlimit --connlimit-above 111 -j
> > > > > REJECT --reject-with tcp-reset
> > > > > 
> > > > > connections get stuck accordingly, it can be easily reproduced by:
> > > > > 
> > > > > # iptables -A INPUT -p tcp -m connlimit
> > > > > --connlimit-above 111 -j REJECT
> > > > > --reject-with tcp-reset
> > > > > # nft list ruleset
> > > > > # Warning: table ip filter is managed by iptables-nft, do not touch!
> > > > > table ip filter {
> > > > >           chain INPUT {
> > > > >                   type filter hook input priority filter; policy accept;
> > > > >                   ip protocol tcp xt
> > > > > match "connlimit" counter packets 0
> > > > > bytes 0 reject with tcp reset
> > > > >           }
> > > > > }
> > > > > # wget -O /dev/null
> > > > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > > > rc3.tar.gz
> > > > > --2026-03-14 14:53:51--
> > > > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > > > rc3.tar.gz
> > > > > Resolving git.kernel.org
> > > > > (git.kernel.org)... 172.105.64.184,
> > > > > 2a01:7e01:e001:937:0:1991:8:25
> > > > > Connecting to git.kernel.org
> > > > > (git.kernel.org)|172.105.64.184|:443...
> > > > > connected.
> > > > > HTTP request sent, awaiting response... 301 Moved Permanently
> > > > > Location: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> > > > > linux.git/snapshot/linux-7.0-rc3.tar.gz
> > > > > [following]
> > > > > --2026-03-14 14:53:51--
> > > > > https://git.kernel.org/pub/scm/linux/kernel/ git/torvalds/linux.git/snapshot/linux-7.0-rc3.tar.gz
> > > > > Reusing existing connection to git.kernel.org:443.
> > > > > HTTP request sent, awaiting response... 200 OK
> > > > > Length: unspecified [application/x-gzip]
> > > > > Saving to: ‘/dev/null’
> > > > > 
> > > > > /dev/null                         [
> > > > > <=>                    ] 248.03M
> > > > > 51.9MB/s    in 5.0s
> > > > > 
> > > > > 2026-03-14 14:53:56 (49.3 MB/s) - ‘/dev/null’ saved [260080129]
> > > > > 
> > > > > # wget -O /dev/null
> > > > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > > > rc3.tar.gz
> > > > > --2026-03-14 14:53:58--
> > > > > https://git.kernel.org/torvalds/t/linux-7.0-
> > > > > rc3.tar.gz
> > > > > Resolving git.kernel.org
> > > > > (git.kernel.org)... 172.105.64.184,
> > > > > 2a01:7e01:e001:937:0:1991:8:25
> > > > > Connecting to git.kernel.org
> > > > > (git.kernel.org)|172.105.64.184|:443...
> > > > > failed: Connection timed out.
> > > > > Connecting to git.kernel.org
> > > > > (git.kernel.org)|
> > > > > 2a01:7e01:e001:937:0:1991:8:25|:443...
> > > > > failed: Network is unreachable.
> > > > > 
> > > > > Before the 69894e5b4c5e ("netfilter: nft_connlimit: update the count
> > > > > if add was skipped") commit this worked.
> > > > > 
> > > > 
> > > > Thanks for the report. I have reproduced
> > > > this on upstream kernel. I am working on it.
> > > > 
> > > 
> > > This is what is happening:
> > > 
> > > 1. The first connection is established and
> > > tracked, all good. When it finishes, it goes to
> > > TIME_WAIT state
> > > 2. The second connection is established, ct is
> > > confirmed since the beginning, skipping the
> > > tracking and calling a GC.
> > > 3. The previously tracked connection is cleaned
> > > up during GC as TIME_WAIT is considered closed.
> > 
> > This is stupid.  The fix is to add --syn or use
> > OUTPUT.  Its not even clear to me what the user wants to achive with this rule.
> > 
> 
> Yes, the ruleset shown does not make sense. Having said this, it could
> affect to a soft-limit scenario as the one described on the blamed commit..

Alejandro, can you describe what you would like to achieve with the
specific rule? 

Regards,
Salvatore