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

You see, I can traceroute

dele-MBP:~ ll$ traceroute
traceroute to (, 64 hops max, 52 byte packets
 1  router.asus.com (  2.082 ms  1.039 ms  0.924 ms
 2 (  3.648 ms  3.795 ms  3.955 ms
 3 (  4.252 ms  4.569 ms  4.168 ms
 4 (  6.378 ms (  6.943 ms (  7.055 ms
 5 (  38.149 ms (  39.949 ms (  40.780 ms
 6 (  37.894 ms (  39.885 ms  39.354 ms
 7 (  45.324 ms (  40.097 ms (  40.580 ms
 8 (  374.218 ms (  187.573 ms (  197.524 ms
 9 (  201.597 ms (  194.194 ms (  204.027 ms
10 (  220.026 ms  282.360 ms
    et-11-1-5.r01.laxus01.us.bb.bgp.net (  185.700 ms
11 (  229.700 ms  508.509 ms  266.683 ms
12  * (  565.161 ms *
13 (  200.531 ms  201.911 ms  191.566 ms

But I can not ping it:

dele-MBP:~ ll$ ping
PING ( 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.

  • can it be that the timeout for ping is too restrictive, and it would have been successful, given more lenient time limits? Traceroute gave over 500 ms for some nodes. – vsz Jun 7 '19 at 12:21
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Dec 15 '19 at 3:41

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.

From your shared output I can see that you are using traceroute command and not tracert which got me to think that you are using a Unix or GNU based operating system. In the answer I mentioned you can see that unix based systems are not using ICMP for traceroute. In other words, since PING is using ICMP (which I think is blocked by the system you are trying to reach) and traceroute is using UDP packets with an incrementation method of TTL field (which I think is not blocked at the system you are trying to reach) PING fails but Traceroute succeeds

| improve this answer | |
  • 2
    so, why my server IP can traceroute but not ping? – 244boy Jun 5 '19 at 9:25
  • 4
    Rather than add a new comment to your post when someone like 244boy suggests an improvement, it would be better to edit your post so that future people reading the answer don't have to read all the comments to get the full answer. – Keeta - reinstate Monica Jun 6 '19 at 15:03
  • @naïveRSA Strictly speaking, traceroute is using ICMP, even if it is sending UDP, namely it expects and evaluates TTL exceeded messages from the hops on the way. A host that blocks all ICMP is a bad idea, but ping will aready fail when ICMP echo requests or replies are blocked at the target host – Hagen von Eitzen Jun 7 '19 at 19:54

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).

| improve this answer | |

Let's look at what happens, shall we? makes a good example, because at least from my location, I can reach it both with traceroute and ping.

First let's try ping and watch what happens:

$ tcpdump -n host or icmp
15:36:51.045994 IP > ICMP echo request, id 7215, seq 0, length 64
15:36:51.062458 IP > ICMP echo reply, id 7215, seq 0, length 64
15:36:52.048350 IP > ICMP echo request, id 7215, seq 1, length 64
15:36:52.073657 IP > 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

15:41:31.803324 IP > UDP, length 24
15:41:31.815184 IP > ICMP time exceeded in-transit, length 36
15:41:31.815343 IP > UDP, length 24
15:41:31.819654 IP > ICMP time exceeded in-transit, length 36
15:41:31.819791 IP > UDP, length 24
15:41:31.824609 IP > ICMP time exceeded in-transit, length 36
15:41:31.824754 IP > UDP, length 24
15:41:31.830506 IP > ICMP time exceeded in-transit, length 36
15:41:31.830649 IP > UDP, length 24
15:41:31.834469 IP > ICMP time exceeded in-transit, length 36
15:41:31.834565 IP > UDP, length 24
15:41:31.840962 IP > ICMP time exceeded in-transit, length 36
15:41:31.841061 IP > UDP, length 24
15:41:31.847440 IP > ICMP time exceeded in-transit, length 148
15:41:31.847634 IP > UDP, length 24
15:41:31.853664 IP > ICMP time exceeded in-transit, length 148
15:41:31.853761 IP > UDP, length 24
15:41:31.859221 IP > ICMP time exceeded in-transit, length 148
15:41:31.859269 IP > UDP, length 24
15:41:31.864149 IP > ICMP time exceeded in-transit, length 36
15:41:31.864192 IP > UDP, length 24
15:41:31.870843 IP > ICMP time exceeded in-transit, length 36
15:41:31.870922 IP > UDP, length 24
15:41:31.876200 IP > ICMP time exceeded in-transit, length 36
15:41:31.876352 IP > UDP, length 24
15:41:31.882148 IP > ICMP time exceeded in-transit, length 36
15:41:31.882249 IP > UDP, length 24
15:41:31.890076 IP > ICMP time exceeded in-transit, length 36
15:41:31.890156 IP > UDP, length 24
15:41:31.896100 IP > ICMP time exceeded in-transit, length 36
15:41:31.896163 IP > UDP, length 24
15:41:31.905037 IP > ICMP time exceeded in-transit, length 60
15:41:31.905235 IP > UDP, length 24
15:41:31.913206 IP > ICMP time exceeded in-transit, length 60
15:41:31.913283 IP > UDP, length 24
15:41:31.923428 IP > ICMP time exceeded in-transit, length 76
15:41:31.923520 IP > UDP, length 24
15:41:31.932266 IP > ICMP time exceeded in-transit, length 60
15:41:31.932441 IP > UDP, length 24
15:41:31.939961 IP > ICMP time exceeded in-transit, length 76
15:41:31.940043 IP > UDP, length 24
15:41:31.947460 IP > ICMP time exceeded in-transit, length 60
15:41:31.947508 IP > UDP, length 24
15:41:31.954824 IP > ICMP udp port 33456 unreachable, length 36
15:41:31.954888 IP > UDP, length 24
15:41:31.963601 IP > ICMP udp port 33457 unreachable, length 36
15:41:31.963671 IP > UDP, length 24
15:41:31.972407 IP > ICMP 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 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, and 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:


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.

| improve this answer | |

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.

| improve this answer | |

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

| improve this answer | |

A brief answer to your question is that the ping utility relies on the ICMP protocol which is sometimes blocked at the network firewall or the firewall on the device itself. The most common reason why network admins block ICMP is to prevent "scanning" of the network which they consider to be a security concern. The traceroute utility on Linux uses UDP, a completely different protocol, which in this case in not blocked by the network admins. UDP has a variety of uses and blocking this would cause many things to be unusable on a network. The type of ICMP 'control message' needed by ping is a subset of a protocol which means blocking that type of ICMP packet causes less problem on a network and is therefore more likely to be blocked than UDP.

| improve this answer | |

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


| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.