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!
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)