Comodo and LogMeIn [Closed]

Help for v2
#1

Hi,

I am new to this forum. I have had Comodo Firewall Pro Version 2.4.18.184 for about a month now. I really like the product. However, one problem I’m having is that I cannot connect to my home/host computer (which runs Comodo) from my school computer (acting as the client) using the free remote desktop service, LogMeIn Free. I do connect to the host briefly, but then I lose it after a few seconds. When I go home, I can see in the Comodo Activity Logs that my connection attempts were rated “High” in severity and thus were blocked. The “Network Monitor” is the reporter, and the descriptions read “Blocked by Protocol Analysis (Fragmented IP Packet)” and “Blocked by Protocol Analysis (Fake or Malinformed UDP Packet).” When I look at the details of each on the bottom, I see proof that they were my failed attempts, being the IP address of my host “Source” comp with Comodo, and the IP of my client “Destination” comp. Please let me know how I might be able to unblock the connection. Any help would be greatly appreciated. Thank you very much.

#2

I use LogMeIn as well, Netophone. I had some issues at first, with getting everything allowed properly through CFP, but if I recall correctly, I have not had any issues with Network Monitor or Protocol Analysis.

What I have is allow the LogMeIn executable (for the systray icon) as a trusted application in the Application Monitor. This I did by opening the rule to Edit it, and instead of the box for “Apply the following criteria” I checked the box, “Allow all activities.” This created a complete set of IP and Port range for it (as opposed to “Any”, which did not seem to work as well). Then I went into the Miscellaneous tab and checked the boxes for “Skip Advanced…Checks” and “Allow Invisible Connections.” (this resulted in the best connectivity for me)

As long as (in Network Monitor) you have a rule to Allow TCP Out to Any Destination/Any Port (which you should have such a rule by default - a combined TCP/UDP Out rule), you should then be good to go.

Hope that helps,

LM

#3

Hmm I havent used LogMeIn. But I have used “TeamViewer” And it worked fine without any problems!
(Actually just an hour ago I used it to access my friend’s desktop and we both have COMODO FW installed!) And TeamViewer “for home” is free as well! Hope this helps although this is not the solution for you question!

#4

Thank you both for your prompt replies. Damitha, I appreciate your suggestion and will keep TeamViewer in mind as a fall-back option.

Little Mac, I followed your config instructions, yet I regret to say I get the same results. In addition to putting the LogMeIn systray exe in the Application Monitor, I found that I had to put the LogMeIn executable for the main prog in there as well to enable the systray icon/connection to LogMeIn on my host comp. As for my network monitor, I have it set up so that TCP/UDP is In/Out so that I can file share on my 2 comps at home…

Is it possible that the problem is the fact I have “Block Fragmented IP Datagrams” and “Do Protocol Analysis” checked in the area Advanced>Advanced Attack Detection and Prevention>Configure>Miscellaneous? As I previously mentioned, the log says that Protocol Analysis is blocking the Fragmented IP, and UDP packets that don’t match, so could that be the problem? If so, is it safe to uncheck “Block Fragmented IP Datagrams” and “Do Protocol Analysis?” I know they are checked by default. Thanks again for your assistance.

#5

Netophone, by checking “Skip Advanced Security Checks” under the Miscellaneous tab of the Application Monitor entry, you should be disabling - for that application only - the Advanced Checks, which includes everything found under Security/Advanced.

That said, is the only log entry you have for LogMeIn being blocked, referencing the fragmented packets?

Is it possible for you to have to computers in physical proximity, and use LogMeIn to access one, so that you can see any alerts/popups in real-time, and respond? I did this myself, and found it helpful.

I just had a thought on something. Will you open Activity/Logs, right-click and select Export to HTML. Save the file, and reopen it (it will open in your browser). Highlight all entries for a few minutes on either side of your last LogMeIn connection attempt. Copy the highlighted section. Paste it into your next post (it will be text, in the same format/layout as the HTML file). If you external IP address shows (which it should - it will match the IP address showing in the lower right corner of your posts here), you may mask/edit it with “x” for privacy. Please do not mask out other IPs, as these will be crucial to what I’m thinking about.

