Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

iptables reject with TCP RST

460 views
Skip to first unread message

Tom Reed

unread,
May 13, 2023, 8:20:06 PM5/13/23
to
Hello

I have these iptables rules which reject tcp connections with tcp rst.

/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

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


IIRC, timeout should happen for iptables DROP action. Since I am using
REJECT, why the connect shouldn't get disconnected quickly?

Thank you.
Tom

Tom Reed

unread,
May 13, 2023, 8:30:05 PM5/13/23
to
>
> On 14/5/23 08:14, Tom Reed wrote:
>> /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
>>
>> 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
>>
>>
>> IIRC, timeout should happen for iptables DROP action. Since I am using
>> REJECT, why the connect shouldn't get disconnected quickly?
>
> There may be an earlier rule in your config that stops the REJECT rule
> being hit.
>
> check rule order with
>
> |iptables -L -n -v The other possibility is you aren't running telnet.
> netstat -tulnpW | grep 23 |
> --

Hello

I telnet to host:587 not the port 23.
And port 587 already reject access with tcp rst.

REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
reject-with tcp-reset
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
reject-with tcp-reset
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:587
reject-with tcp-reset

So what's the reason?

Thank you.

Jeremy Ardley

unread,
May 13, 2023, 8:30:05 PM5/13/23
to

On 14/5/23 08:14, Tom Reed wrote:
> /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
>
> 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
>
>
> IIRC, timeout should happen for iptables DROP action. Since I am using
> REJECT, why the connect shouldn't get disconnected quickly?

There may be an earlier rule in your config that stops the REJECT rule being hit.

check rule order with

|iptables -L -n -v The other possibility is you aren't running telnet.
netstat -tulnpW | grep 23 |
--
Jeremy
(Lists)

jeremy ardley

unread,
May 13, 2023, 8:40:06 PM5/13/23
to

On 14/5/23 08:28, Tom Reed wrote:
> I telnet to host:587 not the port 23.
> And port 587 already reject access with tcp rst.
--

check if you are listening on port 587

netstat -tulpnW | grep 587


Jeremy

Tom Reed

unread,
May 13, 2023, 8:40:06 PM5/13/23
to
yes it does.

tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN
32157/master


And the telnet results:

$ telnet 193.106.250.xx 587
Trying 193.106.250.xx...
telnet: Unable to connect to remote host: Connection timed out


Thanks

zithro

unread,
May 13, 2023, 8:51:56 PM5/13/23
to
On 14 May 2023 02:36, Tom Reed wrote:
> $ telnet 193.106.250.xx 587
> Trying 193.106.250.xx...
> telnet: Unable to connect to remote host: Connection timed out

Run wireshark/dumpcap or tcpdump on the client to check if you get the
TCP reset packet.
You can also run it server-side, to see if the server ever sends it.

Greg Wooledge

unread,
May 13, 2023, 8:51:56 PM5/13/23
to
On Sun, May 14, 2023 at 08:36:38AM +0800, Tom Reed wrote:
> tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN
> 32157/master
>
>
> And the telnet results:
>
> $ telnet 193.106.250.xx 587
> Trying 193.106.250.xx...
> telnet: Unable to connect to remote host: Connection timed out

So, it looks like it's not a LAN address. It's a mail server on the
public Internet? As in, your telnet client and your server are NOT
talking directly to each other over a straight ethernet connection?
There's routers and stuff in between them?

You'd need to investigate the possibility of a firewall-equivalent at
each hop along the way.

Tom Reed

unread,
May 13, 2023, 9:00:06 PM5/13/23
to
> On Sun, May 14, 2023 at 08:36:38AM +0800, Tom Reed wrote:
>> tcp 0 0 0.0.0.0:587 0.0.0.0:*
>> LISTEN
>> 32157/master
>>
>>
>> And the telnet results:
>>
>> $ telnet 193.106.250.xx 587
>> Trying 193.106.250.xx...
>> telnet: Unable to connect to remote host: Connection timed out
>
> So, it looks like it's not a LAN address. It's a mail server on the
> public Internet? As in, your telnet client and your server are NOT
> talking directly to each other over a straight ethernet connection?
> There's routers and stuff in between them?

