Dear Maintainer,

   * What led up to the situation?
        apt-get dist-upgrade

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
        reboot to previous linux-image-6.12.41+deb13-amd64 makes networking
work again.

   * What was the outcome of this action?

        Seems like TCP connections do not work beyond the first connection.
        For example, two apt-get update commands fail on the second one:

root@marcamalaga:~# uname -r
6.12.73+deb13-amd64
root@marcamalaga:~# date
Wed Mar 11 10:22:19 AM CET 2026
root@marcamalaga:~# apt-get update
Get:1 http://security.debian.org/debian-security trixie-security InRelease
[43.4 kB]
Hit:2 http://ftp.es.debian.org/debian trixie InRelease
Get:3 http://ftp.es.debian.org/debian trixie-updates InRelease [47.3 kB]
Hit:4 https://www.deb-multimedia.org trixie InRelease
Fetched 90.7 kB in 1s (152 kB/s)
Reading package lists... Done
root@marcamalaga:~#
root@marcamalaga:~# date
Wed Mar 11 10:22:28 AM CET 2026
root@marcamalaga:~#
root@marcamalaga:~# apt-get update
Hit:1 http://security.debian.org/debian-security trixie-security InRelease
Hit:2 http://ftp.es.debian.org/debian trixie InRelease
Hit:3 http://ftp.es.debian.org/debian trixie-updates InRelease
Ign:4 https://www.deb-multimedia.org trixie InRelease
Ign:4 https://www.deb-multimedia.org trixie InRelease
Ign:4 https://www.deb-multimedia.org trixie InRelease
Err:4 https://www.deb-multimedia.org trixie InRelease
  Cannot initiate the connection to www.deb-multimedia.org:443
(2607:5300:120:e71::1). - connect (101: Network is unreachable) Could not
connect to www.deb-multimedia.org:443 (158.69.254.113), connection timed out
  Cannot initiate the connection to www.deb-multimedia.org:443
(2607:5300:120:e71::1). - connect (101: Network is unreachable)
Reading package lists... Done
W: Failed to fetch https://www.deb-multimedia.org/dists/trixie/InRelease
Cannot initiate the connection to www.deb-multimedia.org:443
(2607:5300:120:e71::1). - connect (101: Network is unreachable)
W: Some index files failed to download. They have been ignored, or old ones
used instead.
root@marcamalaga:~#

        Similarly, for illustration, here two probes of an HTTP stream, works
only once:

administrator@marcamalaga:~$ uname -r
6.12.73+deb13-amd64
administrator@marcamalaga:~$ date
Wed Mar 11 10:19:23 AM CET 2026
administrator@marcamalaga:~$ ffprobe http://10.20.10.80:8130/malagafmmobile
ffprobe version 7.1.3 Copyright (c) 2007-2025 the FFmpeg developers
  built with gcc 14 (Debian 14.2.0-19)
  configuration: --disable-decoder=amrnb --disable-gnutls --disable-liblensfun
--disable-libopencv --disable-podpages --disable-sndio --disable-stripping
--disable-omx --enable-avfilter --enable-chromaprint --enable-frei0r --enable-
gcrypt --enable-gpl --enable-ladspa --enable-libaom --enable-libaribb24
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-
libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --enable-
libdc1394 --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-
libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype
--enable-libfribidi --enable-libgme --enable-libgsm --enable-libharfbuzz
--enable-libiec61883 --enable-libilbc --enable-libjack --enable-libjxl
--enable-libklvanc --enable-libkvazaar --enable-libmp3lame --enable-libmysofa
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264
--enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo
--enable-libpulse --enable-librabbitmq --enable-librist --enable-librsvg
--enable-librubberband --enable-libshine --enable-libsmbclient --enable-
libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libsvtav1
--enable-libtesseract --enable-libtheora --enable-libtwolame --enable-
libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwebp --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs2 --enable-libxml2 --enable-libxvid --enable-libzimg
--enable-libzmq --enable-libzvbi --enable-lv2 --enable-nonfree --enable-openal
--enable-opencl --enable-opengl --enable-openssl --enable-postproc --enable-
pthreads --enable-shared --enable-version3 --incdir=/usr/include/x86_64-linux-
gnu --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --toolchain=hardened
--enable-vaapi --enable-libvpl --cc=x86_64-linux-gnu-gcc --cxx=x86_64-linux-
gnu-g++ --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu
  libavutil      59. 39.100 / 59. 39.100
  libavcodec     61. 19.101 / 61. 19.101
  libavformat    61.  7.100 / 61.  7.100
  libavdevice    61.  3.100 / 61.  3.100
  libavfilter    10.  4.100 / 10.  4.100
  libswscale      8.  3.100 /  8.  3.100
  libswresample   5.  3.100 /  5.  3.100
  libpostproc    58.  3.100 / 58.  3.100
