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
