How to get RealVNC VNC Server Free Edition 4.1 for Windows to work

Comodo Internet Security - CIS Firewall Help - CIS
1

Could someone kindly post a consise / step-by-step HOW-TO for getting the Comodo Firewall + Antivirus for Windows free edition to work with VNC Server?

I have tried creating a new firewall rule, named it “VNC”, source IP any, destination IP any, source port any, destination port 5900. I have set this new rule to log when it gets triggered and I do see log entries show up with a green check box icon, so I would assume that means the remote connection to VNC Server was allowed. On the remote guest machine, I never see a password prompt, and eventually guest times out and pops an error dialog.

2

You need a Global Rule as well. Read the following “tutorial” and substitute the VNC port number.

o open the port TCP 1723 for example

First step is to determine the MAC or Physical address of you network connector. Go to Start → Run → cmd → enter → a black box will show up and enter the following → ipconfig /all (notice the space before /all) → enter → now look up the Physical address and write it down.

Notice that Physical address = MAC address

Firewall → Advanced → Network Security policy → Global Rules → Add → fill in the following:
Action: Allow
Protocol: TCP
Direction: In
Description: Incoming Port

Source address: Any
Destination Address: Choose MAC address and fill in the found MAC/Physical address
Source Port: Any
Destination Port: 1723

Then push Apply → Now make sure that the new rule is somewhere above the basic block rule(s) as the bottom (the block rules have red icons); you can drag and drop the rules → Ok.

3

Aaahh, now I see the tab for Global rules, so I suspected I would soon have success.

I did not care to tie it to a specific MAC address, so I tried both Any and Zone (name of our trusted LAN zone) on the Source / Destination address tabs. Source port I have Any. Destination port I have 5900.

I set the rule to log access.

I removed the program entry for VNC server from firewall rules.

No change in attempting connections. No password prompt, and the firewall logs with a green check the event.

So I see no difference between having an Application Rule and now a Global Rule.

4

As I understand it, you will also need to allow VNC Server (as an application) to accept incoming connections… so, what worked(works) for me:

In the Network Security Policy, “Application Rules” tab, add a new rule:

For the “Application Path”, select “browse” and navigate to “C:\Program Files\RealVNC\VNC4” and select “winvnc4.exe” (the VNC Server exe). (Change as required, if you changed the default installation directory…).

Change the Network Access Rules to “Use a Predefined Policy”, and select “Trusted application”, then “Apply”. You should then see that you have a new rule, with the full path to the VNC Server exe as the application name, and “treat as” a “trusted application”…

I then moved this rule up, so it was at the top of the list of rules in the “Application Rules” window.

For security reasons, I was only allowing VNC in from other PCs in the same (local) subnet, so my network address access permissions were covered in the Global Rules, with the 2 rules “allow all incoming requests if the sender is in [local_LAN]” and “allow all outgoing requests if the target is in [local_LAN]” (which I believe were created automatically when I selected “allow this machine to see/be seen by other PCs on the same network”, when Comodo initially detected my network connection). Depending on where you you want to access the VNC Server from, I assume you may possibly require other rules, explicitly specifiying the source (IP) address from which you wish to make the connection…

HTH, P.

5

pawhe955: That basically sounds like you get success using a Application Rule, which I was using, then I learned via the suggestion above to use a Global Rule.

The fact that I have checked the “logged” box and do see “green check” log entries show up in my mind should indicate that Comodo is allowing the traffic. Yet the trouble persists. (shrug)

6

As I understood your first post, you had created a single rule based on permission of port numbers and IP addresses - and in the case of VNC, this would indeed be 5900 for default value. But that doesn’t give the VNC executable permission to use this rule - and more importantly, accept incoming connections…

As I understand it (may be wrong - always prepared to be corrected), you actually need 2 rules - a rule (can be under Global Rules) that covers the IP address/port numbers permissioning AND a rule under “Application Rules” to permit the specified executable to make outgoing connections/accept incoming connections (working in conjunction with the IP Address/Port rules). The green checks you saw in your logs possibly meant that the packet had passed the IP Address/Port rule check - but the fact that VNC was still not accepting the connections was perhaps due to VNC_Server not having the permission to actually respond…

All I can say is that I spent quite a while researching this very issue a few weeks back, and gleaned information from a number of other posts - and the upshot was this solution, which seems to work for me (on 2 or 3 local machines, all running RealVNC [or UltraVNC] and CIS v4). Did you try the Applicaiton Rule as I had written it (it was very different to the description of your original rule…), as an addition to an IP/Port based rule…??

I’ve attached screen shots of both the Application Rules and Global Rules for my Firewall config - the blanked out parts are just the ‘personalised’ name of my local network “zone” - but you can see that in the “Global Rules” I permit all traffic in/out for the specified (local subnet) Zone (i.e. the IP address/port check) and in the “Application Rules” I treat “winvnc4.exe” as trusted, so it’s allowed (as an application) to actually respond to connection requests…

If what you’ve tried so far isn’t this combination of 2 rules, it might be worth just giving it a go…

P.

[attachment deleted by admin]

7

FOUND THE PROBLEM!!! It was the built-in Windows XP firewall causing problems. I had forgotten that Comodo does not disable it when Comodo installs.

I set up a test XP machine without Comodo and still could not connect. That is when I remembered the built-in Firewall in XP.

So first I need to figure out how to be able to leave that enabled and get VNC to work, then I will circle around and tested it with Comodo.

8

