Cannot access certain web page. Ping succeded traceroute didn't

Question

This is my first question on forums at all. I work as a network support engineer and I have a little issue at work and I would really appreciate advice from you.

Cannot access the url www.reach2.org from customer side (from every other net site is available).

Ping to the site succeeded with the source of the LAN interface.

zare@cet-edgware> ping 95.142.154.194 source 185.20.63.197                     
PING 95.142.154.194 (95.142.154.194): 56 data bytes
64 bytes from 95.142.154.194: icmp_seq=0 ttl=57 time=3.176 ms
64 bytes from 95.142.154.194: icmp_seq=1 ttl=57 time=3.363 ms
64 bytes from 95.142.154.194: icmp_seq=2 ttl=57 time=3.304 ms

Traceroute to the site from source of the LAN of the CPE (juniper) fails.

zare@cet-edgware> traceroute 95.142.154.194 source 185.20.63.197
traceroute to 95.142.154.194 (95.142.154.194) from 185.20.63.197, 30 hops max, 40 byte packets
 1  172.21.2.238 (172.21.2.238)  2.699 ms  3.284 ms  3.734 ms
 2  195.66.224.109 (195.66.224.109)  4.163 ms  3.451 ms  3.734 ms
 3  195.66.225.228 (195.66.225.228)  3.932 ms  3.841 ms  3.564 ms
 4  185.52.26.134 (185.52.26.134)  3.991 ms  3.853 ms  3.913 ms
 5  185.52.26.185 (185.52.26.185)  5.343 ms  11.915 ms  5.004 ms
 6  185.52.26.180 (185.52.26.180)  7.053 ms  5.392 ms  12.536 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
^C

Traceroute to every other site failes (except to google).

The only IP address that a traceroute can be obtained is from Google. No other site has been successful.

darkoj@cet-edgware> traceroute 8.8.8.8 source 185.20.63.197 no-resolve
traceroute to 8.8.8.8 (8.8.8.8) from 185.20.63.197, 30 hops max, 40 byte packets
 1  172.21.2.238  3.081 ms  8.896 ms  3.341 ms
 2  149.6.2.198  3.179 ms  3.354 ms  2.833 ms
 3  149.6.2.197  3.777 ms  3.601 ms  3.365 ms
 4  130.117.51.210  9.562 ms  3.674 ms  3.747 ms
 5  149.14.8.150  3.756 ms  3.372 ms  3.161 ms
 6  216.239.47.23  47.197 ms 64.233.174.213  4.311 ms 64.233.174.219  10.453 ms
 7  216.239.47.101  4.202 ms 72.14.234.81  3.755 ms 209.85.245.199  5.016 ms
 8  8.8.8.8  4.376 ms  3.618 ms  3.766 m

I advised them to change the DNS to google's but no help.

I advised them to lower the MTU MSS on the device that sends the request, they advised that they lowered MTU on the server down to 1300 and same again.

I think that it is MTU/MSS issue.

Can you advise why ping succeeds and traceroute fails?

If you need any additional info please ask.

Any advice will be helpful and appreciated.

Answer 1

Ping uses ICMP, but traceroute doesn't necessarily use ICMP so different results are not necessarily unexpected. Some OSes use ICMP and some use something else like UDP.

The traceroute seems to stop in the 185.52.26.xxx network on its way to the next network. Who owns that network, the ISP? It would be beneficial to have the owner of that network see what is happening since that is where the traceroute is failing. The network to which you are trying to trace could be blocking the traceroute, too.

Both ping and traceroute use small packets, so the odds of an MTU problem are fairly small.

Notice that the trace to Google goes a completely different route. There is some sort of routing problem.

EDIT:

For what it's worth, I can't ping or trace to the website, but I can load it in my browser. That has everything to do with my router configuration.

Answer 2

I was able to ping and traceroute to your destination (95.142.154.194). I tried the default UDP traceroute, and it failed. Some routers along the path are perhaps filtering ICMP/UDP messages.

The ICMP traceroute works: traceroute -I 95.142.154.194. I suspect that either 185.52.26.180 network or 95.142.154.194 network is configured to filter ICMP/UDP packets, and that's the reason traceroute was initially failing. (FYI - the immediate next hop after 185.52.26.180 is 95.142.154.194 - this tells me there is some configuration problem in either of those networks)

Answer 3

A ping/traceroute is a good test to run, but may not provide uselful results (as with your case here). I do see that the last IP address before the trace drops (185.52.26.180) and the IP of the web server (95.142.154.194) belong to the same organization (Paragon Internet Group), But your successful pings prove that there isn't a routing issue anywhere in transit.

Try a higher level test as ping/traceroutes don't equate to trying to pull up a web page. Run telnet 95.142.154.194 80 or telnet 95.142.154.194 443 to see if traffic can reach your destination IP and port.

Given that other users are able to reach this site, and your other networks are able to reach this site, I would look closer on the CPE side for anything that may be blocking web traffic to this address.