limewire - connections seem to be in the wrong direction

Help for v2
1

I’ve read through the manual and the help files, and I think I understand what comodo means when it refers to in/out destination/source relationships. This is what confuses me about limewire.

I’m trying to set some good control rules for limewire. These are the rules I have.

limewire.exe (no parent check) [ALLOW, TCP/UDP, OUT, ANY PORT, ANY ADDRESS, allow invisible]
limewire.exe (no parent check) [BLOCK, TCP/UDP, IN, ANY PORT, ANY ADDRESS, allow invisible]

I know these are not the proper rules, and I know limewire needs an inbound port open to function correctly, but I’m using them to illustrate something else that confuses me.

According to my log, I keep getting inbound connection attempts being blocked by the application. This is what should be happening with my above rule set. What confuses me, is that the address listed as destination appears to be the source. ie, the “destination” address is the address of the person sending me the data.

I understood that on inbound connections, the destination should always be me. Am I missing something?

Cheers,
-Jayne

P.S. Incidentally, I’m sure this has been answered before, but the search function on these forums doesn’t appear to work. I get the same results no matter what my keywords are. I’ve tried “limewire”, “limewire rules”, “application monitor limewire”, and “blah blah”. All search querys return the same unrelated results. Maintenance on the forums?

2

Hey pacificwing,
I’m not sure this will lead us somewhere but before I’ll give you some dim-witted nonsense answer I’d like to know a bit more about your problem.

  1. Correct me if I’m wrong:
  • You created the rules quoted below (well, it was below when I wrote this, now it’s above - stupid me ;D) by using the “add” button in the “Application Monitor”?
  1. Could you please have another look at your log and post the main “details” including the “reason” for a typical “Inbound policy violation” log-entry that is related to Limewire???

I’m sure somebody else could instantly answer your question, I, however, need these information first.

Cheers,
grampa.

3

Sorry for the spam. The only way I could see to export these things was in HTML format.

What follows are four examples of what are hundreds of inbound connection attempts. These should not be getting as far as the application monitor, as the network monitor rules I have set should not be allowing them. Also, what is very strange, is that the destination address is not my IP address. Reverse lookups appear to be random ISPs, so I’m guessing they are peers trying to connect.

Why would the listed destination addresses actually be the source addresses? This was my original question.

Also, i’m sorry, but I was not able to find a way to export the rules i have any more clearly than what I posted above. Yes, I was adding them manually.

Date/Time :2007-05-03 12:00:19
Severity :Medium
Reporter :Application Monitor
Description: Application Access Denied (LimeWire.exe:69.215.2.108: :4627)
Application: C:\Program Files\LimeWire\LimeWire.exe
Parent: C:\WINDOWS\explorer.exe
Protocol: TCP In
Destination: 69.215.2.108::4627

Date/Time :2007-05-03 12:00:19
Severity :Medium
Reporter :Application Monitor
Description: Application Access Denied (LimeWire.exe:75.162.112.44: :4624)
Application: C:\Program Files\LimeWire\LimeWire.exe
Parent: C:\WINDOWS\explorer.exe
Protocol: TCP In
Destination: 75.162.112.44::4624

Date/Time :2007-05-03 12:00:19
Severity :Medium
Reporter :Application Monitor
Description: Application Access Denied (LimeWire.exe:75.65.137.183: :4625)
Application: C:\Program Files\LimeWire\LimeWire.exe
Parent: C:\WINDOWS\explorer.exe
Protocol: TCP In
Destination: 75.65.137.183::4625

Date/Time :2007-05-03 12:00:19
Severity :Medium
Reporter :Application Monitor
Description: Application Access Denied (LimeWire.exe:74.100.137.143: :4626)
Application: C:\Program Files\LimeWire\LimeWire.exe
Parent: C:\WINDOWS\explorer.exe
Protocol: TCP In
Destination: 74.100.137.143::4626

Thanks for the help,
-PW

4

