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 how my system connects to the internet, 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 any way 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.

As per comments, I tried traceroute to IP address.

 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

2 Answers 2


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.

  • That makes a lot of sense. Is there anyway to force nmap to use ICMP instead?
    – Akhil
    Commented May 24, 2018 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. Commented May 24, 2018 at 16:46

From the source code of nmap traceroute

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .