Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.unix.programmer > #16459

Re: outgoing tcp port 25 blocked? how to prove it?

From Lesley Esen <lesen@wimezu.com>
Newsgroups comp.unix.programmer
Subject Re: outgoing tcp port 25 blocked? how to prove it?
Date 2024-10-19 13:13 -0300
Organization A noiseless patient Spider
Message-ID <87h698vzop.fsf@wimezu.com> (permalink)
References <87o73h4if7.fsf@tudado.org> <yded4dhrmr.fsf@UBEblock.psr.com> <87plnwz40w.fsf@wimezu.com> <868qukw4b4.fsf@linuxsc.com>

Show all headers | View raw


Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Lesley Esen <lesen@wimezu.com> writes:
>
>> Winston <wbe@UBEBLOCK.psr.com.invalid> writes:
>>
>>> Lesley Esen <lesen@wimezu.com> writes:
>>>
>>>> # tcpdump -n port 25
>>>> tcpdump:  verbose output suppressed, use -v or -vv for full protocol decode
>>>> listening on ena0, link-type EN10MB (Ethernet), capture size 262144 bytes
>>>> 09:01:45.939473 IP 172.26.5.226.37963 > 69.164.210.174.25:  Flags
>>>> [S], seq 1665376094, win 65535,
>>>
>>> 172.26.*.* is private, not public, IP address space.  If that's the TCP
>>> source address being sent to the remote hosts, it's not surprising
>>> you're not getting an answer.  If I'm reading your article right, the
>>> public IP address 34.197.192.71.
>>
>> That's the public IP address, yes.  This is typical on the AWS network.
>> Each instance gets a private and a public IP address.  I never see the
>> public IP address in the instance, but the packets must be being
>> rewritten by the AWS network because I can communicate with the outside
>> world just fine.
>>
>>> If you can't solve the problem directly, you may need to relay outbound
>>> mail via some AWS mail forwarder, if they have them.
>>
>> I think that's also possible.
>>
>>>> The host 69.164.210.174 also runs an SMTP server, but someone seems to
>>>> block my path to it.  It might not AWS as I also can't reach it from my
>>>> personal computer (with a dynamic IP address).
>>>
>>> Try "netstat -an4" on 69.164.210.174 to verify that the mail server is
>>> indeed listening on port 25.
>>
>> %netstat -an4 | grep 25
>> tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN
>> tcp        0      0 69.164.210.174:25       194.169.175.47:34740    TIME_WAIT
>> tcp        0      0 69.164.210.174:25       194.169.175.47:40116    TIME_WAIT
>
> Can you try running a traceroute?  I did this:
>
>     sudo traceroute -n --tcp -p 25 69.164.210.174
>
> and was able to see the path (with 13 stops along the way) from my
> colo server to 69.164.210.174.
>
> If you are being blocked I would expect the traceroute to stall
> at some point along the path.

My system is a FreeBSD, whose traceroute doesn't have the --tcp option.
But I have tcptraceroute installed.  Translating your command to
tcptraceroute, we get

%tcptraceroute -n 69.164.210.174 25
Selected device ena0, address 172.26.5.226, port 24330 for outgoing packets
Tracing the path to 69.164.210.174 on TCP port 25 (smtp), 30 hops max
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
Destination not reached

which suggests outbound tcp packets on port 25 all get dropped by the
very first router.  We get a different picture if we change ports.  Port
80, for instance.

%tcptraceroute -n 69.164.210.174 80
Selected device ena0, address 172.26.5.226, port 14076 for outgoing packets
Tracing the path to 69.164.210.174 on TCP port 80 (http), 30 hops max
 1  * * *
 2  240.0.228.98  0.333 ms  0.222 ms  0.251 ms
 3  240.3.180.9  0.870 ms  0.796 ms  0.809 ms
 4  151.148.14.42  0.630 ms  0.623 ms  0.637 ms
 5  151.148.14.43  0.989 ms  0.988 ms  0.981 ms
 6  23.209.170.106  1.450 ms  1.370 ms  1.267 ms
 7  23.209.165.97  1.301 ms  1.147 ms  1.203 ms
 8  23.32.62.58  6.151 ms  6.020 ms  6.132 ms
 9  23.203.154.41  6.807 ms  6.845 ms  6.911 ms
10  23.203.154.43  7.648 ms  7.143 ms  7.114 ms
11  * * *
12  * * *
13  * * *
14  69.164.210.174 [open]  7.649 ms  7.396 ms  7.595 ms

Despite a few grumpy routers, the path is clear.  In other words, the
evidence is that AWS really didn't open tcp 25 outbound.  I'm going to
ask them to look into it.  Thanks very much for the help!

Back to comp.unix.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

outgoing tcp port 25 blocked? how to prove it? Lesley Esen <lesen@wimezu.com> - 2024-10-18 11:03 -0300
  Re: outgoing tcp port 25 blocked? how to prove it? Winston <wbe@UBEBLOCK.psr.com.invalid> - 2024-10-18 20:18 -0400
    Re: outgoing tcp port 25 blocked? how to prove it? Lesley Esen <lesen@wimezu.com> - 2024-10-19 09:11 -0300
      Re: outgoing tcp port 25 blocked? how to prove it? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-19 07:33 -0700
        Re: outgoing tcp port 25 blocked? how to prove it? Lesley Esen <lesen@wimezu.com> - 2024-10-19 13:13 -0300
      Re: outgoing tcp port 25 blocked? how to prove it? John Levine <johnl@taugh.com> - 2024-10-19 18:40 +0000
        Re: outgoing tcp port 25 blocked? how to prove it? Lesley Esen <lesen@wimezu.com> - 2024-10-19 19:13 -0300
      Re: outgoing tcp port 25 blocked? how to prove it? Bob Eager <news0009@eager.cx> - 2024-10-19 19:43 +0000

csiph-web