C:\Users\Collen>netstat -a | find "5900" TCP 0.0.0.0:5900 Speleologist:0 LISTENING C:\Users\Collen>
I used windump, a free packet capture tool for Microsoft Windows systems, similar to the tcpdump tool found on OS X/macOS and Linux systems, to verify that the system was seeing the incoming connections to network port 5900.
C:\Program Files (x86)\Network\>windump port 5900
windump: listening on \Device\NPF_{B5B6E80B-A4BF-4B04-90ED-573BA531BD03}
19:05:00.749658 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,nop,wscale 5,nop,nop,timestamp 459255717 0,sackOK,eo
l>
19:05:01.739199 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,nop,wscale 5,nop,nop,timestamp 459256717 0,sackOK,eo
l>
19:05:02.737463 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,nop,wscale 5,nop,nop,timestamp 459257718 0,sackOK,eo
l>
19:05:03.746881 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,nop,wscale 5,nop,nop,timestamp 459258719 0,sackOK,eo
l>
19:05:04.741430 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,nop,wscale 5,nop,nop,timestamp 459259719 0,sackOK,eo
l>
19:05:05.759667 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,nop,wscale 5,nop,nop,timestamp 459260720 0,sackOK,eo
l>
19:05:07.759922 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,nop,wscale 5,nop,nop,timestamp 459262720 0,sackOK,eo
l>
19:05:11.776950 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,sackOK,eol>
19:05:19.770063 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,sackOK,eol>
19:05:35.784238 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,sackOK,eol>
19:06:07.793203 IP 192.168.226.54.49672 > Speleologist.5900: S 3356145059:335614
5059(0) win 65535 <mss 1360,sackOK,eol>
11 packets captured
3360 packets received by filter
0 packets dropped by kernel
C:\Program Files (x86)\Network\Monitoring>I could see the incoming packets, but I didn't see any responses from the VNC server, so I stopped and restarted the UltraVNC service. Note: if you try to stop the service from a regular command prompt rather than an administrator command prompt, you will receive the message below:
C:\Program Files (x86)\Network>net stop uvnc_service System error 5 has occurred. Access is denied. C:\Program Files (x86)\Network>
When I opened an administrator command prompt, I was able to successfully restart the service.
C:\Windows\system32>net stop uvnc_service The uvnc_service service is stopping... The uvnc_service service was stopped successfully. C:\Windows\system32>net start uvnc_service The uvnc_service service is starting. The uvnc_service service was started successfully. C:\Windows\system32>
But the same problem occurred. I.e., remote VNC connections failed and, using windump, I could see incoming packets to port 5900, but no outgoing packets. So at that point I surmised it was probably a host-based firewall issue, since the system uses the Windows Firewall. I stopped the firewall, which also has to be done from an administrator command prompt, and then attempted a remote VNC connection. That worked. When I turned the firewall back on, connectivity to port 5900 with VNC again failed.
C:\Windows\system32>netsh advfirewall set currentprofile state off Ok. C:\Windows\system32> C:\Windows\system32>netsh advfirewall set currentprofile state on Ok.
When I looked for any firewall rules referencing "vnc", I saw the following:
C:\Windows\system32>netsh advfirewall firewall show rule name=all dir=in | find /i "vnc" Rule Name: vncviewer.exe Rule Name: vncviewer.exe Rule Name: winvnc.exe Rule Name: winvnc.exe C:\Windows\system32>
Since I wasn't concerned about connectivity to the viewer application,
I looked at the rules for winvnc.exe and saw the following:
C:\Windows\system32>netsh advfirewall firewall show rule name=winvnc.exe dir=in Rule Name: winvnc.exe ---------------------------------------------------------------------- Enabled: Yes Direction: In Profiles: Private Grouping: LocalIP: Any RemoteIP: Any Protocol: UDP LocalPort: Any RemotePort: Any Edge traversal: No Action: Allow Rule Name: winvnc.exe ---------------------------------------------------------------------- Enabled: Yes Direction: In Profiles: Private Grouping: LocalIP: Any RemoteIP: Any Protocol: TCP LocalPort: Any RemotePort: Any Edge traversal: No Action: Allow Ok. C:\Windows\system32>
That revealed that there were two rules, one for TCP and the other for UDP, but both only applied to "private" network profiles. I could also see that through the graphical user interface (GUI) for managing firewall rules by selecting Control Panel, System and Security, Windows Firewall, and then Allow an app or feature through Windows Firewall.
At the prior Windows Firewall window, I could see that the system believed it was connected to a "guest or public network".
You can also see whether the Windows firewall believes you are currently
connected to a public, private, or work network using the command
netsh advfirewall show currentprofile at a command prompt.
C:\Windows\system32>netsh advfirewall show currentprofile Public Profile Settings: ---------------------------------------------------------------------- State OFF Firewall Policy BlockInbound,AllowOutbound LocalFirewallRules N/A (GPO-store only) LocalConSecRules N/A (GPO-store only) InboundUserNotification Enable RemoteManagement Disable UnicastResponseToMulticast Enable Logging: LogAllowedConnections Disable LogDroppedConnections Disable FileName %systemroot%\system32\LogFiles\Firewall\pf irewall.log MaxFileSize 4096 Ok. C:\Windows\system32>
The system had only one possible network connection. I chose to enable the firewall rules for winvnc.exe by clicking on the Change settings button at the "Allow apps to communicate through Windows Firewall" window, which then allowed me to put a check in the public check box next to winvnc.exe.
I then clicked on OK. I then re-enabled the Windows Firewall from
the command line for the current profile, which was a public profile with
the command netsh advfirewall set currentprofile state on.
Remote VNC connections then worked. They had been working previously, so,
perhaps, the system changed its view of the network after a reboot regarding
the network connection to be a public rather than private network.
