Re: [BUG] connlimit breaks localhost connections since 6.17.13

[Fernando Fernandez Mancera <fmancera@suse.de>]

On 1/9/26 11:57 AM, Fernando Fernandez Mancera wrote:
> Hi Michal,
> 
> On 1/8/26 6:15 PM, Florian Westphal wrote:
>> Michal Slabihoudek <michal.slabihoudek@gooddata.com> 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.
> 

Hi again, I have been doing some work around this issue. I have been 
able to reproduce the problem. I am testing a small fix for it. In 
addition, I couldn't reproduce this with nftables so far.

I am also wondering, what is the purpose of matching flags FIN, RST? I 
believe SYN or ACK SYN alone would be more appropriated.

Thanks,
Fernando.

>>> Best regards.
>