Input #0, mp3, from 'http://10.20.10.80:8130/malagafmmobile':
  Metadata:
    icy-br          : 170
    icy-description : : Radio MARCA MA :
    icy-genre       : Sport Radio
    icy-name        : : Radio MARCA MA :
    icy-pub         : 1
    icy-url         : www.radiomarca.com
    StreamTitle     :
  Duration: N/A, start: 0.000000, bitrate: 191 kb/s
  Stream #0:0: Audio: mp3 (mp3float), 44100 Hz, stereo, fltp, 191 kb/s
administrator@marcamalaga:~$
administrator@marcamalaga:~$
administrator@marcamalaga:~$ date
Wed Mar 11 10:19:44 AM CET 2026
administrator@marcamalaga:~$ ffprobe http://10.20.10.80:8130/malagafmmobile
ffprobe version 7.1.3 Copyright (c) 2007-2025 the FFmpeg developers
  built with gcc 14 (Debian 14.2.0-19)
  configuration: --disable-decoder=amrnb --disable-gnutls --disable-liblensfun
--disable-libopencv --disable-podpages --disable-sndio --disable-stripping
--disable-omx --enable-avfilter --enable-chromaprint --enable-frei0r --enable-
gcrypt --enable-gpl --enable-ladspa --enable-libaom --enable-libaribb24
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-
libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --enable-
libdc1394 --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-
libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype
--enable-libfribidi --enable-libgme --enable-libgsm --enable-libharfbuzz
--enable-libiec61883 --enable-libilbc --enable-libjack --enable-libjxl
--enable-libklvanc --enable-libkvazaar --enable-libmp3lame --enable-libmysofa
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264
--enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo
--enable-libpulse --enable-librabbitmq --enable-librist --enable-librsvg
--enable-librubberband --enable-libshine --enable-libsmbclient --enable-
libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libsvtav1
--enable-libtesseract --enable-libtheora --enable-libtwolame --enable-
libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwebp --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs2 --enable-libxml2 --enable-libxvid --enable-libzimg
--enable-libzmq --enable-libzvbi --enable-lv2 --enable-nonfree --enable-openal
--enable-opencl --enable-opengl --enable-openssl --enable-postproc --enable-
pthreads --enable-shared --enable-version3 --incdir=/usr/include/x86_64-linux-
gnu --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --toolchain=hardened
--enable-vaapi --enable-libvpl --cc=x86_64-linux-gnu-gcc --cxx=x86_64-linux-
gnu-g++ --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu
  libavutil      59. 39.100 / 59. 39.100
  libavcodec     61. 19.101 / 61. 19.101
  libavformat    61.  7.100 / 61.  7.100
  libavdevice    61.  3.100 / 61.  3.100
  libavfilter    10.  4.100 / 10.  4.100
  libswscale      8.  3.100 /  8.  3.100
  libswresample   5.  3.100 /  5.  3.100
  libpostproc    58.  3.100 / 58.  3.100
[tcp @ 0x561036562fc0] Connection to tcp://10.20.10.80:8130 failed: Connection
timed out
http://10.20.10.80:8130/malagafmmobile: Connection timed out

        The problem happens on VIRTUAL MACHINES (PROXMOX 9 guests) using virtio
drivers.
        I have experienced same behaviour on dist-upgraded Bookworm VMs with
latest kernel.
        All VMs worked as expected and are inproduction without any issues
before dist-upgrading them.
        Machines still not dist-upgraded work flawless.
        The problem is fully consistent with kernel upgrade... just reboot to
previous kernel to resume work.

   * What outcome did you expect instead?
        Regular operation of the networking stack

Hi

I suspect this then depends on the underlaying virtualisation,
otherwise we would have I think more such reports. As you have a
fairly straightforward reproducer, can you please bisect the changes
between 6.12.41 and 6.12.73? (Ideally you test first the kernels
inbetween up to 6.12.69-1 so we have a closer range, you can get other
images earlier in the archive from the snapshots service. This should
be done as first step, because there were a a couple of releases in
Debian between 6.12.41-1 and 6.12.73-1). So assume you have 6.12.69-1
which is good, and 6.12.73-1 which is not anymore, bisecting would
involve:

    git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    cd linux-stable
    git checkout v6.12.69
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

    # test 6.12.69 to ensure this is "good"
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm problem does not exist

    # test 6.12.73 to ensure this is "bad"
    git checkout v6.12.73
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm the problem exists.

