Traceroute will work when ICMP is blocked

ICMP traceroute

With "ping" you generally check the accessibility of a remote station, unless a firewall is obstructing the packets used. With "TraceRoute" you can also record the route of the packets from the sender to the destination. Whereby this statement has to be put into perspective. This page describes the functionality and limitations of Traceroute.


The classic "PING" command sends a packet to the remote station and waits for the answer. The data is transmitted via the IPv4 or IPv6 protocol (Layer3). On OSI Layer 4, however, Windows does not use a secure TCP connection with ports or an unsecured UDP connection, but rather the ICMP (Internet Control Message Protocol) protocol. With ICMP there are no ports or similar and in addition to the ICMP ECHO, which is used by Ping, ICMP is also used for other notifications, e.g. if a port cannot be reached (3 = destination unreachable) or packets are traveling too long ( 11 = Time Exceeded) and a few more. Even Tracert has its own type (30).

So not only one packet with a long TTL is sent to which many stations would then reply. The sender sends several packets with an ascending TTL on the journey and evaluates the "ICMP not reachable".

You can then also understand this in WireShark in the same way. But you can see here that a Windows Tracert sends each packet three times

There are three limitations to this approach:

  • Redundant paths are not unique
    The sender cannot specify the route and since the Internet is a "meshed" network, it is likely that a packet to the same destination will always take the same route, but it is not guaranteed. There are even programs that send a large number of ICMP packets to determine exactly that. It looks like this

    See also End2End-Ping
  • ICMP is blocked
    PING is an essential means to see if the IP routing is correct. However, there are still firewalls that block or falsify ICMP. With a sufficient number of pings you can of course try to create a map of the networks, routers and even reachable endpoints, which you can then investigate further. You can see it that way, but just because there are no street signs does not mean that there is any protection against burglars. However, the data here is not always reliable as you can see here.

    Of course, I can use Outlook Online, even if the traceroute (green) is struggling with dropouts. It is also interesting that the fourth hop sends an "ICMP TTL Exceeded" but does not respond to a direct PING.
  • No serviceability
    But you have already seen that a lack of availability via ICMP does not mean that the service itself cannot be reached.
  • QoS
    And of course an ICMP packet does not have the same QoS class as a VoIP or HTTP packet. In this respect, an ICMP cannot be used meaningfully for a bandwidth measurement or a throughput measurement.

The classic traceroute under Windows is therefore a tool, the results of which, however, should be evaluated with reservations.

There are more powerful programs such as Visual TraceRoute from IPSwitch, which graphically show the route and the runtimes:

Tracert with UDP / TCP

A trace route under Unix, on the other hand, uses UDP with any port that is presumably inaccessible. Here, too, the sending trace route expects the replies in the form of "ICMP TTL Expired" or an "ICMP not reachable" from the target host if nobody is listening on the addressed port.

There are even tools that use TCP ports, e.g. 80 / TCP or 443 / TCP and hope not to get stuck on firewalls. Of course, none of these tools can be used via an HTTP proxy or SOCKS proxy. In addition, the results are not always reliable here either, since an ICMP packet is sent back to an outgoing UDP / TCP packet. Here too, of course, you depend on the cooperation of the intermediate stations.

more links