Also, if you can capture a screenshot of your Network Monitor (taken at full-screen size) and attach to your post under Additional Options, that would be very helpful as well. There’s more info about screenshots (if you need it) in a post in this thread: https://forums.comodo.com/index.php/topic,6167.0.html

You will probably want to change the TCP/UDP In/Out rule; I realize you set it for a reason, but there’s a better way to do what you need to do, and more secure. We’ll tackle that later.

Get me the log and the screenshot. If you want to turn off Protocol Analysis to see if that makes a difference, you may do so (but get me the info first). Not the ideal solution by any means, and it may end up being necessary, but I’d like to see if we can’t resolve this without resorting to that as a permanent solution. Mine’s working without it, so I’m thinking we should be able to do it…

LM

#6

Hi Little Mac,

As you can see via my logs, Protocol Analysis is blocking both Fragmented Packets and Fake/Malinformed UDP packets. Yes, I actually have tried a LogMeIn connection between 2 of my home computers- both of which have Comodo. I have had no problems doing so. The problem is only from my school comp connecting to my home comp.

Below, I have provided my logs of the blocked events. I regret to say that I have to mask my “destination” address (my school address, an external IP). I don’t feel secure posting it for everyone to see on http. My “source” address, however, is private, so I have provided that for you. Also, I attached my network monitor as per your request. Thank you.

-Mod edit to replace long log post with text attachment-

[attachment deleted by admin]

#7

Thanks, Netophone ~

Okay, so it’s not the connection going in that’s being blocked; it appears it would be LogMeIn’s outbound transmission, that’s getting jacked up. Very odd. I thought maybe your school’s system was doing something to the packets, but that’s not the case, apparently, since they’re all Outbound attempts.

The two computers you’ve successfully connected, are they both on the same “network”? Perhaps those you’re doing file sharing on anyway?

Trying to mull through this. It shouldn’t be working this way (or rather, not working). One of our Moderators, “panic,” knows a lot more about remote access software and networking than I do; let me see if I can’t get some knowledgeable assistance from him.

Please listen to the pretty music while I put you on hold… ;D

LM

PS: The TCP/UDP In/Out rule really must go… it’s a security risk. If you want to share files between your computers through a LAN or other direct connection, you need to establish a trusted network for those. It’s a simple process.

Go to Security/Tasks/Create a Zone. I presume your internal IPs are fixed; use those to establish the Start/End IPs for your Zone; give it a name that is easy and memorable.

Then go to Security/Tasks/Define a New Trusted Network. Use the Zone you just created. This will give you two new rules in Network Monitor, in positions Rule ID 0 & 1. The first will Allow IP Out from Any to Zone; the second will Allow IP In from Zone to Any. This allows your two computers to communicate freely, but securely.

Then go to your TCP/UDP In/Out rule and change it back to the default TCP/UDP Out Any/Any rule.

Hold, please…

#8

Hey netophone,

Can you confirm a few things fro me?

  1. The log extract posted above is from a PC at your home, and not from a PC at your school.

  2. You can successfully use LogMeIn to take over another PC on your LAN from a PC on the same LAN.

  3. The connection only fails if you try to connect FROM school to home

Something’s defintiely a bit pear shaped, either in our understanding (probable), your explanation (unlikely) or in the ruleset. Funnily, if it was in the ruleset, I really am at a loss to understand how it works in one set of circumstances and not in another.

Cheers,
Ewen :slight_smile:

#9

Hi Ewen,

Thank you for your prompt reply. I can answer you with a definitive “yes” to all 3 of your questions. The log I provided is indeed that of my home PC…not my school. As I told Little Mac, I can use LogMeIn between my 2 home PC’s on the same LAN. Both PC’s have Comodo installed, and there have been no problems at all there. And yes, the only problem is my connection going from my school to home. When I connect from home to school, I am fine (I’m using a different firewall at school). And from school, I connected out to my grandma’s computer (on yet another LAN) with no problem at all. She does not have Comodo either. Finally, today, I made sure to disable Comodo at home and turn on Windows Firewall instead before I went to school. And now, as expected, I finally connected from school to home successfully. So it seems it is definitely Comodo at home causing the problems. If you have any suggestions at all, it would be very much appreciated.

