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

[Fernando Fernandez Mancera <fmancera@suse.de>]

On 4/22/26 11:18 AM, Thorsten Leemhuis wrote:
> 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.
> 

Yes, it stalled and fell through the cracks. Let me prepare a fix as I 
mentioned.

Thanks for the reminder Thorsten!

> 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 <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@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!
>>
>>
> 
>