Re: [BUG] connlimit breaks localhost connections since 6.17.13

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