Re: [BUG] connlimit breaks localhost connections since 6.17.13

Fernando Fernandez Mancera <[email protected]> Fri, 9 Jan 2026 11:57:18 +0100
Newsgroups gmane.comp.security.firewalls.netfilter.general
Message-ID <[email protected]>
Hi Michal,

On 1/8/26 6:15 PM, Florian Westphal wrote:
> Michal Slabihoudek <[email protected]> wrote:
> 
> [ CC Fernando ]
> 
>> 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
> 
> We have very little test cases or real world examples, especially
> for iptables.  Hence constant breakage is expected.
> 
> Fernando, can you please have a look?
> 
>>   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.
>>

Thank you for this report, I am trying to reproduce it. If I am able to 
reproduce it I will provide a fix ASAP.

>> Best regards.