Discussion:
outgoing tcp port 25 blocked? how to prove it?
(too old to reply)
Lesley Esen
2024-10-18 14:03:40 UTC
Permalink
I've got a FreeBSD running as a Lightsail instance at AWS. I asked AWS
to create a reverse dns for my host and also lift all restrictions on
port 25. They did so: the reverse dns has been created and I can get
mails from the outside, but I can't seem to go out on TCP port 25. That
still seems blocked at least as far as the hosts I've tried to reach.
This might not have anything to do with AWS. AWS said that "[e]mail
sending limitations have also been removed for any resources for the
region your EIP is located in." I believe them.

The host 69.164.210.174 can reach my host at mx.antartida.xyz just
fine. The host mx.antartida.xyz is also named a.antartida.xyz.

%telnet mx.antartida.xyz 25
Trying 34.197.192.71...
Connected to mx.antartida.xyz.
Escape character is '^]'.
220 a.antartida.xyz ESMTP Sendmail 8.17.1/8.17.1; Fri, 18 Oct 2024 10:24:01 -0300 (-03)
help
214-2.0.0 This is sendmail version 8.17.1
214-2.0.0 Topics:
214-2.0.0 HELO EHLO MAIL RCPT DATA
214-2.0.0 RSET NOOP QUIT HELP VRFY
214-2.0.0 EXPN VERB ETRN DSN AUTH
214-2.0.0 STARTTLS
214-2.0.0 For more info use "HELP <topic>".
214-2.0.0 To report bugs in the implementation see
214-2.0.0 http://www.sendmail.org/email-addresses.html
214-2.0.0 For local information send email to Postmaster at your site.
214 2.0.0 End of HELP info
quit
221 2.0.0 a.antartida.xyz closing connection
Connection closed by foreign host.

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). Here's a tcpdump from
host mx.antartida.xyz while trying to telnet to 69.164.210.174 on port
25.

--8<-------------------------------------------------------->8---
# 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, options [mss 8961,nop,wscale 6,sackOK,TS val 3931741362 ecr 0], length 0
09:01:46.964516 IP 172.26.5.226.37963 > 69.164.210.174.25: Flags [S], seq 1665376094, win 65535, options [mss 8961,nop,wscale 6,sackOK,TS val 3931742388 ecr 0], length 0
09:01:49.164532 IP 172.26.5.226.37963 > 69.164.210.174.25: Flags [S], seq 1665376094, win 65535, options [mss 8961,nop,wscale 6,sackOK,TS val 3931744588 ecr 0], length 0
09:01:53.424248 IP 172.26.5.226.37963 > 69.164.210.174.25: Flags [S], seq 1665376094, win 65535, options [mss 8961,nop,wscale 6,sackOK,TS val 3931748848 ecr 0], length 0
09:02:01.764542 IP 172.26.5.226.37963 > 69.164.210.174.25: Flags [S], seq 1665376094, win 65535, options [mss 8961,nop,wscale 6,sackOK,TS val 3931757188 ecr 0], length 0
09:02:17.964527 IP 172.26.5.226.37963 > 69.164.210.174.25: Flags [S], seq 1665376094, win 65535, options [mss 8961,nop,wscale 6,sackOK,TS val 3931773388 ecr 0], length 0
09:02:50.164521 IP 172.26.5.226.37963 > 69.164.210.174.25: Flags [S], seq 1665376094, win 65535, options [mss 8961,nop,wscale 6,sackOK,TS val 3931805588 ecr 0], length 0
^C
7 packets captured
243 packets received by filter
0 packets dropped by kernel
--8<-------------------------------------------------------->8---

The view from host 69.164.210.174:

--8<-------------------------------------------------------->8---
# tcpdump -n host 34.197.192.71
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
--8<-------------------------------------------------------->8---

We can see TCP SYN packets being sent and none are acknowledged.

If I switch from port 25 to port 21, I can see my packets arrive (even
though there's no FTP server at 69.164.210.174).

From the Lightsail instance:

--8<-------------------------------------------------------->8---
%telnet 69.164.210.174 21
Trying 69.164.210.174...
telnet: connect to address 69.164.210.174: Connection refused
--8<-------------------------------------------------------->8---

The view from 69.164.210.174:

--8<-------------------------------------------------------->8---
# tcpdump -n port 21
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:31:04.679931 IP 34.197.192.71.43674 > 69.164.210.174.21: Flags [S], seq 2257976044, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 2164055307 ecr 0], length 0
13:31:04.679989 IP 69.164.210.174.21 > 34.197.192.71.43674: Flags [R.], seq 0, ack 2257976045, win 0, length 0
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
--8<-------------------------------------------------------->8---

I get a TCP RST back as expected. I get essentially the same output
from tcpdump at both hosts. In other words, there's no connectivity
problem between the two. It's really port 25 that's being filtered.
(Each host is also able to ping each other.)

In summary, I can get e-mails from the outside, but I can't deliver
e-mails or reach Google SMTP servers either from the host
mx.antartida.xyz. So it's not just the host 69.164.210.174 that I can't
reach.

If I try a random SMTP such as the ones for cnn.com, say, I can't reach
them from mx.antartida.xyz, but I can from host 69.164.210.174. Host
69.164.210.174 is a personal mail server running netqmail, so I'm
getting the idea that host 69.164.210.174 has good reputation enough to
talk to, say, CNN's email servers, but not mx.antartida.xyz (which is an
newly-born SMTP, just starting out in life).

So I must be blacklisted? I've looked around on the web and the queries
I've been able to issue say that I'm *not* blocked anywhere.

So I'm looking for advice on running my own mail server once again in
the complicated phase the Internet is going through. If you have any
recommendations on this, I'd appreciate hearing about it. Thank you.
Winston
2024-10-19 00:18:36 UTC
Permalink
Post by Lesley Esen
# 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.

If you can't solve the problem directly, you may need to relay outbound
mail via some AWS mail forwarder, if they have them.
Post by Lesley Esen
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. Also, if that host is behind a NAT
firewall, you may also need to configure the firewall to enable port
forwarding for port 25.
-WBE
Lesley Esen
2024-10-19 12:11:11 UTC
Permalink
Post by Winston
Post by Lesley Esen
# 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.
Post by Winston
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.
Post by Winston
Post by Lesley Esen
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

Thanks!
Tim Rentsch
2024-10-19 14:33:19 UTC
Permalink
Post by Lesley Esen
Post by Winston
Post by Lesley Esen
# 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.
Post by Winston
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.
Post by Winston
Post by Lesley Esen
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.
Lesley Esen
2024-10-19 16:13:10 UTC
Permalink
Post by Tim Rentsch
Post by Lesley Esen
Post by Winston
Post by Lesley Esen
# 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.
Post by Winston
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.
Post by Winston
Post by Lesley Esen
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
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!
John Levine
2024-10-19 18:40:22 UTC
Permalink
Post by Lesley Esen
I think that's also possible.
Post by Winston
Post by Lesley Esen
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.
I sent a message saying what the problem likely is, but since wimezu.com is
a fake address, it bounced. Too bad.
--
Regards,
John Levine, ***@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Lesley Esen
2024-10-19 22:13:38 UTC
Permalink
Post by John Levine
Post by Lesley Esen
I think that's also possible.
Post by Winston
Post by Lesley Esen
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.
I sent a message saying what the problem likely is, but since wimezu.com is
a fake address, it bounced. Too bad.
Sorry about that. I'd appreciate if you can post it here. Thank you!
Bob Eager
2024-10-19 19:43:23 UTC
Permalink
Post by Lesley Esen
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.
AS a data point ... I ran an outbound mail server on an AWS instance
(FreeBSD) for four years (I stopped because I now have fast access at
home).

It connected with a mail server run by me, though. So I wonder if it's
your ISO blocking an AWS IP range.
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Loading...