Untouched comodo, some apps worked, Remote Assistance won't

HI, I installed comodo firewall, and just have some questions.

I read that even if some apps are allowed in AM, like msn messenger for instance, but no rule is created in NM for it, then msnmsgr wont work. But msnmsgr is not in the AM and I have not configured anything in the NM (block rule is still at number 5), but it works just fine…

Yet I cant get remote assistance to work. Someone is sending me an invitation, but it says “could not resolve host name”.
I have the pc that is sending me the invitation’s ip address, and i’ve tried many combinations of allowing port 3389 and their ip, and moving the rules to position one, but still not connecting.
When it tries to connect, comodo doesnt ask for any confirmation either, and nothing relating to remote assistance is in the AM.

How can i set it up?



You may try going to Security/Advanced/Miscellaneous and doing two things:

  1. Uncheck the box, “Do not show alerts for applications certified by Comodo.” This will be why you’re not seeing an alert for MSN Msgr (regarding application monitor); the default network monitor rules are general enough that it will allow the outbound connection (and the inbound response is not an unsolicited inbound connection, so it will be allowed too, just like your browser). If you create an application rule specifying ports, etc, then you will find it to be blocked by the network monitor…

  2. Move Alert Frequency slider to High or Very High. OK, and reboot. Now you will see direction/ip/port/etc popups occurring. Be sure to allow svchost.exe or you may be blocked from connecting entirely. Then try your remote assistance scenario and see if you get a popup to allow. You can turn the Frequency back down later so that you’re not covered up in all sorts of popups and rules…

BTW, as I re-read your post, is the remote assistance scenario being started by your computer (thus being outbound), or is it started by the other computer (thus being inbound)? If it’s the latter, number 2 above won’t do diddly for you; we’ll need to see the logs of what is being blocked.

To do that, go to Activity/Logs, right-click an entry and select “Clear all Logs.” Then have the remote assistance scenario start again, to generate block entries. Right-click again, select “Export to HTML.” Save and reopen the file; highlight and Copy the new entries, and Paste them into the textbox of your next post. You can edit out your personal/external IP with “x” for privacy.

You might also open Network Monitor to full-screen size, capture a screenshot. Save the screenshot as an image file (jpg, gif, png) and attach to your post under Additional Options.



I’m initiating the contact(the other pc is inviting me via msn messenger, when i accept it connects from my pc and logs on to theirs).
I unchecked the box(1) and moved the slider to very high, rebooted.
when i tried connecting only messenger and helpcntre pop ups showed from comodo(chose allow for every pop up), but it didn’t connect.
When i choose allow all, it connects fine, when i set back to custom, it wont connect and comes back with a host name unresolved box.
before i set it back to custom, i cleared logs, then connected, and when i pressed ok to the error box, i saved the comodo log to html.

hope it helps.

[attachment deleted by admin]

Okay thanks, Comode…

This is you responding to the invitation:

Date/Time :2007-03-22 00:22:44
Severity :High
Reporter :Application Behavior Analysis
Description: Suspicious Behaviour (HelpCtr.exe)
Application: C:\WINDOWS\pchealth\helpctr\binaries\HelpCtr.exe
Parent: C:\WINDOWS\system32\rcimlby.exe
Protocol: TCP Out
Details: C:\Program Files\Messenger\msmsgs.exe has tried to use C:\WINDOWS\pchealth\helpctr\binaries\HelpCtr.exe through OLE Automation

This is your application connecting to the internet/remote location:

Date/Time :2007-03-22 00:22:45
Severity :High
Reporter :Application Monitor
Description: Suspicious Behaviour (HelpCtr.exe)
Application: C:\WINDOWS\pchealth\helpctr\binaries\HelpCtr.exe
Parent: C:\WINDOWS\system32\rcimlby.exe
Protocol: TCP Out
Details: C:\WINDOWS\pchealth\helpctr\binaries\HelpCtr.exe is an invisible application

You’ve got some ICMP Port Unreachable entries to a different IP, but I really don’t think those are immediately related. I could be wrong, but we’ll leave them for now.

Then you’ve got this:

Date/Time :2007-03-22 00:23:06
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP =, Port = dhcp(68))
Protocol: UDP Incoming
Reason: Network Control Rule ID = 8

Two of them to be exact, then it kind of repeats; probably a second connection attempt. The IP in blue is an internal IP address, which would likely be the IP address of the network you’re attempting to log in to; probably a business, based on the 10.x.x.x. This network is trying to assign you a DCHP lease for the network, and it’s failing (because it’s blocked). Make sense to you? If that stacks up with what you know about your remote connection, then we’ll need to create a rule to allow this (you can confirm by setting to Allow All, logging in to the remote system, and checking the ipconfig for the DHCP Server IP address…).

