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. On Wed, 2026-03-11 at 17:12 +0100, Salvatore Bonaccorso wrote: > Control: tags -1 + moreinfo upstream > > Hi Alejandro, > > On Wed, Mar 11, 2026 at 04:07:47PM +0100, Alejandro Oliván Alvarez > wrote: > > So, by reading git bisect final output: > > > > b29ddccf36946a90323486221f39e9f88cc01b8e is the first bad commit > > commit b29ddccf36946a90323486221f39e9f88cc01b8e > > Author: Fernando Fernandez Mancera <[email protected]> > > 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 <[email protected]> > > Signed-off-by: Pablo Neira Ayuso <[email protected]> > > Signed-off-by: Sasha Levin <[email protected]> > > > > 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 > > 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
