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