[BUG] connlimit breaks localhost connections since 6.17.13
Michal Slabihoudek <[email protected]> Thu, 8 Jan 2026 17:37:41 +0100
| Newsgroups | gmane.comp.security.firewalls.netfilter.general |
|---|---|
| Message-ID | <[email protected]> |
Hello netfilter maintainers,
I would like to report a regression related to the connlimit match.
Kernel versions:
• 6.17.12: working
• 6.17.13: broken
• 6.18.3: still broken
Distribution:
• CentOS Stream 9
Netfilter component:
• connlimit (iptables)
Description:
Applying an iptables rule using the connlimit module causes TCP connections
to be dropped (client observes connection timeout), even though the rule
action is LOG and not DROP/REJECT.
This happens specifically when connecting from localhost to a non-localhost
IP address (i.e. not in 127.0.0.0/8). The first connection succeeds, but
subsequent connections immediately time out.
Removing the iptables rule with the connlimit match fully resolves the issue.
Expected behavior:
• connlimit should only match and log packets
• connection handling should remain unaffected when using -j LOG
Actual behavior:
• connections are silently dropped
• client experiences TCP connection timeout
Reproducer:
Target port: TCP 443
iptables rule used (for custom logging only):
```
iptables -I INPUT -p tcp --dport 443 \
--tcp-flags FIN,SYN,RST,ACK SYN \
-m connlimit --connlimit-above 500 \
--connlimit-mask 32 --connlimit-saddr \
-j LOG --log-prefix "IPT-443: "
```
iptables ruleset:
```
Chain INPUT (policy ACCEPT)
num pkts bytes target prot opt in out source destination
1 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp dpt:443 flags:0x17/0x02 #conn src/32 > 500
LOG flags 0 level 4 prefix "IPT-443: "
```
Test case:
First connection from localhost to instance IP (X.X.X.X):
```
curl -I -L -k -m 3 https://X.X.X.X
-> HTTP/2 200 OK
```
Immediate second connection:
```
curl -I -L -k -m 3 https://X.X.X.X
-> curl: (28) Connection timed out after 3001 milliseconds
```
Without the iptables rule applied, repeated connections succeed without
any issue.
Notes:
• This looks like a regression introduced in 6.17.13
• The behavior resembles an implicit drop, despite using LOG only
• Regression might be introduced by https://github.com/torvalds/linux/commit/69894e5b4c5e28cda5f32af33d4a92b7a4b93b0e
Please let me know if further debugging data (conntrack state, traces,or kernel logs) would be helpful.
Best regards.