3

I'm trying to install and run the nmap tool to test my server, but it keeps saying

Note: Host seems down. If it is really up, but blocking our ping probes, try -P0 

and showing all the server ports are closed. Which is not true - the server is up and has lots of open ports. Any ideas?

UPDATE: Just to clarify - the server can be pinged and port-scanned fine by other programs. It's juts nmap that does not work. Even "google.com" seems to be down for nmap.

3
  • 1
    Try it with the firewall fully off.
    – Chopper3
    Apr 4, 2011 at 17:42
  • Wonder if you ever solved this? I have the same problem with nmap. (And yes, firewall is off and server is active/reachable on local network.)
    – Mike S.
    Dec 1, 2011 at 19:18
  • This question shoudl be reworded as: "unable to scan localhost under Win 7 64bit", and it should provide the nmap version and the rights of the user running nmap (e.g. admin)
    – blau
    May 20, 2013 at 9:36

5 Answers 5

5

If you have two NICs on your computer, nmap sometimes picks up the wrong routing information (for Windows, different from what route PRINT would output, compare with nmap --iflist)

You can see which interface it is picking with the -d option

The solution is to specify the correct interface with the -e option, for instance if nmap is picking eth1 whereas it should have picked eth2 you would write nmap -e eth2 ...

1
  • This helped me out. Didn't know nmap would try to use a downed NIC.
    – BeepBoop
    Oct 15, 2012 at 16:34
2

As I have the same problem on my Win 7 64-bit machine and managed to fix it, I thought I should contribute so that it could be searchable for other users.

Step 1: Do a nmap --iflist which will show you the device IP address (if any) and MAC address From there, select the interface that you will use e.g.eth2

Step 2: Then you are ready to run your scan by running:

nmap -v -O -e eth2 somehost.com
1

I have nmap working perfectly on my Windows 7 Professional 64 bit machine, so I do not believe it is the OS that is preventing nmap from properly scanning your server. Either it's a problem with your system configuration, server configuration, or network configuration.

I would recommend as a first step trying to figure out where the problem lies (workstation, network, or server). Running some form of network sniffer (e.g.: wireshark, tcpdump) on your workstation and server while the nmap scan is running might be a good first step. This will help you determine whether the network traffic from nmap is even leaving the workstation or arriving at the server. Obviously the nmap program thought it executed the scan without error, so it must have received TCP traffic back from somewhere.

Again, this is only a first step to get you going. I don't know very much about your setup to be able to make further recommendations. Good luck.

1

Some random thoughts:

I always forget that my local firewall can block outbound traffic. I think I hit this same issue with nmap. Try disabling your local firewall or creating a policy that allows all traffic out which originates from localhost.

If that isn't it then forget nmap and focus solely on getting ping to work. If ping currently doesn't work then this will help you find the point of failure.

The ports on the server might be open, but are they exposed to your source IP or network segment? They might be open only for localhost. Disable the firewall on the server for a minute to see if that helps you find where the blocking is occurring.

You said the ports on the server were open. I'm assuming you have tested this. Try a netstat -an on the server just to be certain that it's actually listening on those ports.

Is there any potential for blocking inbetween the devices? Does your traffic traverse a router, other firewall, etc?

One other random potential issue: Sometimes my apps just don't work on Win7x64 unless they're running as Admin. Even if I launch them under an account that has admin privs, I still occasionally have to right click on them and run them as administrator. Perhaps...

As @Ryan said; map out the potential choke points for your traffic and starting testing each one.

1

For anyone who's still stumbled upon this problem:

The above answer(Kaan's) works, but only in some case. There are cases I met where the default route is binded to the wrong interface, hence some will see a "cannot route" message.

Just for anyone that's getting this problem, the best course is to get the newest version (At the time of this post it is 6.25 (link), which seemed to have fixed the problem).

You must log in to answer this question.

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