I'm using Zenmap to map out the network topology of the company I'm working in. When I ran the following command to trace route how my system connects to the internet but Zenmap only shows me a single hop.

    nmap -sn --traceroute google.com

    Starting Nmap 7.70 ( https://nmap.org ) 

    Nmap scan report for google.com (

    Host is up (0.00025s latency).

    rDNS record for par10s28-in-f110.1e100.net

    TRACEROUTE (using port 80/tcp)


    1   0.00 ms par10s28-in-f110.1e100.net (

    Nmap done: 1 IP address (1 host up) scanned in 3.19 seconds

This happens regardless of what target I provide (bing, facebook or even a server I know is on a different continent). I tried running the same command directly in the cmd but that also shows the same result. Tracert command on cmd shows the correct result (ie all the hops).

I know nmap runs traceroute in a different way but I'd like to know why this happens. Also is there anyway to fix this and make it actually show the entire route and all the hops? I searched on the internet but I couldn't find a solution. This is important for building the topology diagram in zenmap.


EDIT: As per comments, I tried traceroute to IP addreess.

 nmap -sn --traceroute

Still shows the same result.

 Starting Nmap 7.70 ( https://nmap.org ) at 2018-05-24 18:13 

Nmap scan report for par10s28-in-f14.1e100.net (

Host is up (0.00025s latency).

TRACEROUTE (using port 80/tcp)


1   0.00 ms par10s28-in-f14.1e100.net (

Nmap done: 1 IP address (1 host up) scanned in 3.18 seconds

traceroute works by sending packets with a specific TTL (time to live, i.e. maximum number of hops to travel). It expects that these packets get discarded by a system on the path to the target if the TTL is reached and that this system sends an ICMP time exceeded message back.

Since your output of nmap only shows the unlikely result of you being only a single hop away from the target and a very low time to the target it is likely that some middlebox (firewall or similar) at the edge of your local network is messing with the traffic, i.e. it transparently intercepts the connection and answers it directly instead of forwarding it.

Tracert command on cmd shows the correct result (ie all the hops).

Tracert uses ICMP. According to your output your nmap is using TCP on port 80 instead:

TRACEROUTE (using port 80/tcp)

Thus the middlebox let ICMP probably pass while it handles port 80 by itself. This is a common behavior with transparent proxies on firewalls.

  • Oh. Could you please explain how the tracert command manages to show the actual hops then? Also is there any way to fix this? Like maybe force nmap to run a script that gleans result using the tracert? – Akhil May 24 '18 at 16:18
  • @Akhil: see update – Steffen Ullrich May 24 '18 at 16:28
  • That makes a lot of sense. Is there anyway to force nmap to use ICMP instead? – Akhil May 24 '18 at 16:39
  • @Akhil: There are several questions about this and from these it looks like that nmap will automatically take what it is considering as the best way. While there does not seem to exist an explicit way to force ICMP you might try to make nmap not find a better way by specifying a port which does definitely not work, i.e. something like nmap -p9999 --traceroute .... If the port is unreachable it hopefully falls back to ICMP. – Steffen Ullrich May 24 '18 at 16:46
  • I tried that. It just fell back to using 80/tcp again. But I just went through the source code (traceroute.cc) and found a solution which I shall update. Thanks a lot for explaining, :) – Akhil May 24 '18 at 16:54

From the source code of nmap traceroute (https://raw.githubusercontent.com/nmap/nmap/master/traceroute.cc)

else {
    /* No responsive probe known? The user probably skipped both ping and
       port scan. Guess ICMP echo as the most likely to get a response. */
    if (target->af() == AF_INET) {
      probe.type = PS_ICMP;
      probe.proto = IPPROTO_ICMP;
      probe.pd.icmp.type = ICMP_ECHO;
      probe.pd.icmp.code = 0;

Therefore all you have to do is use the following command.

nmap -sn -Pn --traceroute {target}

-sn is used to specify not to perform a port scan and -Pn is used to specify not to use pings.

Hope this helps the others having the same problem.

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.