Hi folks. On Wed, 2026-03-18 at 13:49 +0100, Salvatore Bonaccorso wrote: > 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 <[email protected]> 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@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). So, I have but screwed the idea of using connlimit anymore anyways. Sorry for the noise. Lesson learned. Cheers!
