After the "downgrade" to Parallels desktop 3.0 at least nmap stoped working correctly on the host operating system (OSX 10.4). This bug was not part of the previous version of Parallels Desktop! Using one of the guest operating systems to scan (FreeBSD 6.x), which worked quite nice with the previous version of Parallels Desktop, now results in excessive timeouts due to dropped probes. So I guess they really screwed up BIG TIME!
Nmap is not part of Mac OS X and if you installed it and it stopped working, it probably has nothing to do with Parallels. How did you conclude that this is a Parallels bug???
I built nmap v. 4.20 from source and it runs fine in my system. I verified it runs with Parallels 2.5 3214 as well as 3.0 4128. That said, there have been a few complaints regarding Parallels 3.0 and problems apparently related to the fw0 interface. I don't recall there being a resolution to the problem, and I am not able to reproduce it. I will also note that when you have installed Parallels, Fusion, and Cisco VPN you do end up with a rather tortured tcp/ip stack so I'd not be surprised to hear there are oddities for some folks.
The next update of PD 3.0 is supposed to fix the Cisco issue so that should also fix the nmap issue as they both relate to the way PD deals with the fw IP stack.
Any information of when this next update will be availble? I am very happy to alpha or beta test it, since it would fix the only major problem I am experiencing now...
The problem has indeed something to do with the fw0 interface on my macbook pro. It also only surfaces when running nmap as root (superuser) - which is necessary to use some of the more funky options. So "nmap localhost" will work flawlessly when parallels desktop 3.0 is installed, but "sudo nmap localhost" will fail with an error message mentioning the fw0 interface (which should not have been accessed at all. The previous version of parallels worked flawlessly together with nmap on OSX (executed both as a normal user and as root). That is also thereason why I am very disapointed. VMWare is no solution either because their product never worked together with nmap on OSX (all kind of wierd errors mentioning the vmnet8 interface -- also a virtual interface that I want nothing to do with when I am scanning an external / non-virtual system.
It has a lot to do with the kernel modules of parallels 3.0! I conclude this because nmap 4.20 stops working when I install parallels 3.0 and starts working again after removing parallels from the system (after a reboot).
Build 4560 nmap problems continue... After installing build 4560 and recompiling nmap 4.20 I still encounter problems. When scanning remote hosts (ie. not on the same LAN) nmap can no longer determine the correct route: # nmap -sS -v -sR -O -P0 XXX.XXXX.XXX Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-19 11:25 CEST nexthost: failed to determine route to AAA.BBB.CCC.DDD QUITTING! Name resolution works flawlessly (XXX.XXXX.XXX is hostname; AAA.BBB.CCC.DDD is correct IP-address). After uninstalling Parallels nmap works again flawlessly!!! Confused! Quuxster.