Here’s the thing, tho… you stated earlier that Rule ID 5 is still your default Block rule in the Network Monitor, but this is blocked by Rule ID 8, as are the ICMP entries. That says there are rules in there besides the default… Will you open Network Monitor to full-screen, capture a screenshot, save it as an image file (jpg, png, gif) and attach to your post under Additional Options.



yeah rule 8 is the block rule, because i made some rules and moved them up, i made an allow tcp/udp port 3389 rule and allow ip in out rules putting my ip as source and their ip as destination. Obviously it had no effect :slight_smile: So rule 8 in the logs is definitely the default block rule.

Ok, now, both those destination ip’s for helpctr.exe are the pc’s public ip address im trying to connect to. Their broadband internet is connected to a modem which is connected to a router which is connected to their pc(
They have done all the port forwarding etc… and like I said if i allow all in comodo, it connects fine, so there end is set up ok. They gave me the public ip address, Is that the one i should have asked for? I can ask them for another ip if i need too.

I’m really not sure what the address is, and where that is in the chain, and whether its their modem or router or pc thats getting blocked by comodo.

thanks again

No, the public IP is what you need in order to start the connection. Once you establish the connection, though, your computer becomes (temporarily) an extension of their network, operating as if it is a workstation attached to the server you gained access through. You will show up in Terminal Services as a user on the server. Which would mean at that point (I think) that their system would assign you a LAN IP address to match their system. That’s what I think the blocked 10.x.x.x address relates to. But if they’re saying the LAN IP range is 192.x.x.x, something strange is happening.

A couple options.

Temporarily set the FW to Allow All, and log in remotely to their system. Go to Start/Run, type “cmd”. At the DOS prompt, type “ipconfig /all”. See what the address of their DHCP Server is; if it’s 10.x.x.x you’re good to go. That’s option 1.

Option 2 is to create a rule in Network Monitor, as follows (make sure it is ABOVE the bottom Block All rule):

Action: Allow
Protocol: UDP
Direction: In
Source IP: Single IP:
Destination IP: Any
Source Port: Single Port: 67
Destination Port: Single Port: 68

OKay, and reboot computer. Then try to connect to the remote system. If it works, you’re good to go.

I’d personally do Option 2 first; this doesn’t create the security issue (however temporary), and relates specifically to the logs created during the activity.


okay, I’ll try option 2 when i get to test it with them again.
But i removed all other rules i made for their public ip and port 3389, do i have to make rules for them again too, or just your rule?

I also returned alert level, and the certified comodo alerts back to default.
I dont really need them on again do I?


Just one more thing, I decided to do a trace route, and it turn out that the ip is the first hop…
so why would it only block when doing remote connection?
and i guess its safe to allow.

Tracing route to www.l.google.com []
over a maximum of 30 hops:

1 8 ms 8 ms 7 ms

Trace complete.

Rules: Depends on what you had. I’d put it back the way you had it, for now. This way we’ve got consistency when we check the additional rule I posted for you. If you change them, and we try the new rule, then we’re taking away just to add something new; that will skew the results.

Alert Level: Yes, you can turn the alert level & certified apps back to default.


Here’s a couple things to look at, regarding the remote connection; I’ve been thinking you may need to go this route.

https://forums.comodo.com/index.php/topic,6167.msg45527.html#msg45527 This is a copy of the original post; you can reach the original by clicking the embedded link next to m0ng0d’s name.

He also links to this one. [url]https://forums.comodo.com/index.php/topic,806.0.html]/url] Note that this scenario looks very much like yours (or it does to me, at least).

I’ve been thinking the key will probably be in the Trusted Network/Zone approach, as that means you will have uninhibited communication back and forth from your computer to that Zone, and vice versa. Sorry I’m not more on top of this; last time I used remote connections, I didn’t have a firewall like Comodo, and it had no problem with such a bilateral connection…


ok, i’ll have a look at those thread and see if it solves the problem.

can i just ask you another question about network rules,

I’ve got ICS on in winxp to share the internet with another pc via a second nic and crossover cable.
Is this rule ok?



and have this rule for a bittorrent client listening on port 16259


are both these rules right, and what position should each one be to work best?


The first two are the standard Trusted Network rules; if you created them through the Network Wizard, they should automatically be placed in positions Rule ID 0 & 1. This is where they should be.

For the p2p rule, change it from In/Out to In. You’ve already got a rule to allow TCP/UDP Out, by default, so you don’t need that aspect of it; besides, having the rule that way would mean that the remote/destination port for the Outbound connection would have to be 16259, which would be the listening port for the other end (which it probably isn’t…).

So the p2p rule would be Allow TCP/UDP In from IP Any to IP Any (or your IP address) where Source Port is Any and Destination Port is 16259.