Unable to traceroute 'smtp.gmail.com'

0

I've been trying to configure my NAS to send SMTP messages, but the transmission always seems to fail. To diagnose this problem I tried traceroute'ing "smtp.gmail.com:587"...

It always fails on the second hop:

kylemart@nas:/$ sudo traceroute -n -T -p 587 smtp.gmail.com
[sudo] password for kylemart:
traceroute to smtp.gmail.com (74.125.141.109), 30 hops max, 60 byte packets
 1  192.168.143.1  0.337 ms  0.753 ms  0.771 ms
 2  66.158.XXX.XXX  1.752 ms  1.497 ms  1.758 ms
 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  * * * 

(Note: The X's were manually inserted to mask the IP address.)

Am I going about diagnosing my original problem the correct way? If so, is this an ISP-related issue? None of my devices seem to be able to traceroute "smtp.gmail.com:587" while connected to my home network, but while connected to a mobile hotspot things work fine.

kylemart

Posted 2018-04-02T09:17:11.170

Reputation: 121

Everything about this points to your ISP blocking smtp.gmail.com on port 587. – davidgo – 2018-04-02T09:23:09.527

Answers

0

This was the solution I needed: https://community.netgear.com/t5/Nighthawk-WiFi-Routers/Outbound-Mail-Blocked/m-p/1359873/highlight/true#M65452.

In short, my router was being assigned an IP address that was blacklisted from using SMTP. The ISP had apparently mapped my router's MAC address to this blacklisted IP address, so I configured my router to use a pseudo-random MAC address. This resulted in the ISP giving my router a fresh IP address, and consequently solved my problem.

EDIT: Although traceroute seems to indicate things aren't working as expected. Here's the new output:

kylemart@nas:/$ sudo traceroute -n -T -p 587 smtp.gmail.com
traceroute to smtp.gmail.com (74.125.141.108), 30 hops max, 60 byte packets
 1  192.168.143.1  0.448 ms  0.968 ms  0.999 ms
 2  66.158.177.124  2.114 ms  2.032 ms  2.072 ms
 3  208.111.0.123  2.090 ms  2.073 ms  2.057 ms
 4  208.111.12.214  5.149 ms  5.181 ms  5.119 ms
 5  65.158.121.12  13.068 ms  13.095 ms  13.077 ms
 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  * * * 

Note: The IP addresses were manually (slightly) obfuscated.

kylemart

Posted 2018-04-02T09:17:11.170

Reputation: 121

glad you got it working. that said, in relation to your question, I would not expect the behavior of the tracert to have changed just becasue you got a new IP. did it? – Frank Thomas – 2018-04-02T16:55:13.107

@FrankThomas Actually, it did change slightly. Still, it is quite surprising to me that it doesn't actually complete. I'll provide the new output in the above post. – kylemart – 2018-04-02T18:33:43.607

Tracert relies on each host in the chain being configured to emit ICMP TTL-EXCEEDED messages when the packet TTL is expired. Many networks drop expired messages silently, and in that case, the node will not appear in your output. Note that on modern networks, your traffic may take a multitude of paths, some which allow ICMP response messages, and others that don't. – Frank Thomas – 2018-04-02T19:25:41.907