[eMule] Outgoing ports? [Resolved]

Hello

I read this thread. Telling Comodo to let incoming connections on the TCP and UDP ports that eMule uses is easy, but it doesn’t explain how to allow any outgoing connection: Peers can be listening on any port.

At this point, I had to create a rule that allows outgoing TCP/UDP connections to a bunch of ports (4254, 3012, 4256, 4662, 4333, 4673, 3014. I just add them when I see an error in the Log section), but surely, there’s a more intelligent solution to tell Comodo to let eMule connect out.

Thank you.

Hi. It’s me again. I actually thought you would continue posting on that thread, but oh well.

Let me explain the first rule in Network Monitor (NM). This is also the default - one in which I will never have to change because remember that NM are global rules; they apply to all applications that haven’t been filtered / blocked by Application Monitor. There is also an order: top (highest priority) to bottom (lowest priority). The first rule allows all outgoing connects from your computer or defined trusted network to the internet (specifically to programs that are currently connected to the internet). The internet here is my simplified term for any computer on the end (given the fact that it’s ANY IP on ANY Port). That’s why CFP was designed with the default rules as such.

So there is no need to create any additional outgoing rules to be allowed in Network Monitor for eMule.

[attachment deleted by admin]

Thanks for the prompt answer, but I’m puzzled: Unless I set eMule in AM as “Allow all activities for this application” (default is “Apply the following criteria”), if I don’t create outgoing rules, NM stops them, and eMule can’t upload data to remote peers.

