Bsrgvty

I have an IP address and can traceroute to it, but I can not ping.

You see, I can traceroute 43.224.226.50:

dele-MBP:~ ll$ traceroute 43.224.226.50
traceroute to 43.224.226.50 (43.224.226.50), 64 hops max, 52 byte packets
 1 router.asus.com (192.168.2.1) 2.082 ms 1.039 ms 0.924 ms
 2 100.64.0.1 (100.64.0.1) 3.648 ms 3.795 ms 3.955 ms
 3 118.112.212.225 (118.112.212.225) 4.252 ms 4.569 ms 4.168 ms
 4 171.208.203.73 (171.208.203.73) 6.378 ms
 171.208.198.25 (171.208.198.25) 6.943 ms
 171.208.203.61 (171.208.203.61) 7.055 ms
 5 202.97.36.225 (202.97.36.225) 38.149 ms
 202.97.36.221 (202.97.36.221) 39.949 ms
 202.97.36.225 (202.97.36.225) 40.780 ms
 6 202.97.90.158 (202.97.90.158) 37.894 ms
 202.97.94.146 (202.97.94.146) 39.885 ms 39.354 ms
 7 202.97.38.166 (202.97.38.166) 45.324 ms
 202.97.39.149 (202.97.39.149) 40.097 ms
 202.97.94.77 (202.97.94.77) 40.580 ms
 8 202.97.51.118 (202.97.51.118) 374.218 ms
 202.97.27.238 (202.97.27.238) 187.573 ms
 202.97.86.138 (202.97.86.138) 197.524 ms
 9 218.30.53.190 (218.30.53.190) 201.597 ms
 218.30.54.190 (218.30.54.190) 194.194 ms
 218.30.53.190 (218.30.53.190) 204.027 ms
10 182.54.129.91 (182.54.129.91) 220.026 ms 282.360 ms
 et-11-1-5.r01.laxus01.us.bb.bgp.net (182.54.129.38) 185.700 ms
11 182.54.129.91 (182.54.129.91) 229.700 ms 508.509 ms 266.683 ms
12 * 212.95.128.2 (212.95.128.2) 565.161 ms *
13 43.224.226.50 (43.224.226.50) 200.531 ms 201.911 ms 191.566 ms

But I can not ping it:

dele-MBP:~ ll$ ping 43.224.226.50
PING 43.224.226.50 (43.224.226.50): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11

If there is a ban on ICMP, traceroute should not work either. What's the reason for it?

I checked the server's firewall is stopped.

On a similar question here Luke Savage explained it perfectly:

Traceroute is not a protocol itself, it is an application and the protocols used depends on the implementation your are using. Primarily this is ICMP.

There are two main implementations:

tracert - tracert is a Windows application that utilises ICMP packets with as incrementing TTL field to map the hops to the final destination address.

traceroute - traceroute is a *nix application available on most Linux based systems, including network devices, and on Cisco devices. This uses UDP packets with an incrementing TTL field to map the hops to the final destination.

The difference between these is useful to know as some network now block ICMP by default so both PING and tracert from a Windows machine will fail but a traceroute from a Linux device may still work.

To add to @naïveRSA's answer, if there's filtering/firewalling in the path one could also have the situation where an ICMP "echo reply" (ping) packet is blocked, but an ICMP "time exceeded" (tracert) packet is allowed. This would give the same results even when only ICMP (Windows) is used.

In both cases (sender using either UDP or ICMP) the error communication will be ICMP (ie the node replying to a ping or tracer* packet).

Let's look at what happens, shall we?

8.8.8.8 makes a good example, because at least from my location, I can reach it both with traceroute and ping.

First let's try ping 8.8.8.8 and watch what happens:

$ tcpdump -n host 8.8.8.8 or icmp
15:36:51.045994 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 0, length 64
15:36:51.062458 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 0, length 64
15:36:52.048350 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 1, length 64
15:36:52.073657 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 1, length 64

So ping sends an ICMP echo request, and expects an ICMP echo reply.

Now traceroute -n 8.8.8.8:

