Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
C:\Windows\system32>nmap --iflist

Starting Nmap 6.01 ( http://nmap.org ) at 2012-08-31 06:51 Central Daylight Time
************************INTERFACES************************
DEV  (SHORT) IP/MASK                      TYPE        UP   MTU  MAC
eth0 (eth0)  fe80::797f:b9b6:3ee0:27b8/64 ethernet    down 1500 5C:AC:4C:E9:2D:46
eth0 (eth0)  169.254.39.184/4             ethernet    down 1500 5C:AC:4C:E9:2D:46
eth1 (eth1)  fe80::5c02:7e48:8fbe:c7c9/64 ethernet    down 1500 00:FF:3F:7C:7C:2B
eth1 (eth1)  169.254.199.201/4            ethernet    down 1500 00:FF:3F:7C:7C:2B
eth2 (eth2)  fe80::74e4:1ab7:1b7d:a0d0/64 ethernet    up   1500 14:FE:B5:BA:8A:C3
eth2 (eth2)  10.0.0.0.253/24              ethernet    up   1500 14:FE:B5:BA:8A:C3
eth3 (eth3)  fe80::b03e:ddf5:bb5c:5f76/64 ethernet    up   1500 00:50:56:C0:00:01
eth3 (eth3)  169.254.95.118/16            ethernet    up   1500 00:50:56:C0:00:01
eth4 (eth4)  fe80::b175:831d:e60:27b/64   ethernet    up   1500 00:50:56:C0:00:08
eth4 (eth4)  192.168.153.1/24             ethernet    up   1500 00:50:56:C0:00:08
lo0  (lo0)   ::1/128                      loopback    up   -1
lo0  (lo0)   127.0.0.1/8                  loopback    up   -1
tun0 (tun0)  fe80::100:7f:fffe/64         point2point down 1280
tun1 (tun1)  (null)/0                     point2point down 1280
tun2 (tun2)  fe80::5efe:a9fe:5f76/128     point2point down 1280
tun3 (tun3)  (null)/0                     point2point down 1280
tun4 (tun4)  fe80::5efe:c0a8:9901/128     point2point down 1280
tun5 (tun5)  fe80::5efe:ac14:fd/128       point2point down 1280

DEV  WINDEVICE
eth0 \Device\NPF_{0024872A-5A41-42DF-B484-FB3D3ED3FCE9}
eth0 \Device\NPF_{0024872A-5A41-42DF-B484-FB3D3ED3FCE9}
eth1 \Device\NPF_{3F7C7C2B-9AF3-45BB-B96E-2F00143CC2F7}
eth1 \Device\NPF_{3F7C7C2B-9AF3-45BB-B96E-2F00143CC2F7}
eth2 \Device\NPF_{08116FE5-F0FF-498A-9BF1-515528C57C13}
eth2 \Device\NPF_{08116FE5-F0FF-498A-9BF1-515528C57C13}
eth3 \Device\NPF_{AA83C6CE-AB2E-4764-92D1-CDEAFBA7AD21}
eth3 \Device\NPF_{AA83C6CE-AB2E-4764-92D1-CDEAFBA7AD21}
eth4 \Device\NPF_{D0679889-E9D4-411D-BDC5-F4DDB758E151}
eth4 \Device\NPF_{D0679889-E9D4-411D-BDC5-F4DDB758E151}
lo0  <none>
lo0  <none>
tun0 <none>
tun1 <none>
tun2 <none>
tun3 <none>
tun4 <none>
tun5 <none>

**************************ROUTES**************************
DST/MASK           DEV  GATEWAY
192.168.153.255/32 eth0
255.255.255.255/32 eth0
255.255.255.255/32 eth0
127.0.0.1/32       eth0
127.255.255.255/32 eth0
255.255.255.255/32 eth0
169.254.95.118/32  eth0
169.254.255.255/32 eth0
10.0.0.0.253/32    eth0
255.255.255.255/32 eth0
10.0.0.0.255/32    eth0
255.255.255.255/32 eth0
192.168.153.1/32   eth0
255.255.255.255/32 eth0
10.0.0.0.0/24      eth0
192.168.153.0/24   eth0
10.10.10.0/24      eth0 10.0.0.0.4
169.254.0.0/16     eth0
127.0.0.0/8        eth0
224.0.0.0/4        eth0
224.0.0.0/4        eth0
224.0.0.0/4        eth0
224.0.0.0/4        eth0
224.0.0.0/4        eth0
224.0.0.0/4        eth0
0.0.0.0/0          eth0 10.0.0.0.1

JMeterX - I worded that way in hopes of raising answer efficnecy, but that probably wasnt the smartest choice. IMHO the problem (could be a symptom) is that nmap retardedly chooses eth0 as the gateway interface for any and all networks. Here's the result:

C:\Windows\system32>nmap 10.0.0.55

Starting Nmap 6.01 ( http://nmap.org ) at 2012-08-31 07:43 Central Daylight Time
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.95 seconds

C:\Windows\system32>nmap -e eth2 10.0.0.55

Starting Nmap 6.01 ( http://nmap.org ) at 2012-08-31 07:44 Central Daylight Time
Nmap scan report for esxy5.dionne.net (10.0.0.55)
Host is up (0.00070s latency).
Not shown: 991 filtered ports
PORT     STATE  SERVICE
22/tcp   open   ssh
80/tcp   open   http
427/tcp  open   svrloc
443/tcp  open   https
902/tcp  open   iss-realsecure
5988/tcp closed wbem-http
5989/tcp open   wbem-https
8000/tcp open   http-alt
8100/tcp open   xprint-server
MAC Address: 00:1F:29:59:C7:03 (Hewlett-Packard Company)

Nmap done: 1 IP address (1 host up) scanned in 5.29 seconds

Just to be clear, this is what makes absolutly no sense to me whatsoever. For reference, I've included similar info from an Ubuntu (that works normally) vm on the affected host below.

Jacked Windows 7

**************************ROUTES**************************
DST/MASK           DEV  GATEWAY
192.168.153.255/32 eth0
255.255.255.255/32 eth0
255.255.255.255/32 eth0
127.0.0.1/32       eth0
127.255.255.255/32 eth0
255.255.255.255/32 eth0
169.254.95.118/32  eth0
169.254.255.255/32 eth0
10.0.0.0.253/32    eth0
255.255.255.255/32 eth0
10.0.0.0.255/32    eth0
255.255.255.255/32 eth0
192.168.153.1/32   eth0
255.255.255.255/32 eth0
10.0.0.0.0/24      eth0
192.168.153.0/24   eth0
10.10.10.0/24      eth0 10.0.0.0.4
169.254.0.0/16     eth0
127.0.0.0/8        eth0
224.0.0.0/4        eth0
224.0.0.0/4        eth0
224.0.0.0/4        eth0
224.0.0.0/4        eth0
224.0.0.0/4        eth0
224.0.0.0/4        eth0
0.0.0.0/0          eth0 10.0.0.0.1

Working Ubuntu VM

root@ubuntu:~# nmap --iflist

Starting Nmap 5.21 ( http://nmap.org ) at 2012-08-31 07:44 PDT
************************INTERFACES************************
DEV  (SHORT) IP/MASK            TYPE     UP MAC
lo   (lo)    127.0.0.1/8        loopback up
eth0 (eth0)  172.20.0.89/24     ethernet up 00:0C:29:0A:C9:35
eth1 (eth1)  192.168.225.128/24 ethernet up 00:0C:29:0A:C9:3F
eth2 (eth2)  192.168.150.128/24 ethernet up 00:0C:29:0A:C9:49

**************************ROUTES**************************
DST/MASK        DEV  GATEWAY
192.168.225.0/0 eth1
192.168.150.0/0 eth2
172.20.0.0/0    eth0
169.254.0.0/0   eth0
0.0.0.0/0       eth0 172.20.0.1

root@ubuntu:~# nmap esxy2

Starting Nmap 5.21 ( http://nmap.org ) at 2012-08-31 07:44 PDT
Nmap scan report for esxy2 (172.20.0.52)
Host is up (0.00036s latency).
rDNS record for 172.20.0.52: esxy2.dionne.net
Not shown: 994 filtered ports
PORT     STATE  SERVICE
80/tcp   open   http
427/tcp  closed svrloc
443/tcp  open   https
902/tcp  closed iss-realsecure
8000/tcp open   http-alt
8100/tcp open   unknown
MAC Address: 00:04:23:B1:FA:6A (Intel)

Nmap done: 1 IP address (1 host up) scanned in 4.76 seconds
share|improve this question

closed as not a real question by EEAA, rnxrx, pauska, Michael Hampton, Ward Sep 24 '12 at 4:31

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Try explaining the situation maybe even ask an actual question –  JMeterX Aug 31 '12 at 12:22
    
Ip address is four digits, not five. It's 10.0.0.55 and not 10.0.0.0.55. –  Andrew Smith Aug 31 '12 at 13:15
1  
My bad, I botched a simple find/replace to mask my real ip's. I fixed it, thanks –  user30772 Aug 31 '12 at 13:30
    
See nmap.org/book/man-bugs.html for details on how to determine if the problem is a bug with nmap. –  Max Vernon Aug 31 '12 at 13:47
    
I have two Dell M6500 Win7 laptops and they both exhibit the exact same bogus behavior. If I had to guess, I think it might have something to do with the version of vcredist that get's installed by the latest VMware vSphere Client. –  user30772 Aug 31 '12 at 14:54
add comment

1 Answer

This is a known bug affecting Nmap on Windows starting from version 6. The workaround, as you discovered, is to manually specify the correct interface using the -e option.

share|improve this answer
add comment

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