CFW 5 blocks Windows Remote Desktop in local network; why?

CFW 4 (64 bit) running under Win XP x64 Pro SP2 makes the computer it is installed on invisible to requests for remote desktop connections from other computers in my LAN. I found instructions for a workaround in this archived thread for v3:
https://forums.comodo.com/help-for-v3/comodo-fw-blocking-ms-remote-desktop-on-host-computer-t23595.0.html
However, I don’t understand why this should be necessary. I told CFW on installation to allow all LAN traffic. As a result, it automatically created 2 rules, one allowing all inbound traffic from the LAN, and one allowing all outbound traffic to the LAN. Neither of these rules specify a port or protocol. Therefore I would expect CFW to allow Windows Remote Desktop along with all of the other traffic in the LAN without the need for an additional rule. What logic might explain this counter-intuitive behaviour?
Also, why is the generic permission for the local network configured as 2 separate rules, instead of a single rule allowing in/out?

P.S. Adding the rule suggested in the v3 post mentioned above still didn’t fix the problem, or maybe I didn’t interpret it correctly. I added a rule allowing In/Out on the RDP for all addresses in the LAN zone. Perhaps “invisible” is the wrong expression for what is happening. When I try to connect with Remote Desktop, I get a timeout error. It’s not clear from the error message whether or not RD “sees” the host computer.
This is a K.O. criterion for me. If I can’t get RD to work, I’ll have to find another firewall.

P.P.S In further research, I came across two threads, which suggest that this is a problem with performance rather than a problem with rule definition:
https://forums.comodo.com/firewall-help-cis/comodo-firewall-causing-very-high-pings-in-windows-7-64bit-t61798.0.html
and
https://forums.comodo.com/firewall-help-cis/massive-ping-spikespacket-drops-t61995.0.html
Two incidental bits of information, which may be relevant:

  1. Before I installed CFW, I was using Windows Firewall, with which Remote Desktop connections worked fine.
  2. During the CFW installation, at the point where the kernel drivers are installed, Windows warned me that CFW (64 bit) didn’t fulfill the “Windows Logo” certification criteria.

P.P.P.S.
BTW, the original title was erroneous. I was trying CFW 5, not 4.
Reinstalling didn’t help, adding a rule for RD port 3389 didn’t help. Since RD is a service, not an application, I wouldn’t know how to add an application rule for it, as suggested in some threads.
IAC, since no one bothers to answer here, and since the last similar thread I found (https://forums.comodo.com/empty-t57302.0.html) doesn’t report any resolution of the problem, I have given up, deinstalled CFW5 and am now using Outpost 7.0 free. It is not as sophisticated as CFW, but it is free, supports XP x64 and seems to be adequate for my needs.

Well this may be an old thread but I thought I would see if any solution has been found.

This is a description of the problem I see with Remote Desktop:

Simple problem:

I have two Windows XP SP3 machines.
I use one directly (A) and one via remote desktop (B).
Both run Comodo 5.9.221665.2197

I can connect from (A) to (B) over the LAN no problem. [192.168.x.x / 16]
However, I also have a scenario where by I connect (A) → (internet router) → (B)

The problem is as follows:
When I connect via the (internet router) I get to the standard windows XP user logon screen;
I enter correct user ID/pass and login … pause …
Then, IMMEDIATELY, the connection is lost !

The RD window briefly displays a message:
“Your session has been disconnected, reconnecting attemp #1 of 20”

The session is immediately reconnected and immediately dropped ad infinitum.

There are no error messages in Event Log.

All packets required are passed according to logs (ie. Comodo FW Log & Router Log)

As stated, I can connect over the LAN and even over VPN via the internet but when I route via my router (without VPN) I am immediately disconnected.

All ports are open as necessary, as is obvious considering I can enter login details and get to desktop before being disconnected.

Eventually I decided to disable the Comodo Firewall & Helper Driver on the Server (B) machine
and was able to login to Remote desktop via the internet router absolutely no problem.

Summary:
With Comodo installed on a WXP-SP3 Remote desktop Server and the client IP address being of an internet (routable) source (ie. Not 192.168.x.x etc rfc…) the Remote desktop connection is dropped.

Disabling Comodo on the Client PC made no difference.
Disabling Comodo on the Server PC resolved the problem.

Any news would be delightful

If I am not mistaken Windows RDP uses svchost.exe for it to function. Can you see if the Firewall logs show blocking of incoming traffic to svchost.exe around the time you are trying to connect to the other pc?

Can you also show screenshots of Global Rules and Application Rules?

I wrote a detailed reply but your forum wasted it when it told me I could not post cfgx files >:(

I can’t be bothered to rewrite it.

I have fixed the problem by re-installing comodo.

If you want to inspect my cfgx file it is atached here as a text file.

:facepalm:

[attachment deleted by admin]

The problem of remote desktop being disconnected has reared its ugly head once more …

Full details can be made available if you need them.
However, I see from searching this forum that Remote desktop continues to prove problematic.

In breif, i would like to add the following details for what they are worth.

Connecting to remote desktop using VPN works fine.

Connecting to the same remote desktop Via routed internet connection, the connection is made
and then INSTANTLY dropped.

As RDPCLIP.exe runs within the SVCHOST.exe I have also added rules to allow RDPCLIP.exe
Any IP In & Out … just in case.

I also used the “wizard” (lol), to add all networks involved in the transaction as HOME network.

It made no difference …

Remote desktop connection is made and then disconnected … ad infinitum.

Please point me to the most upto date thread concerning this issue so that I can add my
input to the best thread. If a Fix is available please let me know.

*PLEASE ADD “Follow This Post” on your forum …

If svchost.exe is involved did you adapt the rule for svchost.exe to allow incoming traffic for the required port?

You can be notified about posts to your topics in your Profile under Notifications and emails.