With that confirmed, the bisection can start:

    git bisect start
    git bisect good v6.12.69
    git bisect bad v6.12.73

In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:

    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install, verify if problem exists

and if the problem is hit run:

    git bisect bad

and if the problem doesn't trigger run:

    git bisect good

. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.

Iterate until git announces to have identified the first bad commit.

Then provide the output of

    git bisect log

In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.

Regards,
Salvatore

Hi Alejandro,

[please keep the Debian bug address as well in the loop, so we have
a track on progress and additionally an increased bus factoor]

Ok that is great, that reduces the search range. I update the metadata
for the bug.

Thank you, if you have issues in any of the steps, let us know please.

Regards,
Salvatore

Thank you for your help.

I think I'm on it...
Right now building for the 3rd step (6.12.58+ and 6.12.62+ tested as
good)... Presumably 8 steps remaining.
Will report when (if) I end up with that log.

Cheers.

Hi.

Here's git bisect log:

git bisect log
git bisect start
# status: waiting for both good and bad commits
# good: [8a243ecde1f6447b8e237f2c1c67c0bb67d16d67] Linux 6.12.57
git bisect good 8a243ecde1f6447b8e237f2c1c67c0bb67d16d67
# status: waiting for bad commit, 1 good commit known
# bad: [567bd8cbc2fe6b28b78864cbbbc41b0d405eb83c] Linux 6.12.63
git bisect bad 567bd8cbc2fe6b28b78864cbbbc41b0d405eb83c
# good: [850c7f0537cc5a37ed012592907920637cc548b6] x86/microcode/AMD:
Add Zen5 model 0x44, stepping 0x1 minrev
git bisect good 850c7f0537cc5a37ed012592907920637cc548b6
# good: [ad396a05d9851c0198f6246377a52b56733800cc] smack: always
"instantiate" inode in smack_inode_init_security()
git bisect good ad396a05d9851c0198f6246377a52b56733800cc
# good: [630f2ce9c7cc6797eeed06174675d295f87686a9] drm/msm/a6xx: Flush
LRZ cache before PT switch
git bisect good 630f2ce9c7cc6797eeed06174675d295f87686a9
# bad: [7c3ba62a4d29fbafd2f4f0dfe8437fcdedec6428] net: stmmac: fix rx
limit check in stmmac_rx_zc()
git bisect bad 7c3ba62a4d29fbafd2f4f0dfe8437fcdedec6428
# good: [96eab6610cb3abfbc8abdae3008984e0621e0da0] um: Don't rename
vmap to kernel_vmap
git bisect good 96eab6610cb3abfbc8abdae3008984e0621e0da0
# good: [094e8f78c6335318c9ee0862cc0d4fafa8c7c2ef] of: Skip devicetree
kunit tests when RISCV+ACPI doesn't populate root node
git bisect good 094e8f78c6335318c9ee0862cc0d4fafa8c7c2ef
# good: [5cc0fd103918c358464b1618d63736d947ad4248] ARM: dts: samsung:
universal_c210: turn off SDIO WLAN chip during system suspend
git bisect good 5cc0fd103918c358464b1618d63736d947ad4248
# good: [9a15982a2c099b25924b539e8727cfc39dbf1682] resource: replace
open coded resource_intersection()
git bisect good 9a15982a2c099b25924b539e8727cfc39dbf1682
# good: [9f953b045886c9e9add6b0e89aae555517782fa7] netfilter:
flowtable: check for maximum number of encapsulations in bridge vlan
git bisect good 9f953b045886c9e9add6b0e89aae555517782fa7
# bad: [b29ddccf36946a90323486221f39e9f88cc01b8e] netfilter:
nft_connlimit: update the count if add was skipped
git bisect bad b29ddccf36946a90323486221f39e9f88cc01b8e
# good: [3558faee8aace3541189c3a2ca45c7e85e144b44] netfilter:
nf_conncount: rework API to use sk_buff directly
git bisect good 3558faee8aace3541189c3a2ca45c7e85e144b44
# first bad commit: [b29ddccf36946a90323486221f39e9f88cc01b8e]
netfilter: nft_connlimit: update the count if add was skipped

Cheers.

So, by reading git bisect final output:

