Lo! Top-posting on purpose to make this easy to process.

What happened to this regression? It looks a bit like things stalled and
fell through the cracks. Or Fernando, did you post a patch like you
mentioned? I looked for one referring the commit or the reporter, but
could not find anything -- but maybe I missed it.

Ciao, Thorsten

On 3/19/26 09:59, Fernando Fernandez Mancera wrote:

On 3/19/26 9:44 AM, Alejandro Oliván Alvarez wrote:

quoted

Hi folks.

On Wed, 2026-03-18 at 13:49 +0100, Salvatore Bonaccorso wrote:

quoted

Hi Alejandro,

On Sun, Mar 15, 2026 at 02:09:33AM +0100, Fernando Fernandez Mancera
wrote:

quoted

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@eldama
r.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/l
inux.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

The intended use of that rule was to prevent (limit) a single host from
establishing too many TCP connections to given host (Denial of
Service... particularly on streaming servers).

I learnt about it in several IPtables guides/howtos (maaaany years
ago!), and never was an issue on itself.
Was it stupid? ... possibly... It 'seemed' to work, or, at least, when
checking iptables -L -v one could see packet counter for the rule
catching some traffic, without ever noticing it being troublesome, so,
at the very least it 'didn't hurt', and, since DoS ever happened over
the years...well, I tended to think it was indeed working the way I
read it did.

Certainly, I never (the authors of those guides at their time indeed)
though about the possibility of just target the TCP syn.
I have given a try to adding the --syn option to the rule to see the
difference, and well, it is way less disruptive that way, but it still
breaks things (I saw postfix queues hanging, for instance).

The current problem with the ruleset is that it mixes both, incoming and
outgoing connections. This should probably use --syn flag so it targets
connections established against your host only.

Anyway, I am sending a patch fixing this as it makes sense to do it IMO.
We just want to understand what is the real use-case and how the ruleset
can be improved.

In addition, I would recommend you to transition to nftables because it
would be ideal for your use-case. With nftables it would be easy to
combine this with sets and probably quota expression to limit the usage.

What is wrong with the current ruleset? (Even before the blammed
commit), if you reach the connlimit limit **ALL** TCP connections will
be rejected (including legit ones), I do not think that is what you want
to achieve.

Thanks,
Fernando.

quoted

So, I have but screwed the idea of using connlimit anymore anyways.
Sorry for the noise. Lesson learned.

Cheers!