#10

The running LogMeIn.exe always has an active outgoing TCP connection, and from what I’ve seen, it’s always one specific IP address.

You should have a rule in Application Monitor already that allows this application to connect, and your logs aren’t giving alerts based on the application.

What if you add, at the top of Network Monitor (position Rule ID 0) a rule to Allow TCP Out from Any IP to that specific IP, Any Port to Destination Port 443. That way it is Explicitly allowed in Network Monitor.

I will admit I don’t see how that would make a difference, but then I don’t see how the situation makes sense anyway!

LM

#11

Can you let us know what router and firewall hardware/software is in the connection chain at school?

The only thing I can think of, based on the fact that it works within your LAN but not from your school, is that something in the schools communications chain is somehow sending data in a manner unnacceptable to CFP most probably due to malformed packets. Finding out your hardware/software may not be the end of the issue either, it could be something in your schools ISP as well.

Still thinking …

Ewen :-

#12

That was my first thought, too (and I almost went that route to propose a solution), but then I re-read the log entry and it was only related to Outbound. If it was the school’s system (again, my first choice…), why would it be only on outbound from the Home network? Wouldn’t that make it that router? But then, he (gender presumptive) can connect from Home to School.

Here’s a thought, Netophone… can you connect from Grandma’s to Home? Can you connect from Home to Grandma’s?

We know:

School to Home = XX
Home to School = OK
School to Grandma = OK
Grandma to Home = ??
Home to Grandma = ??

Maybe we can start to establish a pattern to help narrow the culprit…

LM

#13

Hi guys,

Panic, just to answer your question, my software firewall at school is Symantec (which I had no problem configuring). As for the hardware firewall…I don’t know about that one. I’ll see if I can find out next week.

LM, I made the TCP rule you suggested and will try it out Monday at school…thank you. As for my grandma’s comp, I can connect to it with no problems from both home and school (she has Kerio FW). I have yet to try connecting from her comp to home. I hope to be able to attempt this over the weekend. I will be sure to let you know how I make out. Thanks again.

#14

Hey LM,

Yep,I noticed that they were outbound - that’s what makes it so odd! Having said that, all the blocked outbound connections are UDP, which I believe is a “connectionless” protocol. I’ll try and see how this fits into this scenario.

The common element, as I see it, isn’t one thing, it’s a combination of the schools communication chain AND the Comodo firewall. Assuming that if he disables the fragmentation check it will work, then it has to be something in how LogMeIn on his home PCis responding to a LogMeIn request from school.

Curiouser and curiouser said the cat.

Ewen :slight_smile:

#15

Hello again guys,

I won’t be able to try grandma-to-home until sometime next week…but in the meantime, I may have made an interesting discovery. LM, I put in the rule in network monitor for my 2 home comps to share…which I thank you for. The problem was, as soon as I did so, I could not share. I checked my comps’ IP’s, and they had changed after I put the rule in (I had dynamic IP’s configured). Thus, I was obviously blocking the comps instead and had to configure static IP’s etc.

Anyway, what I’m getting at is, prior to my fixing this simple problem, I decided to use LogMeIn between my 2 home comps…with the faulty rule in place, just to see what happens. I attempted to connect from my laptop to my desktop (the home comp I always refer to connecting to/from school), and lo and behold, I seemed to recreate my problem connecting from school to my desktop. Only this time, I was able to observe what was happening on my desktop. On my laptop screen, the connection to my desktop via LogMeIn seemed to suddenly stop just like when I was at school…however, as strange as this may sound, I still had full control of my desktop! In other words, my laptop’s LogMeIn screen of my desktop appeared frozen/disconnected just like at school, but I looked at my desktop screen itself, and I had full control of the mouse/keyboard/files…u name it. I was essentially controlling the desktop blind- seeing as at school, I thought it was blocked/disconnected, but it’s not. Are you following me? Am I making any sense at all? Anyway, this seems to prove the fact that the Outbound is indeed being blocked so that I cannot see anything on the client end.