The first rule allows all outgoing connects from your computer or defined trusted network to the internet (specifically to programs that are currently connected to the internet). The internet here is my simplified term for any computer on the end (given the fact that it's ANY IP on ANY Port). That's why CFP was designed with the default rules as such. So there is no need to create any additional outgoing rules to be allowed in Network Monitor for eMule.

But I don’t want just any application to connect out without my allowing them specifically (malware, legit apps calling home without telling me, etc.). So I don’t understand this bit about the first rule allowing any app to call out.

But remember that we’re working with NM. You haven’t shown what your AM ruleset looks like (I assumed you’ve already allowed them). You should post a maximized screenshots of your AM and NM rules on emule so that we can see what’s going on, preferably so that we can see the detail description at the bottom (source, ip, destination, etc.).

Ah, but here’s the beauty of AM. Remember in the other thread I explained CFP has 2 safeguards. It first checks AM for programs that are allowed and only then does it do the second check on NM. Hence, only allowed AM programs and programs in the safelist can reach NM.

Here goes:

AM
http://img521.imageshack.us/img521/8259/comodoamob0.jpg

NM
http://img207.imageshack.us/img207/6570/comodonmgy4.jpg

What I don’t get, is that eMule was listed in AM but outoing connections were blocked by NM: That’s why I created a “allow any TCP/UDP outgoing connection” rule before the final blocking rule yesterday and asked you if that was safe :wink:

So, at this point:

  • either I let the app in AM with the default “Apply the following criteria” and must create rules in NM, but I have to update it a lot because eMule users don’t always use the same TCP/UDP ports
  • set eMule to “Allow all activies for this application” in AM and don’t bother with NM.

Allow me to recommend how your rules should be. You can remove your emule rules and start over to make things clearer.

Your AM rules can be more secured, but it requires a minimum of 3 rules (due to the nature of eMule vs other p2p programs like uTorrent):
Action: Allow
Protocols: TCP/UDP
Direction: Out
Destination IP: Any
Destination Port: Any

Action: Allow
Protocol: TCP
Direction: In
Destination IP: Any (or your computer’s IP or your trusted network zone)
Destination Port: 25530

Action: Allow
Protocol: UDP
Direction: In
Destination IP: Any (or your computer’s IP or your trusted network zone)
Destination Port: 4129

You can keep your 2 NM rules and delete the Allow TCP/UDP Out [Any] [Any] WHERE SOURCE PORT IS [Any] AND DESTINATION PORT IS IN [4254, 3012, 4256, … one:
Action: Allow
Protocol: TCP/UDP
Direction: Out
Source IP: Any (or your computer’s IP or your trusted network zone)
Destination IP: Any
Source Port: Any
Destination Port: Any

Action: Allow
Protocol: TCP
Direction: In
Source IP: Any
Destination IP: Any (or your computer’s IP or your trusted network zone)
Source Port: Any
Destination Port: 25530

Action: Allow
Protocol: UDP
Direction: In
Source IP: Any
Destination IP: Any (or your computer’s IP or your trusted network zone)
Source Port: Any
Destination Port: 4129

The one in blue is where I think is the core of the problem lies. If someone else who’s more familiar with LANs and networks can confirm or correct this for me, I’d appreciate it.

** I think another important thing you didn’t know was that the definition of Source and Destination changes; depending on the direction (whether it’s an incoming or outgoing connection/rule), the roles can be switched to be your computer/trust zone or the internet:
Outgoing connection = Source is your PC and Destination is the Internet
Incoming connection = Source is the internet and Destination is your PC
Keep this in mind when setting up your other rules (which I won’t go over as that’ll be for another topic).

You are right to place them above the last block everything rule (as with any time you create a new NM rule).

Allow me to recommend how your rules should be. You can remove your emule rules and start over to make things clearer.

OK, here’s what I have now:

  • in AM, for eMule, I added TCP IN 25530, UDP IN 4129, and TCP/UPD OUT ANY
  • in NM, right before the final Block All rule, TCP IN 25530, UDP IN 4129, TCP/UPD OUT ANY

Am I right in understanding that the TCP/UDP OUT in NM will only allow outgoing connections for applications that are listed in AM? I don’t want just any app running on the PC to dial out without my knowing.

Thanks.

Excellent. Right, in addition you also have programs certified as safe by CFP (if you left the default option in Security > Advanced > Miscellaneous > Configure > 2nd one). That’s what I’ve been posting about. That’s why there’s no need to wory about the TCP/UDP Out rule in NM. There’s a good reason why it’s the default NM rule and why it’s placed at the top. I don’t think CFP devs would play a crule joke on all of us out of the blue ;D. You can also easily confirm this by checking your log. If there’s any program jumping out without your consent you would’ve noticed it due the last block all rule is set to log by default - or you can even set to log every connection that was allowed by the TCP/UDP Out rule in NM.

That's why there's no need to wory about the TCP/UDP Out rule in NM. There's a good reason why it's the default NM rule and why it's placed at the top.

Finally :slight_smile:

But I’m still not convinced this two-step method is superior to Kerio’s single-step solution: Applications that aren’t listed in AM won’t be able to go through the firewall anyway, so what’s the point of NM?

Now you’re getting nearer to my thinking stage. One of the main reasons has to be the double-layered defense. There are other reasons that deal with how it was designed like in relation to the Advance Attack Detection & Prevention module (take a look a those and you’ll notice they’re all global settings just like NM) and why ICMP and other protocols weren’t built into AM, but I’ll leave that to other users or the devs (you know who you are :P).

What I’ve posted is basically gathered from the FAQ:

[b]Order of Monitor Rules[/b] https://forums.comodo.com/index.php/topic,725.0.html https://forums.comodo.com/index.php/topic,2288.0.html https://forums.comodo.com/index.php/topic,8863.0.html

Explanation of Comodo’s Layered Rules
https://forums.comodo.com/index.php/topic,5372.0.html

There may be good reasons for splitting rules into two parts, but what I know, is that a one-step solution like Kerio is already hard enough to use for non-techies, so I very much doubt Comodo will become a valid alternative to ZoneAlarm or XP’s firewall as long as it uses such a complicated layout :-/

What I've posted is basically gathered from the FAQ:

That’s another thing people in charge of support should do: Summarize those sticky threads into basic, no-brainer articles/tutorials, so that users don’t have to read all those threads in the forum.

I’ll take a look at V3 once it’s available, and see if offers better usability.

Thanks for all your help.

I’m kind of in charge of it (being a volunteer support and all 88), or rather I have the ability to maintain it). Only when you have to open ports like emule / p2p / programs that require incoming ports does it become harder than usual, but what you asked was on the outgoing part, which actually didn’t really any rule modification (at least for people who aren’t on a LAN).

Actually, no-brainer tutorials were already constructed by another mod, who LOVES to advertise it whenever he can. And guess what? It’s in the same ** FAQs/Threads - Read Me First ** thread

I’ve posted for the hundredth time across the forum:

[b]Compilation of Tutorials / Explanations for Easy Reading[/b] https://forums.comodo.com/index.php/topic,6167.0.html

Version 3 is a different realm which I myself haven’t tested it, but will be sure to have to re-learn most things.

Edit: I found out another reason why NM exits. Let’s say you want to block an IP range for any program. You don’t want to have to create 500 rules if you had 500 programs that potentially connects to those IP addresses. Having a universal rule system (NM) would be convenient in that sense.

Only when you have to open ports like emule / p2p / programs that require incoming ports does it become harder than usual, but what you asked was on the outgoing part, which actually didn't really any rule modification (at least for people who aren't on a LAN).

Considering the number of people who stumble on this, there’s an obvious need to expand the help file so that the reason for the different layers makes sense, especially by non-techies (if even people like me have a difficult time making sense of it…)

Actually, no-brainer tutorials were already constructed by another mod, who LOVES to advertise it whenever he can. And guess what? It's in the same [url=https://forums.comodo.com/help/faqsthreads_read_me_first-t9364.0.html]** FAQs/Threads - Read Me First **[/url] thread https://forums.comodo.com/Themes/NewComodo/images/post/thumbup.gif I've posted for the hundredth time across the forum:

I don’t think threads are a good alternative to a quick, to-the-point tutorial in the help file. It’s like learning from an encyclopedia vs. a step-by-step class that starts with a 30,000-foot view, and then zeros in on specific tasks.

I found out another reason why NM exits. Let's say you want to block an IP range for any program. You don't want to have to create 500 rules if you had 500 programs that potentially connects to those IP addresses. Having a universal rule system (NM) would be convenient in that sense.

OK. I’m not an expert in firewalls, so can’t comment on the technical choices. What I do know is that Comodo is a bit hard to use. Maybe V3 will be better in this respect, in which case, I’ll recommend it for those wanting to move from Kerio 2.1.5.

Thanks.

Since this issue has been resolved I am closing this thread. Feel free to open new threads if you other questions.