Hi, On Sun, May 14, 2023 at 08:14:04AM +0800, Tom Reed wrote: > I have these iptables rules which reject tcp connections with tcp rst.
First question, why are you using iptables instead of nft? On a new Debian install you actually are using nftables with an iptables compat layer, but a new install is a good opportunity to directly use the "nft" tool. iptables is still supported and will be for years to come, so "I don't have time to learn a new thing" is a perfectly reasonable answer, but: https://wiki.debian.org/nftables "nftables is the default and recommended firewalling framework in Debian, and it replaces the old iptables (and related) tools." > /usr/sbin/iptables -A INPUT -p tcp --dport 143 -j REJECT --reject-with > tcp-reset > /usr/sbin/iptables -A INPUT -p tcp --dport 587 -j REJECT --reject-with > tcp-reset Possibly this is implicit in the above command but I am used to also having to specify "-m tcp" first,. i.e. # iptables -A INPUT -m tcp -p tcp --dport 143 -j REJECT --reject-with tcp-reset > When I telnet from another host to the protected port, it gets timeout > message as follows. > > telnet: Unable to connect to remote host: Connection timed out Have you verified by looking at the packet counters, that apckets are actually hitting your rule? # iptables -vnL INPUT If you don't see incrementing numbers for packets and bytes next to your above rules, packets aren't hitting them and are instead being dropped somewhere in the middle. Have you verified with tcptraceroute that you can reach all the way from your client host to your machine with iptables on port 143? e.g. I used 193.106.250.1 since you obscured the IP (which only makes our task of helping you harder) but this seems to be blocked one hop after 213.200.112.170: $ sudo tcptraceroute 193.106.250.1 587 [sudo] password for andy: Selected device eth0, address 85.119.80.223, port 48267 for outgoing packets Tracing the path to 193.106.250.1 on TCP port 587 (submission), 30 hops max 1 limoncello.bitfolk.com (85.119.80.29) 0.157 ms 0.143 ms 0.440 ms 2 e3b.bitfolk.com (185.168.136.3) 1.669 ms 1.828 ms 1.542 ms 3 c5.jump.net.uk (194.153.169.140) 1.729 ms 1.625 ms 1.674 ms 4 t5.jump.net.uk (194.153.169.232) 0.535 ms 0.539 ms 0.393 ms 5 as2914.jump.net.uk (194.153.169.185) 0.827 ms 4.001 ms 7.779 ms 6 ae-14.r20.londen12.uk.bb.gin.ntt.net (129.250.3.248) 1.279 ms 0.859 ms 1.171 ms 7 ae-1.r04.londen05.uk.bb.gin.ntt.net (129.250.4.141) 1.056 ms 1.012 ms 1.240 ms 8 ae15.cr11-lon2.ip4.gtt.net (77.67.98.53) 19.353 ms 1.425 ms 0.628 ms 9 ae1.cr2-nyc4.ip4.gtt.net (213.200.112.170) 70.567 ms 69.967 ms 70.946 ms 10 * * * 11 * * * 12 *^C compare to mtr (which partially uses simple ping): $ mtr -bzwrc10 193.106.250.1 Start: 2023-05-14T16:52:01+0000 HOST: use Loss% Snt Last Avg Best Wrst StDev 1. AS8943 limoncello.bitfolk.com (85.119.80.29) 0.0% 10 0.3 0.3 0.1 1.0 0.2 2. AS??? e3b.bitfolk.com (185.168.136.3) 0.0% 10 2.2 1.8 1.6 2.2 0.2 3. AS??? c5.jump.net.uk (194.153.169.140) 0.0% 10 2.0 3.6 1.6 17.9 5.0 4. AS??? t5.jump.net.uk (194.153.169.232) 0.0% 10 0.5 1.1 0.4 4.5 1.3 5. AS??? as2914.jump.net.uk (194.153.169.185) 0.0% 10 0.6 3.1 0.6 8.5 2.8 6. AS2914 ae-14.r20.londen12.uk.bb.gin.ntt.net (129.250.3.248) 0.0% 10 1.1 1.6 0.6 4.5 1.4 7. AS2914 ae-1.r04.londen05.uk.bb.gin.ntt.net (129.250.4.141) 0.0% 10 1.2 1.2 1.0 1.7 0.2 8. AS3257 ae15.cr11-lon2.ip4.gtt.net (77.67.98.53) 20.0% 10 0.7 4.2 0.6 19.4 6.9 9. AS3257 ae1.cr2-nyc4.ip4.gtt.net (213.200.112.170) 0.0% 10 84.2 88.3 70.5 102.1 8.6 10. AS63023 193.106.250.1 0.0% 10 73.1 74.7 72.9 81.1 3.0 so whatever your 193.106.250.x host is, maybe it did indeed block the packets itself, but would be good to verify. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting