0

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

# nmap -v -n -sP  192.168.102.116
 Host 192.168.102.116 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 192.168.102.116
 PING 192.168.102.116 (192.168.102.116) 56(84) bytes of data.
 From 192.169.64.129: icmp_seq=1 Redirect Host(New nexthop: 192.169.64.149)
 64 bytes from 192.168.102.116: 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
  10.10.2.0      *               255.255.254.0   U         0 0          0 
  eth0
  169.254.0.0     *               255.255.0.0     U         0 0          0 
  eth0
  default         10.10.2.1      0.0.0.0         UG        0 0          0 
  eth0

Question

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.

0

I don't understand.

You are asking for a ping ping 192.168.102.116 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 192.169.64.129 which belongs to:

$ whois 192.169.64.129
NetRange:       192.169.64.0 - 192.169.64.255                                                                                               
CIDR:           192.169.64.0/24
....
Organization:   Wayne County Community College (WCCC-3)
....

That should not happen.

Futhermore, you are getting a public route Redirect Host(New nexthop: 192.169.64.149) 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 10.10.2.1. 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 10.10.2.1 (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 192.168.102.116. 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 10.10.2.1 (eth1:0 above), X is 192.168.102.116 and G2 seems to be 192.169.64.129, and the source is in range (you did not say) 10.10.2.0/16 (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
0

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 10.50.1.105
PING 10.50.1.105 (10.50.1.105) 56(84) bytes of data.
64 bytes from 10.50.1.105: icmp_seq=1 ttl=64 time=0.127 ms

--- 10.50.1.105 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 10.50.1.105

Starting Nmap 7.40 ( https://nmap.org ) at 2018-07-25 15:25 CEST
Nmap scan report for 10.50.1.105
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.