[Bug Report] VMWare NAT Interface Failure

[zwarren]

Summary:
A coworker discovered a bug where network connectivity would stop working when a particular nmap command was run on a VM using NAT. I’ve narrowed the cause of the interface going down to the g flag (which sets the source port) setting a well-known source port (1-1024) and SYN/ACK discovery scanning being used on closed ports. The network adapter stops all traffic when a SYN/ACK response is not received. This magnifies as more closed/filtered ports are queried from a well-known source port. The nmap command that originally caused this issue was using SYN scanning for host discovery as well as port scanning which compounded the problem to the point network access would drop for 20-30 minutes on all VMs using VMWare’s NAT interface. This was confirmed on VMWare Player (7.1.0) and Workstation (v11.1.3) on Windows 7 machines. This issue does not affect VMWare’s bridge interface or any VirtualBox interfaces.

Avoiding:
Don’t set source port to well-known port while on NAT.

Solutions:
1. Restart VMWare NAT service. Cannot do this without Local Admin privileges.

2. Wait 1-30 minutes and the VMWare NAT service will start properly forwarding traffic from host to guests.

3. Reboot computer

Evidence

The original script generated command:
nmap -iL tmp-target --excludefile tmp --privileged -n -PE -PS21-23,25,53,80,110-111,135,139,143,443,445,993,995,1723,3306,3389,5900,8080 -PU53,67-69,123,135,137-139,161-162,445,500,514,520,631,1434,1900,4500,49152 -sS -sU -p T:1-1040,1050,1080,1099,1125,1158,1194,1214,1220,1344,1352,1433,1500,1503,1521,1524,1526,1720,1723,1731,1812,1813,1953,1959,2000,2002,2030,2049,2100,2121,2200,2202,2222,2301,2381,2401,2433,2456,2500,2556,2628,2745,2780-2783,2947,3000,3001,3031,3121,3127,3128,3200,3201,3230-3235,3260,3268,3269,3306,3339,3389,3460,3500,3527,3632,3689,4000,4045,4100,4242,4369,4430,4443,4445,4661,4662,4711,4848,5000,5001,5009,5010,5019,5038,5040,5059,5060,5061,5101,5180,5190,5191,5192,5193,5250,5432,5554,5555,5560,5566,5631,5666,5672,5678,5800,5801,5802,5803,5804,5850,5900-6009,6101,6106,6112,6161,6346,6379,6588,6666,6667,6697,6777,7000,7001,7002,7070,7100,7210,7510,7634,7777,7778,8000,8001,8004,8005,8008,8009,8080,8081,8082,8083,8091,8098,8099,8100,8180,8181,8222,8332,8333,8383,8384,8400,8443,8444,8470-8480,8500,8787,8834,8866,8888,9090,9100,9101,9102,9160,9343,9470-9476,9480,9495,9996,9999,10000,10025,10168,11211,12000,12345,12346,13659,15000,16080,18181-18185,18207,18208,18231,18232,19150,19190,19191,20034,22226,27017,27374,27665,28784,30718,31337,32764,32768,32771,33333,35871,37172,38903,39991,39992,40096,46144,46824,49400,50000,50030,50060,50070,50075,50090,51080,51443,53050,54320,58847,60000,60010,60030,60148,60365,62078,63148,U:53,67,123,137,161,500,523,1434,1604,2302,3478,5353,6481,17185,31337 --max-retries 3 --min-rtt-timeout 100ms --max-rtt-timeout 1500ms --initial-rtt-timeout 500ms --defeat-rst-ratelimit --min-rate 450 --max-rate 15000 --open --stats-every 10s -g 53 --scan-delay 0 -oA test

Collection:
1. echo $(date); <nmap command>| grep open
2. tcpdump -nni eth0 not icmp && host <vm ip addr>
3. ping 8.8.8.8 | while read pong; do echo "$(date): $pong"; done

These will work (-sS default as root):
nmap -Pn -p 80 google.com = 1.PNG

nmap -Pn -p 1 google.com = 2.PNG

nmap -Pn -p 80 -g 53 google.com = 3.PNG

This will kill network traffic on VMWare’s NAT interface:

nmap -Pn -p 1 -g 53 google.com = 4.PNG

Add more closed ports to watch it flounder longer:

nmap -Pn -p 1,2,3,4,5,6,7,8,9,10 -g 53 google.com =5.PNG

Sincerely,

[TheHoneyBadger]

I've been having this same issue for years and had no idea what was causing it. Finally tried to see what was up and found this bug report from 2016.... I can confirm that the same nmap -g issue effects VMWare Workstation Pro 17. I would love to see this bug fixed as I use VMWare Workstation for work and scanning via nmap is something I do daily for my job.

Note:

Running VMware Workstation 17 Pro Version -- 17.0.2 build-21581411 on Window 10