Not sure if you mean that you want to get VNC working whilst Windows Firewall is enabled, then add Comodo and see if VNC still works - whilst leaving the Windows Firewall enabled?

Concensus is that you don’t run two of the same type of security products at the same time (e.g. 2 Firewalls, or 2 Anti-Virus), as they might clash for resources - as far as I am aware, most people are simply manually disabling the Windows Firewall after CIS has been successfully installed…??

9

In my mind, if Comodo wanted the Windows Firewall (the built-in one) disabled, then it would have done so during installation.

Since it did not, I will assume clients have it running and I will find a way to make it work the way I expect it to.

If OTOH it is a bad-bad-bad thing to accept default settings for that detail, please advise and I will figure out how to communicate this news to all of the Comodo installation I have done.

10

Here’s a typical discussion on this subject, from these forums:

https://forums.comodo.com/bug-report-cis/windows-firewall-not-disabled-on-install-merged-threads-t28973.0.html

…as I said, I understood concensus was that you should only run 1 firewall at a time. I guess that there are situations where running 2 doesn’t cause issues, but it sure as heck would make troubleshooting connectivity issues a lot more difficult…!!!

11

With the Windows firewall turned off, now the Comodo rule works properly and I am allowed to connect.

Next to try across our VPN to a remote site.

Thank you so much all! ;D

12

I have documented a couple of blog posts, one for basic Comodo configuration, the second specifically how to get VNC Server working.

http://www.lueckdatasystems.com/HOW-TO_Getting_started_survival_guide_for_Comodo_Free_Firewall_Antivirus_for_Windows

http://www.lueckdatasystems.com/HOW-TO_Getting_VNC_Server_to_work_with_Comodo_Free_Firewall_Antivirus_for_Windows

And BTW: No additional rules were needed to get a remote location Windows computer to allow VNC access over the VPN. In the past, ZoneAlarm needed a trusted network configured for each “other” LAN that trusted connections could be expected to come from. Comodo FW only needed the trusted LAN of that machine and connections via the LAN VPN were also trusted.

Thanks so much! 88)

13

Hi mdlueck,

I’m still a little confused, and unfortunately have not had time to do any research/testing locally, but thought I’d throw the question into the forum anyway…

Being from a Cisco (router/access-list & PIX) background, I look for a “1st rule match”, and also to erradicate duplicate rules (to reduce the size/manageablitly of acl lists).

If I look at the screen shot of your gloabl rules in the “VNC how-to”, I see (abridged):

1 - Allow all incoming requests if the sender is in “LDS LAN”
2 - VNC from LDS LAN

What I don’t understand is, rule 1 should already permit the incoming VNC connection… As far as I recall, other Firewalls allow all protocol (ICMP/IP/TCP/UDP) incoming connections when a rule has been created that defines the “local subnet”, and allows all incoming/outgoing connections to that “local subnet” (or “Zone” in the case of CIS and ZoneAlarm, etc.).

So I don’t understand why the additional rule for incoming TCP port 5900 is required?

As previously stated, my solution for the “permit incoming VNC” issue was slightly different - I did not need to add any additional rules to my global rules (which already had the "Allow all incoming requests if the sender is in “LOCAL_LAN” rule, due to my ticking “allow this computer to send/receive to/from all computers on the local network” when the local network was initially “discovered”) - but I did need to add “winvnc4.exe” as a “trusted application” in the Application Rules…

Can I ask whether, after you ticked “remember” and clicked “allow” to the “winvnc4.exe is trying to receive a connection from the Internet” alert, CIS automatically created a new “trusted application” rule in the Applications Rules?

Otherwise, could anyone comment on why they there are two different ways to achieve the same thing (when in a security product, you’d expect it’s functionality to be a little “tighter”?), and the pro’s / con’s of either method?

Thanks,

P.

14

Greetings pawhe955:

Well I am just getting comfortable with Comodo. The last Windows firewall I was comfortable with was ZoneAlarm.

It is my understanding that the Global Rule allows for port 5900 connections at all.

Then the VNC Server may receive the connection, which pops up an allow / deny box, which we chose allow.

I have not yet tried taking systems to a non-trusted zone to see if indeed VNC is blocked. I would certainly hope so.

As for Comodo’s trusted / untrusted network zones… going back to confirm which network zone was configured which was is not clear at all through the admin interface. I have not been able to find a spot to see what the status was of that one “trust other machines on this network” check box after the fact. That point remains open.

15

I wouldn’t run any VNC flavour with the standard 5800 and 5900 ports, as they are well known from robots.

Wouldn’t it be safer to customize your own ports for VNC?

16

@brucine:

From the various posts, I asume that mdlueck is using VNC in the same way as myself - that is, only letting machines from the local network have VNC access to machine on the same network… and that port 5900 incoming is still blocked at any router/gateway providing Internet connectivity. So using VNC in a small private network where I’m the admin for all machines, I stick to 5900 for simplicity…

As it happens, I do run VNC server on a couple of remote “client” machines so that I can take them over, via the Internet - and in that case, not only do I change the applicable VNC port from default to something that looks pretty random, but also ensure that the machine that the Internet gateway/router is forwarding the publically accessible (non-default) VNC port to, is not running VNC server normally - it only runs when I ask the client to launch it, and I shut down the server when I’m done with their machine… (so, for example, under “normal” circumstances a port scan would not get a response of any kind from the port I sometimes use VNC on…).

P.

17

@brucine Acknowledged… that is why I opened the ■■■■■ for a intended to allow connections only from our trusted network.

Though I prefer to stick with the standard port for now. I see doing so as “middle ground”.