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: >> 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). >> > > 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. > >> So, I have but screwed the idea of using connlimit anymore anyways. >> Sorry for the noise. Lesson learned. >> >> Cheers! > >