I looked up the IP-addresses, just for the fun of it ;D

  • The first is located in Cleveland, USA.
  • The second in Salt Lake City, USA.
  • The third in Houma, USA.
  • The fourth in Etobicoke, Canada.
    So your guess should be right.
    What’s quite interesting are the ports: Limewire uses standard port 6346 ??? ??? ???

And that is one hell of a question for me to answer. HEEEEEEEEEEEEEEEEELP!!!
Every log I get that was triggered by “Application Monitor” is OUT. I only get “Inbout policy violation” reported by “network monitor”.
However, I think CPF is working as it should. You should set proper NCRs, delete your ACRs, and tick “remember+allow” when warned about an unknown app (Limewire.exe) trying to connect to the intenet.
If you need any help in configuring these rules (as I’m sure you don’t, having understood the workings of CPF so perfectly) then be assured that I can help you.
As for your actual question, I’m afraid, I think we’ll have to wait for one of the wiser people to answer.
Please forgive my inability to help and the above dialog between app x and comodo (it’s quite late and I’m tired).
Cheers,
grampa.

P.S. When I examine my logs I cannot find my IP-address at all. It’s neither source nor destination.
Beats me :o

Woahhhhhhhhhh, half of my post is missing ??? Where did it go ??? The upper half has disappeared!!! I’ll see if I can remember what I’ve written and do it again in short form.

5

Here’s a summary of the first half of the post (the one that’s disappeared (:AGY)).
I think I first congratulated you on your perfect understanding of the workings of CPF:
that “Application Control Rules” can only work if not contradicted by “Network Control Rules”, the latter being kind of a “bouncer”. This part also included an illustrative dialogue between “Application X” and Comodo FW that went something like this:
App X:“Oi, Comodo! Let me connect to the internet. See, I’ve got an Application Control Rule that says allow.”
Comodo." No way mate, Network Monitor tells me not to let you connect. I’m sorry. He’s the boss.
(I also insert a quote here to make my post look nicer.)
Then came another quote where you stated that you should be the “destination” with “inbound control rules”. I told you that you were perfectly right again.
I might have written other things but I really cannot remember what and if I really have.
Hope you’ll get an answer soon.
Cheers,
grampa.

6

Two things we need, to help us out, pacificwing:

Open CFP Network Monitor to full-screen size. Capture a screenshot. Save it as an image file (jpg, png, gif) and attach to your post under Additional Options.

Then open CFP Application Monitor to full-screen size. Capture a screenshot, blah blah blah. To attach a second file, you’ll need to click the little red “(more attachments)” next to the “Browse…” button under Additional Options, then use the 2nd Attach: field.

Also, what port have you set in Limewire for it to Listen on? Also also, you will need to allow In connectivity for Limewire in application monitor, if you want it to be able to Listen on that port (per firewall permission).

Tnx,

LM

PS: For best results right now from the broken Search feature (it used to work, I promise), select “Advanced Search”, and Subject/Titles Only. You can also select the Board, to limit it to just the FW boards - Help, CFP FAQ, etc.

PPS: Check out this thread: https://forums.comodo.com/index.php/topic,6167.0.html (part of the FAQ); look for the P2p Applications link in the top post.

7

Here are the applicable application rules, network rules, an example of the log, and the limewire config. I’ll restate my original question, which I think is best illustrated in the log file image. Why does an INBOUND connection, which I’m receiving, have a destination IP address that isn’t mine?

This is the crux of my problem. The firewall appears to be confusing source identities with destination identities, which makes setting inbound rules impossible. The only way I get get this application to work is by allowing everything (in and out) for limewire.

Oh. And the advanced search still doesn’t work. I select to search in only certain topics, but it still produces results from all topics. Also, I still get the same results no matter what keywords I use.

Cheers,
-PW

[attachment deleted by admin]

8

Be very careful with LimeWire! The files sent most of the time contain viruses! I got a nasty Trojan that wasn’t detected straight away and I ended up having to do a CD backup Reinstall!

Just a warning! Make sure you’ve got Comodo BOClean and a really good AV running!

Eric

9

This is kind of implicit with all p2p applications, but thank you anyway.