b29ddccf36946a90323486221f39e9f88cc01b8e is the first bad commit
commit b29ddccf36946a90323486221f39e9f88cc01b8e
Author: Fernando Fernandez Mancera <fmancera@suse.de>
Date:   Fri Nov 21 01:14:32 2025 +0100

    netfilter: nft_connlimit: update the count if add was skipped

    [ Upstream commit 69894e5b4c5e28cda5f32af33d4a92b7a4b93b0e ]

    Connlimit expression can be used for all kind of packets and not
only
    for packets with connection state new. See this ruleset as example:

    table ip filter {
            chain input {
                    type filter hook input priority filter; policy
accept;
                    tcp dport 22 ct count over 4 counter
            }
    }

    Currently, if the connection count goes over the limit the counter
will
    count the packets. When a connection is closed, the connection
count
    won't decrement as it should because it is only updated for new
    connections due to an optimization on __nf_conncount_add() that
prevents
    updating the list if the connection is duplicated.

    To solve this problem, check whether the connection was skipped and
if
    so, update the list. Adjust count_tree() too so the same fix is
applied
    for xt_connlimit.

    Fixes: 976afca1ceba ("netfilter: nf_conncount: Early exit in
nf_conncount_lookup() and cleanup")
    Closes:
https://lore.kernel.org/netfilter/trinity-85c72a88-d762-46c3-be97-36f10e5d9796-1761173693813@3c-app-mailcom-bs12/
    Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 net/netfilter/nf_conncount.c  | 12 ++++++++----
 net/netfilter/nft_connlimit.c | 13 +++++++++++--
 2 files changed, 19 insertions(+), 6 deletions(-)


I got the clue that the issue seems related to netfilter connection
count/track limit.
Effectively, I do use in my iptables scripts de connection limit
feature to deal with some DoS activity.


I can assert that by just commenting the following iptables line on my
scripts:

     iptables -A INPUT -p tcp -m connlimit --connlimit-above 111 -j
REJECT --reject-with tcp-reset

And reloading the rules, networking resumes working normally with
latest 6.12.73 kernel (and presumably with all of them in between).
Still, this iptables rule has worked nicely for me for years.
Not sure whether I should dismiss it from now on, since this is the
intended way for the kernel to work, or there is, indeed, something
wrong on the kernel

Cheers.

Hi Alejandro,

Thank you for having done this bisect work and identify the commit in
combination with the given rule. Might I ask you one latest test do
perform? The commit 69894e5b4c5e ("netfilter: nft_connlimit: update
the count if add was skipped") was backported from 6.19-rc1 to the
various stable series (in particular 6.18.2, 6.17.13 as well):

Can you either test 6.17.13-1~bpo13+1 from backports, and ideally as
well 6.19.6 from unstable to see if the problem reproduces htere as
well with a newer kernel which did include this change as well?

Regards,
Salvatore

Hi.

I probably will succeed installing a given kernel from backports. OTOH
I've never messed with unstable (I have never though on bring a kernel
to a stable system).

Notice though that I CAN FULLY REPRODUCE the exact same issue on
oldstable Bookworm:
Until 6.1.0-42, iptables connection limit DoS rule worked as always
did, whereas from 6.1.0-43 upgrading results in unusable networking.
commenting out the rule and reloading iptables makes networking work
again.

Will report as (if) I have something.
Cheers.

Hi Alejandro,

No need to test 6.19.6-1 explicitly, with your rule I can reproduce
the problem on my own and looks to be present as well on 6.19.6-1.

Will double-check once more and then possibly approach upstream with
your report.

Regards,
Salvatore

Hi again.

The issue is perfectly reproducible with 6.17.13+deb13-amd64 from
backports.
You can just flip on/off the issue adding/removing the firewall rule
from the chain.

At this point I'm starting to thing this may have nothing to do with
virtualisation and that, eventually, any recent system (physical or
virtual) applyng this firewall setting, or any existing system with
this firewall rule set dist-upgrading, will get their networking
screwed.

Will give a try on unstable kernel...

Thank you.
Cheers.

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

Hi,

Thanks for the report. I have reproduced this on upstream kernel. I am
working on it.

Thanks,
Fernando.

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;
  		}

Fernando Fernandez Mancera <fmancera@suse.de> wrote:

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.

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.

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.

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

Hi Alejandro,

Alejandro, can you describe what you would like to achieve with the
specific rule?

Regards,
Salvatore

Hi folks.

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!

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.

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

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

Thanks for the reminder Thorsten!

is the fix now in upstream?

Hi Fernando,

Did that happened? On a quick chek at least 7.0.13 upstream seem still
to exhibit the problem (or would it be fair to let this usecase rest?)

Regards,
Salvatore

I still have to take a fix Fernando posted.