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

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

[Salvatore Bonaccorso]

Control: forwarded -1 https://lore.kernel.org/regressions/177349610461.3071718.4083978280323144323@eldamar.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/linux.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.

#regzbot introduced: 69894e5b4c5e28cda5f32af33d4a92b7a4b93b0e
#regzbot link: https://bugs.debian.org/1130336

Regards,
Salvatore

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

[Fernando Fernandez Mancera]

Hi,

On 3/14/26 3:03 PM, Salvatore Bonaccorso wrote:
> Control: forwarded -1 https://lore.kernel.org/regressions/177349610461.3071718.4083978280323144323@eldamar.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/linux.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.

Thanks,
Fernando.

> #regzbot introduced: 69894e5b4c5e28cda5f32af33d4a92b7a4b93b0e
> #regzbot link: https://bugs.debian.org/1130336
> 
> Regards,
> Salvatore
> 

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

[Fernando Fernandez Mancera]

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@eldamar.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/linux.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.
4. count is therefore 0 and xt performs a drop.

There are two different approaches to fix this IMHO.

The first one would be to stop considering TIME_WAIT as closed. But that 
would artificially solve the issue.

The second one is to check what is the TCP status inside the 
nf_ct_is_confirmed() check and if it is SENT or RECV but confirmed there 
are two options - ore it is a retransmission or the ct was confirmed 
even before we tracked it. In both situations, perform an insert with a 
GC. Then we make sure no duplicate tracking is happening and the 
connection is tracked properly. The following diff fixes it, what do you 
think? I can send a formal patch if this solution is considered acceptable.

diff --git a/net/netfilter/nf_conncount.c b/net/netfilter/nf_conncount.c
index 00eed5b4d1b1..ae94e5d7e00b 100644
--- a/net/netfilter/nf_conncount.c
+++ b/net/netfilter/nf_conncount.c
@@ -78,6 +78,15 @@ static inline bool already_closed(const struct 
nf_conn *conn)
  		return false;
  }

+static inline bool tcp_syn_sent_or_recv(const struct nf_conn *conn)
+{
+	if (nf_ct_protonum(conn) == IPPROTO_TCP)
+		return conn->proto.tcp.state == TCP_CONNTRACK_SYN_SENT ||
+		       conn->proto.tcp.state == TCP_CONNTRACK_SYN_RECV;
+	else
+		return false;
+}
+
  static int key_diff(const u32 *a, const u32 *b, unsigned int klen)
  {
  	return memcmp(a, b, klen * sizeof(u32));
@@ -183,6 +192,9 @@ static int __nf_conncount_add(struct net *net,
  		 * might have happened before hitting connlimit
  		 */
  		if (skb->skb_iif != LOOPBACK_IFINDEX) {
+			if (tcp_syn_sent_or_recv(ct))
+				goto check_connections;
+
  			err = -EEXIST;
  			goto out_put;
  		}

> Thanks,
> Fernando.

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

[Florian Westphal]

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@eldamar.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/linux.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.

> +static inline bool tcp_syn_sent_or_recv(const struct nf_conn *conn)
> +{
> +	if (nf_ct_protonum(conn) == IPPROTO_TCP)
> +		return conn->proto.tcp.state == TCP_CONNTRACK_SYN_SENT ||
> +		       conn->proto.tcp.state == TCP_CONNTRACK_SYN_RECV;
> +	else
> +		return false;
> +}

We're adding ever more complex checks in the conncount backend.
I don't like any of the solutions.

What about reverting the offending commit, at least for tree_count?
That way it continues to work as it did in the past.

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

[Fernando Fernandez Mancera]

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@eldamar.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/linux.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..

xt_connlimit was designed with --syn on mind but it was not enforced and 
people used it for many different things. At least, we are learning many 
people ignored --syn completely.

>> +static inline bool tcp_syn_sent_or_recv(const struct nf_conn *conn)
>> +{
>> +	if (nf_ct_protonum(conn) == IPPROTO_TCP)
>> +		return conn->proto.tcp.state == TCP_CONNTRACK_SYN_SENT ||
>> +		       conn->proto.tcp.state == TCP_CONNTRACK_SYN_RECV;
>> +	else
>> +		return false;
>> +}
> 
> We're adding ever more complex checks in the conncount backend.
> I don't like any of the solutions.
> 

As we are already fetching the ct.. would it be fine if instead we go 
for a protocol agnostic solution with:

if (ctinfo == IP_CT_NEW)
	goto check_connections;

inside the confirmed if statement? If I am not wrong, it should be a 
valid solution too and IMHO a better one.

> What about reverting the offending commit, at least for tree_count?
> That way it continues to work as it did in the past.
> 

Before the fix, soft-limiting scenarios were broken and therefore this 
specific ruleset was too. I hope this is not a ruleset in production and 
it is just for reproducing the issue.

P.S: I have been investigating on a way to improve conncount backend 
structure so the GC is not that expensive.. I don't have anything 
relevant yet but I plan to provide some updates.

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

[Salvatore Bonaccorso]

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@eldamar.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/linux.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

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

[Alejandro Oliván Alvarez]

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).

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

Cheers!

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

[Fernando Fernandez Mancera]

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!