Currently I’m using kaspersky, as comodo is a bit heavy and unstable at the moment. I’ll wait until its out of beta.

I can assure you, the limewire application itself is clean of spyware or malicious operation. I’m fairly certain the problem I’m having exists within comodo firewall. I’m willing to accept that it might be something I’ve configured incorrectly, however I’ve gone through all of the documentation I can find and thus far come up empty.

It occurred to me that comodo might be having a problem with limewire because, as I understand it, limewire connects through the Java runtime environment. There is no mention of this relationship in comodo. When I have more time, I might see if I can recreate the problem in another Java based internet application (azureus).

Cheers,
-PW

10

Okay. I’ve ruled out JRE. It’s a p2p thing. Might be exclusively a problem with the gnutella network. I tried another p2p application (KCeasy) and got the same results. Inbound connections display the source identity as the destination in the log file.

What I don’t understand is why this problem is limited to p2p applications.

I’ll keep playing with it, but if anyone can shed some light on this, it would be helpful.

Cheers,
-PW

11

Hi pacificwing,

from what I see the problem is your block rule for limeware. This is the one that blocks the connection versus the other clients.

12

I was going to post the same as pandlouk. It’s your Application rule blocking all TCP/UDP in, despite having an allow rule for incoming to your listen port. You don’t need an Application rule to block Limeware because remember that Network rules have the final say.

BTW, you have redundant Network rules:
Block UDP In - Destination Port 137-138
Block IP In

Unless you have some other purpose like testing, your very last rule is incorrect because it should be the one that blocks everything:
Block IP In & Out

13

Thank you. I am aware of this. This isn’t why I was posting. I mentioned this above, but I figured someone would comment on it anyway. I’m aware this rule stops limewire from working. I added it deliberately to produce a log entry that would illustrate my original question, which still has not be answered.

When the connection is inbound, why is the source ip shown as the destination?

If you look on the log screenshot, you’ll notice the third rule down has been highlighted. It is TCP, inbound, 204.11.219.226:4333. This is not my IP address! Why is it shown as the destination to a connection that is supposedly inbound? Shouldn’t my IP address be the destination? Or am I not understanding something?

This was the original (and only) question I really need answered. I’ve never had a problem getting limewire to work.

This is not a redundant rule. One rule logs, the other doesn’t. On one of the networks I frequent, I get hit with so many connection attempts on 137-138 that it clutters my log to no end. Thus I turn off logging for those, and enable it for everything else.

If you mean the network rules, please elaborate. I thought that is exactly what my last rule (rule #10) was doing. If you meant the application rules, I have no control over how the application rules order themselves. They seem to have a mind of their own.

Thanks for your input. Much appreciated.

Cheers,
-PW

14

Nevermind this. I see what you mean now.

15

You’re right. For incoming, destination should = your IP. I don’t know why it logs it like this. It definitely wouldn’t be an outgoing connection either because you have only an allowed Application rule on outgoing for Limewire.

IP encompasses TCP, UDP, ICMP (and probably more, but I’m not certain and this is something I want to confirm myself). So if your intent is to have your last network rule as the “final block all” rule, it’s best to keep the default rule as Block IP In & Out. In essence, you can remove your last 2 rules and change into this one.

Edit: Notice you posted before me :slight_smile:

16

Thank you! I thought I was going insane. Glad to know it isn’t something silly I’m doing wrong.

My only concern is that it’s not just the log. I wonder if comodo actually interprets rules using this erroneous information. If the source and destination are getting confused, then that could play havoc with specific rule sets.

I would submit a bug, except I can only reproduce it with p2p applications, and thus far no one else has had the problem.

:-\

-PW

17

At this point we can speculate that it’s due to you having both an allow and block Application Monitor rule on the same program that’s causing this bug, specifically the first 2 in your screenshot. There are other issues like the ordering that you mentioned earlier:
https://forums.comodo.com/index.php/topic,8863.0.html

If you haven’t filed a http://support.comodo.com ticket, now would be the time. Link them to this thread.