Nik <nik_cro@xxxxxxxxxxxxxx> wrote: > Hello, > I have those fairly simple iptables rules: > > # Generated by iptables-save v1.6.0 on Fri Aug 2 11:38:39 2019 > *filter > :INPUT ACCEPT [4314:257355] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [15980:1820018] > -A INPUT -s xxx.xxx.xxx.xxx -j ACCEPT > -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT -p tcp -m tcp --dport 2222 -m connlimit --connlimit-above 1000 -- > connlimit-mask 0 --connlimit-saddr -j DROP > > The idea is to not allow more than a thousand concurrent connections at any > given time to the given port. To test this rule, I am sending a burst of 1200 > connections using curl. The odd part is that when I execute them locally, be > it through 127.0.0.1 or my public IP address, the limit hits and blocks as > usual, but it never seems to decrement. Once the limit is hit, it stays there > and it keeps blocking even after connections are long gone. I've let it sit > overnight in this state, and after 8 hours it was still stuck like that. > netstat resulted in no connections at any state, as expected, but still, the > connlimit rule seems like it thinks there are connections to saturate the > limit. I've tested this through an external host, and this issue doesn't > appear, as soon as connections are gone from netstat, the connlimit is not > limiting anything and allows connections to pass, as expected. I do not know > why this behaviour is present when I create the connections locally. Can't reproduce this on 5.1-stable. What kernel version are you using? What does 'conntrack -L -s 127.0.0.1' list when blocking still occurs while it should not?
