I'm trying to ping the health of VM's using nmap utility.

# nmap -v -n -sP
 Host appears to be down.
 Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
 Nmap finished: 1 IP address (0 hosts up) scanned in 2.006 seconds

then I tried with direct ping, as it shows the host reachable. then I found the next hop directive in the ping output.

# ping
 PING ( 56(84) bytes of data.
 From icmp_seq=1 Redirect Host(New nexthop:
 64 bytes from icmp_seq=1 ttl=52 time=15.6 ms

Env:- RHEL 5.11 nmap version - 4.11

$ netstat -r
  Kernel IP routing table
  Destination     Gateway         Genmask         Flags   MSS Window  irtt 
  Iface      *        U         0 0          0 
  eth0     *          U         0 0          0 
  default         UG        0 0          0 


How to do it with the nmap utility? by specifying to ping host from the redirect address?

I found a similar option with fping utility --icmp-redirect-addr, likewise is there any option can specify next hop address so that nmap to scan the host properly

Note: this is production as I can only try with ping and nmap. For scanning many hosts in parallel ping took more time, so need to stick in nmap.


I don't understand.

You are asking for a ping ping to a private address in the range 192.168.x.y which is an address in one of the RFC1918 block addresses. All the addresses in a RFC1918 block should be discarded by any internet public router (such addresses are not routable).

The answer you get back comes from a public internet address From which belongs to:

$ whois
NetRange: -                                                                                               
Organization:   Wayne County Community College (WCCC-3)

That should not happen.

Futhermore, you are getting a public route Redirect Host(New nexthop: as the best route for an internal address. That answer is asking to add a new route to the local routing table.

That should be forbidden

Understand that there is no routing entry in the (local computer) route table for the local address range 192.168.x.y. As there is no routing entry, the packet gets sent to the default gateway default That router sends the packet to the next router. If the next router in in the internet cloud then this router is a "border router" and should not route packets in private ranges from RFC1918 to the wide internet.

In any case, there are at least this problems in your setup:

  • There is no route for the address range in your route table.
  • The router at (or any other border router) does not have an specific route for 192.168.x.y. It should.
  • Packets from 192.168.x.y are being routed to the internet (ping request).
  • Packets to 192.168.x.y are being routed back from the internet (ping answer).
  • You are scanning a VM at I believe that being a VM the packets should not even be sent to the local network (and then to the internet). This packets should be controlled (contained) by the VM virtual network interface.

Could you clarify?

Quoting RFC 792 (Internet Protocol).

The gateway sends a redirect message to a host in the following
situation.  A gateway, G1, receives an internet datagram from a
host on a network to which the gateway is attached.  The gateway,
G1, checks its routing table and obtains the address of the next
gateway, G2, on the route to the datagram's internet destination
network, X.  If G2 and the host identified by the internet source
address of the datagram are on the same network, a redirect
message is sent to the host.  The redirect message advises the
host to send its traffic for network X directly to gateway G2 as
this is a shorter path to the destination.  The gateway forwards
the original datagram's data to its internet destination.

In this case, G1 is (eth1:0 above), X is and G2 seems to be, and the source is in range (you did not say) (i.e. G2 and the host identified by the internet source address of the datagram are clearly NOT on the same network)

  • I gave the IP as an example, not the real one. Yea I'm trying to ping a vm which is in the same private network. – user183980 Jul 25 '18 at 11:07

How come nmap is taking less time? I can't seem to reproduce that. In your case it is giving you a lower time since it can't reach the server so those times can't be compared.

ping -c1 ip-to-check will only send one probe and will take very little time.

In your case, and according to your outputs there seems to be some routing problem, check your routes since your ping is receiving a redirection. Use traceroute to see the hops your ping goes through and check your routes.

You can try to use nmap -sn --traceroute and see if that command accepts the redirection as ping does, but the best would be to check those routes since your IPs are on a different network and the route you have established to reach your destination is being redirected as the ping command shows.

Since it is easier to see my results here I edited my post instead answering your comment:

root@Caronte:~# time ping -c1
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.127 ms

--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.127/0.127/0.127/0.000 ms

real    0m0,002s
user    0m0,000s
sys     0m0,000s
root@Caronte:~# time nmap -sn -Pn

Starting Nmap 7.40 ( https://nmap.org ) at 2018-07-25 15:25 CEST
Nmap scan report for
Host is up.
Nmap done: 1 IP address (1 host up) scanned in 0.00 seconds

real    0m0,005s
user    0m0,000s
sys     0m0,004s

As you can see, on my machine nmap takes more time than ping.

  • nmap -v -n -sP -iL <iplist> which works pretty faster than normal ping{in loop} – user183980 Jul 25 '18 at 11:08

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.