Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #16455 > unrolled thread
| Started by | Lesley Esen <lesen@wimezu.com> |
|---|---|
| First post | 2024-10-18 11:03 -0300 |
| Last post | 2024-10-19 19:43 +0000 |
| Articles | 8 — 5 participants |
Back to article view | Back to comp.unix.programmer
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
| From | Lesley Esen <lesen@wimezu.com> |
|---|---|
| Date | 2024-10-18 11:03 -0300 |
| Subject | outgoing tcp port 25 blocked? how to prove it? |
| Message-ID | <87o73h4if7.fsf@tudado.org> |
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.
[toc] | [next] | [standalone]
| From | Winston <wbe@UBEBLOCK.psr.com.invalid> |
|---|---|
| Date | 2024-10-18 20:18 -0400 |
| Message-ID | <yded4dhrmr.fsf@UBEblock.psr.com> |
| In reply to | #16455 |
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. If you can't solve the problem directly, you may need to relay outbound mail via some AWS mail forwarder, if they have them. > 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
[toc] | [prev] | [next] | [standalone]
| From | Lesley Esen <lesen@wimezu.com> |
|---|---|
| Date | 2024-10-19 09:11 -0300 |
| Message-ID | <87plnwz40w.fsf@wimezu.com> |
| In reply to | #16456 |
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 Thanks!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-19 07:33 -0700 |
| Message-ID | <868qukw4b4.fsf@linuxsc.com> |
| In reply to | #16457 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Lesley Esen <lesen@wimezu.com> |
|---|---|
| Date | 2024-10-19 13:13 -0300 |
| Message-ID | <87h698vzop.fsf@wimezu.com> |
| In reply to | #16458 |
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!
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2024-10-19 18:40 +0000 |
| Message-ID | <vf0uem$1vs$1@gal.iecc.com> |
| In reply to | #16457 |
>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. 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, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Lesley Esen <lesen@wimezu.com> |
|---|---|
| Date | 2024-10-19 19:13 -0300 |
| Message-ID | <87bjzfwxkd.fsf@wimezu.com> |
| In reply to | #16460 |
John Levine <johnl@taugh.com> writes: >>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. > > 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!
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0009@eager.cx> |
|---|---|
| Date | 2024-10-19 19:43 +0000 |
| Message-ID | <lnigerF24ckU6@mid.individual.net> |
| In reply to | #16457 |
On Sat, 19 Oct 2024 09:11:11 -0300, Lesley Esen wrote: > 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
[toc] | [prev] | [standalone]
Back to top | Article view | comp.unix.programmer
csiph-web