With all that said (if any of “that” had substance, please let me know), I went ahead and altered the share rule on my 2 home comps so that I had the correct IP’s of both in there. And then…wa la…I was able to share freely, AND use LogMeIn with no problems at all between the 2…no blind screens or anything.

Is it possible that I should create an additional share rule, so that I can freely exchange information between my desktop and my school comp? Will that perhaps, finally enable me to use LogMeIn without the outgoing restrictions?

As we had discussed, I know that my 2 home comps were able to connect via LogMeIn even before I had created any share rule, but I was just wondering if a connection from school-to-home may require a share rule. I better just stop now and let you guys take it from here. Hopefully I didn’t make too much of a fool out of myself :wink: . Thank you for all of your help.

#16

Can we get a screenshot of your Network Monitor (at full screen size) to see those rules as they are currently?

Tnx,

LM

#17

Sure LM. I have my desktop (192.168.2.101) sharing with my laptop (192.168.2.102) under the zone “FAMILY” for Rules “0” and “1.” I will put in your recommended TCP out rule to my school IP (for Rule “0”) prior to my going to school tomorrow. I do not have it in the screenshot for security reasons.

[attachment deleted by admin]

#18

Hi LM,

Once again, I have tried to connect from school to home (this time with the new TCP rule), but to no avail. I think what I’ll just do is, stick with Comodo as my regular firewall, and disable it and enable the XP firewall if/when I want to connect home via LogMeIn. I won’t need to connect all the time, so it should be fine.

It’s unfortunate we couldn’t get it to work, but I can tell you I learned a lot about Comodo in the process. I thank you guys again for all of your time and effort, as I am very appreciative of all the help you have given me. Take care–

~Netophone

#19

You shouldn’t have to have a “share” rule from school to home, in order for LogMeIn to work. That’s pretty much the whole point of having a browser-based remote-access application; to avoid firewall configuration issues. They just don’t take Comodo into account on that, LOL.

You definitely have an odd one, though.

I somewhat discount connecting on home LAN thru LogMeIn, simply because you are on the same network. I have found it “easier” to connect from one to another on the same LAN as compared to connecting from home to work; I had to modify the AppMon rule to increase its connectivity. Fortunately I was able to log in and do this remotely!

Thus, my highest point of interest is seeing if you can connect from Grandma’s to Home. Reason is, if you have the same issue there, this definitely pinpoints your home setup (something there) rather than the possibility that the School’s system is causing problems. If, however, you can connect easily from Grandma to Home, but still not from School to Home, then there is an issue with the School setup. This is our big diagnostic test… :wink:

You’ve got a workaround figured out, which is good; but not ideal. If Grandma to Home still bogs out, my suggestion would be to uninstall Comodo (with all active security turned off and physically disconnected from the internet), clean out the registry to make sure there are no rogue/orphaned/leftover entries, and reinstall the FW (again with all active security turned off, etc - to make sure we get a “clean” install with no conflicts). In that you already have some rules set up, you can create a backup of those to bring into the new install, from this thread: https://forums.comodo.com/index.php/topic,2366.0.html

We’ll leave this thread open; hopefully once you can check from Grandma to Home, we’ll be closer to a solution…

LM

#20

Hey LM,

Perhaps we are closer to a solution at last. I was able to try grandma-to-home today, and I can connect with absolutely no problems. The screen does not freeze or anything, and everything works just fine. So you and Panic said it…it is apparently an issue between my school and Comodo.

But now that that’s narrowed down, what, if anything, can be done about it? Why would Comodo dislike my using LogMeIn from school so much, that it would block all outgoing IP/UDP? You guys mentioned that it could be a disagreement between Comodo and the school’s hardware firewall? But then again, why wouldn’t this also be the case with the other firewalls I’m using (Symantec at school, or Kerio at grandma’s)? It seems really perplexing to me. Anyway, I look forward to any further input you have!