Destination protocol unreachable


#1

Been having trouble getting to a site for quite some time and I ran a traceroute (tracert) on it today and I keep getting this Destination protocol unreachable error message on the final hop.

I have been in contact with the person running the site and he assures me it is not an IP ban causing the problem.

C:\Users\Wheels>tracert patrulla-azul.com

Tracing route to patrulla-azul.com [78.46.108.187]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  homeportal [***.***.*.***]
  2    25 ms    29 ms    30 ms  76-251-96-1.lightspeed.irvnca.sbcglobal.net [76.251.96.1]
  3    25 ms    24 ms    24 ms  71.147.180.57
  4    36 ms    30 ms    31 ms  12.123.30.194
  5    32 ms    37 ms    26 ms  ggr2.la2ca.ip.att.net [12.122.128.97]
  6    26 ms    27 ms    29 ms  las-bb1-link.telia.net [80.239.193.213]
  7   169 ms   219 ms   170 ms  ash-bb4-link.telia.net [62.115.137.38]
  8   186 ms   185 ms   185 ms  prs-bb3-link.telia.net [62.115.112.243]
  9   189 ms   187 ms   188 ms  ldn-bb3-link.telia.net [62.115.134.93]
 10   172 ms   180 ms   173 ms  ldn-b4-link.telia.net [62.115.134.135]
 11   204 ms   205 ms   204 ms  ldn-bb4-link.telia.net [62.115.134.138]
 12   190 ms   189 ms   189 ms  hbg-bb4-link.telia.net [62.115.122.160]
 13   186 ms   185 ms   185 ms  hbg-b1-link.telia.net [62.115.141.111]
 14   190 ms   191 ms   191 ms  hetzner-ic-326012-hbg-b1.c.telia.net [213.248.70.1]
 15   199 ms   199 ms   199 ms  core12.nbg1.hetzner.com [213.239.245.25]
 16   201 ms   201 ms   201 ms  core21.fsn1.hetzner.com [213.239.224.14]
 17   193 ms   193 ms   193 ms  ex9k2.dc3.fsn1.hetzner.com [213.239.229.242]
 18  3i-misdns.net [78.46.108.187]  reports: Destination protocol unreachable.

Trace complete.

Wheels


#2

Doesn’t look like a complete miss, just something in the protocol? Can hit both the URL and the IP just fine here.


#3

Hi Wheels

You are using the ICMP protocol to test the IP connection. While all 16 hops on the way there do talk ICMP, the server itself does not. Probably due to security reasons, at least somebody thinks this is more secure.

ICMP is also used for other things. For example signaling that fragmentation did not work on a package marked with a „don‘t fragment“ header.

So I‘d do two things:

  1. forget about traceroute or ping to analyse the issue. The test is flawed.
  2. check if your machine is setting the DF-flag or if it‘s using a smaller MTU than usual. A flaky connection can be the result of all packets exceeding a certain size to be lost.

#4

Thanks for the info. :sunglasses:
Will do some more checking this afternoon when I get back.

Wheels


#5

MTU on the router is set to 1500.

As things stand now I am not able to get to the site on multiple machines using the same router to connect to the internet. I am however able to access the site on those very same machines using a proxy server. If the problem was my hardware wouldn’t the fact I used a proxy be moot?

Wheels


#6

The site looks like it is hosted at hetzner.com on shared infrastructure. That IP address alone holds about 275 other sites. It is possible that even though the owner of patrulla-azul.com hasn’t IP blocked you, that someone else from that hosting provider may of. If you can only reach it through a proxy, then your IP might have been iptable’d blocked by someone.

Check out something like https://dnslytics.com/reverse-ip/78.46.108.187 and see what other sites use that IP.


#7

You could try to lower the MTU on your end device just to see if that makes it work. If it does, it‘s very likely that Path MTU Discovery is not working due to to ICMP being blocked somewhere. I do not recommend to set a non standard MTU in the long run, though.

It could also be a routing problem of some sort, as you say it works when proxy is handling the connection (using a different source IP address).

Whatever it is, is seems to be unlikely that you can fix the root cause by yourself. You might be able to find a way to work around it. Or you can try talking to the site operator again, if it‘s important enough for you.

Good luck!

Edit: here‘s how to check MTU in Windows 10:
netsh interface ipv4 show subinterfaces


#8

I have two Win 7 and one Win 10 computer and all three are unable to connect unless I use a proxy.

I was going to ask if this seemed to be something that needed to be fixed on their end and from what I just read that sounds like that is what will need to be done.

Wheels