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 -- anyany anywhere
> anywhere tcp dpt:imaps reject-with tcp-reset
> 0 0 REJECT tcp --
> 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 pac
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 ar
>
> 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/00.0.0.0/0tcp dpt:9
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 instal
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.
On Sun, 14 May 2023, Tom Reed wrote:
On Sun, May 14, 2023 at 08:36:38AM +0800, Tom Reed wrote:
tcp0 0 0.0.0.0
> On Sun, May 14, 2023 at 08:36:38AM +0800, Tom Reed wrote:
>> tcp0 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
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 ser
On Sun, May 14, 2023 at 08:36:38AM +0800, Tom Reed wrote:
> tcp0 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: Connecti
>
> 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
>
>
yes it does.
tcp0 0 0.0.0.0:587 0.0.0.0:* LI
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
>
> 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
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
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
14 matches
Mail list logo
