Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 "" seems to be down for nmap.

share|improve this question
Try it with the firewall fully off. – Chopper3 Apr 4 '11 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 '11 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 '13 at 9:36
up vote 3 down vote accepted

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

share|improve this answer
This helped me out. Didn't know nmap would try to use a downed NIC. – Blake Atkinson Oct 15 '12 at 16:34

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.

share|improve this answer

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.

share|improve this answer

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).

share|improve this answer

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
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.