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:

quoted

Fernando Fernandez Mancera [off-list ref] wrote:

quoted

On 3/14/26 5:13 PM, Fernando Fernandez Mancera wrote:

quoted

Hi,

On 3/14/26 3:03 PM, Salvatore Bonaccorso wrote:

quoted

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