Yes. my mailserver is in NYC DC, and the client host is in Dallas DC.


>
> You'd need to investigate the possibility of a firewall-equivalent at
> each hop along the way.
>

I may need tcpdump for watching the rst packages.

Thank you
Tom

Tim Woodall

unread,
May 14, 2023, 10:50:13 AM5/14/23
to
tcptraceroute might give you more clues as to where it's going wrong. In
particular I'd look at local egress rules not allowing connections to
port 587 outside of the lan.

Andy Smith

unread,
May 14, 2023, 1:02:31 PM5/14/23
to
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

Tom Reed

unread,
May 14, 2023, 9:21:05 PM5/14/23
to

>
> so whatever your 193.106.250.x host is, maybe it did indeed block
> the packets itself, but would be good to verify.
>

Hello

I have checked for details but didn't get the luck.

My destination host does have the rules:

REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
reject-with tcp-reset
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
reject-with tcp-reset
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:587
reject-with tcp-reset


And I telnet from two different DCs (one is Dallas, another is LA), both
got timeout, rather than the expected disconnection quickly.

$ telnet 193.106.250.86 587
Trying 193.106.250.86...
telnet: Unable to connect to remote host: Connection timed out


If I clean iptables in the destination host, this telnet will get success
at once.

Any hints?

Thanks.


--
sent from https://dkinbox.com/

Andy Smith

unread,
May 14, 2023, 9:31:39 PM5/14/23
to
Hello,

On Mon, May 15, 2023 at 09:10:24AM +0800, Tom Reed wrote:
> If I clean iptables in the destination host, this telnet will get success
> at once.
>
> Any hints?

Why have you not used "iptables -vL" to show the packet counts of
each rule so you can see which rules the packets match? They are
clearly matching some other earlier rule, and I suggested that in
the email you have replied to for the exact purpose of checking that
out.

Thanks,

Tom Reed

unread,
May 14, 2023, 9:51:47 PM5/14/23
to


> Hello,
>
> On Mon, May 15, 2023 at 09:10:24AM +0800, Tom Reed wrote:
>> If I clean iptables in the destination host, this telnet will get
>> success
>> at once.
>>
>> Any hints?
>
> Why have you not used "iptables -vL" to show the packet counts of
> each rule so you can see which rules the packets match? They are
> clearly matching some other earlier rule, and I suggested that in
> the email you have replied to for the exact purpose of checking that
> out.
>

Yes after each telnet from client host, the count was increased.

0 0 REJECT tcp -- any any anywhere
anywhere tcp dpt:imaps reject-with tcp-reset
0 0 REJECT tcp -- any any anywhere
anywhere tcp dpt:imap2 reject-with tcp-reset
99 4620 REJECT tcp -- any any anywhere
anywhere tcp dpt:submission reject-with tcp-reset


regards

Andy Smith

unread,
May 14, 2023, 10:10:06 PM5/14/23
to
Hello,

On Mon, May 15, 2023 at 09:40:10AM +0800, Tom Reed wrote:
> Yes after each telnet from client host, the count was increased.
>
> 0 0 REJECT tcp -- any any anywhere
> anywhere tcp dpt:imaps reject-with tcp-reset
> 0 0 REJECT tcp -- any any anywhere
> anywhere tcp dpt:imap2 reject-with tcp-reset
> 99 4620 REJECT tcp -- any any anywhere
> anywhere tcp dpt:submission reject-with tcp-reset

In that case, we must conclude that the TCP RST being sent back never
gets to your source host.

You can try a tcpdump at both ends that shows only RST packets:

# tcpdump -n -v "tcp[tcpflags] & (tcp-rst) != 0"

then when you do the telnet, do you see a packet with "Flags [R…]"
at both server side and client side?

You could also try --reject-with icmp-port-unreachable to see if
that behaves differently.
0 new messages