15:41:31.803324 IP 10.4.27.179.44838 > 8.8.8.8.33435: UDP, length 24
15:41:31.815184 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.815343 IP 10.4.27.179.44838 > 8.8.8.8.33436: UDP, length 24
15:41:31.819654 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.819791 IP 10.4.27.179.44838 > 8.8.8.8.33437: UDP, length 24
15:41:31.824609 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.824754 IP 10.4.27.179.44838 > 8.8.8.8.33438: UDP, length 24
15:41:31.830506 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.830649 IP 10.4.27.179.44838 > 8.8.8.8.33439: UDP, length 24
15:41:31.834469 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.834565 IP 10.4.27.179.44838 > 8.8.8.8.33440: UDP, length 24
15:41:31.840962 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.841061 IP 10.4.27.179.44838 > 8.8.8.8.33441: UDP, length 24
15:41:31.847440 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.847634 IP 10.4.27.179.44838 > 8.8.8.8.33442: UDP, length 24
15:41:31.853664 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.853761 IP 10.4.27.179.44838 > 8.8.8.8.33443: UDP, length 24
15:41:31.859221 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.859269 IP 10.4.27.179.44838 > 8.8.8.8.33444: UDP, length 24
15:41:31.864149 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.864192 IP 10.4.27.179.44838 > 8.8.8.8.33445: UDP, length 24
15:41:31.870843 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.870922 IP 10.4.27.179.44838 > 8.8.8.8.33446: UDP, length 24
15:41:31.876200 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.876352 IP 10.4.27.179.44838 > 8.8.8.8.33447: UDP, length 24
15:41:31.882148 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.882249 IP 10.4.27.179.44838 > 8.8.8.8.33448: UDP, length 24
15:41:31.890076 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.890156 IP 10.4.27.179.44838 > 8.8.8.8.33449: UDP, length 24
15:41:31.896100 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.896163 IP 10.4.27.179.44838 > 8.8.8.8.33450: UDP, length 24
15:41:31.905037 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.905235 IP 10.4.27.179.44838 > 8.8.8.8.33451: UDP, length 24
15:41:31.913206 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.913283 IP 10.4.27.179.44838 > 8.8.8.8.33452: UDP, length 24
15:41:31.923428 IP 108.170.242.241 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.923520 IP 10.4.27.179.44838 > 8.8.8.8.33453: UDP, length 24
15:41:31.932266 IP 108.170.237.9 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.932441 IP 10.4.27.179.44838 > 8.8.8.8.33454: UDP, length 24
15:41:31.939961 IP 209.85.251.9 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.940043 IP 10.4.27.179.44838 > 8.8.8.8.33455: UDP, length 24
15:41:31.947460 IP 108.170.237.21 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.947508 IP 10.4.27.179.44838 > 8.8.8.8.33456: UDP, length 24
15:41:31.954824 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33456 unreachable, length 36
15:41:31.954888 IP 10.4.27.179.44838 > 8.8.8.8.33457: UDP, length 24
15:41:31.963601 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33457 unreachable, length 36
15:41:31.963671 IP 10.4.27.179.44838 > 8.8.8.8.33458: UDP, length 24
15:41:31.972407 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33458 unreachable, length 36

So traceroute, at least the implementation I have installed, doesn't send ICMP. Rather, it sends UDP packets.

What's not visible in this trace (though it would be, if I gave tcpdump a -v to increase the verbosity) is that the first probes have a ttl of 1, and then it increments the ttl for later probes. This causes the routers between me and 8.8.8.8 to respond with an ICMP ttl exceeded error, which is how traceroute discovers the routers between here and there.

Eventually the ttl is long enough to make it all the way to 8.8.8.8, and 8.8.8.8 responds with an ICMP port unreachable error, because it has no process listening on UDP port 44838. This is how traceroute knows it's reached the final destination.

If something between here and there is blocking all ICMP, then neither ping nor traceroute will work.

But it's usually not the case that all ICMP is blocked, though it's also not rare. Blocking all ICMP is problematic: for example it breaks path MTU discovery, which relies on an ICMP fragmentation required error. ICMP packets have a type and a code, and responsible network operators will only selectively block some types or codes, those that pose a potential for abuse or disclose particular information.

For example, some hosts won't respond to an ICMP echo request at all, and thus ping will not work. The idea is that by not responding to pings, it's harder for an attacker to discover what hosts exist on the network. In practice this is questionable, since there are other ways to probe for a host. For example, one can send a TCP SYN to port 80 to find webservers.

Many hosts also won't send an ICMP port unreachable error when they get a UDP datagram or a TCP SYN to a port on which they have no process listening, and this breaks traceroute. Again the idea is to make it more difficult for an attacker to map the network, but again this is only a minor frustration for an attacker.

Because traceroute is a program and not any particular protocol, it has other ways of probing. They all rely on incrementing the TTL to discover the routers, but different kinds of probes can be sent which may have more or less of a chance to elicit a response from the endpoint. For example, my man tcpdump lists an -I option to use ICMP echo probes, the same as ping. It also has -T to use TCP SYN probes instead of UDP. If you know a host will respond to ping then -I makes a lot of sense. If you know the host is listening on a particular TCP port, then -T makes sense, perhaps in conjunction with the -p option to select the port.

Unfortunately these options may require root or special capabilities, so UDP makes a fair default. In fact a similar tool, tracepath, has this to say in its man page:

DESCRIPTION

It traces path to destination discovering MTU along this path. It uses UDP port port or some random port.
It is similar to traceroute, only does not require superuser privileges and has no fancy options.

TLDR; pings can be blocked (ICMP block) on a remote host but traceroute can still find the route to it using standard network routing UDP or TCP/IP (any protocol really; ref https://networkengineering.stackexchange.com/a/36509/58968). Note that your ping can likely also reach the host (unless perhaps you have a very smart firewall blocking ICMP ping traffic somewhere), the host just does not reply.

Linux using UDP instead of ICMP for traceroute, the firewall didn't block that UDP port

You can install nmap (insecure.org) and use nping with either UDP or TCP and any port. Works great on networks with ping blocked outbound.

To ping a web server
nping --tcp -p 80,443

To ping a time server
nping --udp -p 123

https://nmap.org/book/nping-man.html