The issue is that CPF silenlty blocks every app that establishes listening ports (such as most P2P apps do). Although CPF asks for approval for an app registering incoming connection, when packets come to such port, CPF silently discards the data. As a result, P2P apps can’t work effectively (for example, mule gets LowID, DC++ search stops working) unless INCOMING ports are registered system-wide in the Network Monitor rules. But it’s a very lame solution allowing every app listen specified ports.
I already reported this issue at least twice (the last one here), but haven’t got any meaning comments. So, waiting for the feedback from the devs.
CFP has “layered” security, that’s why it’s so secure.
Just because it creates an alert popup for an app, it doesn’t mean that the app get full access to internet. It’s not a bug, it’s a feature.
For apps like filesharing and servers, you need to open a port.
Network monitor works like a router, so you need to forward port(s) for some apps.
Open a port (28019) in network monitor, and it should work.
For instructions, go to the FAQ page, or ask if you don’t know how to do it.
I seriously doubt it’s a feature. From all aspect it is rather a bug:
CFP notices an application listening for a port and ask a user for approval. But even if the user permits this activity CPF won’t allow incoming traffic for the app he just allowed to. (?!)
Such firewall misbehaviour may interfere with any application that dynamically opens listening ports.
Opening system-wide ports in network monitor just for letting app work use them is madness from the point of security. The more restrictive rules are, the better for the system security. If a personal firewall can’t distinguish incoming specific-to-a-certain-process ports, it’s a major design flaw.
If you have just application monitor like most other firewalls, it’s just one layer…
If you also have an extra layer with network monitor, how can that be more unsafe…? Why does security experts think it’s safe, but not you?
Let’s say that you use uTorrent.
In application monitor you set up one allow all OUT rule for TCP/UDP.
And you set up one rule for TCP/UDP IN for port 50000.
Next you set up a rule in network monitor.
You set it up to allow TCP/UDP IN for port 50000 to any/your IP/your zone.
Port 50000 is NOT open all the time!
The connection HAS to start from INSIDE CFP.
When you start uTorrent, it starts to listen to port 50000, (application rule) and then network monitor opens that port for uTorrent. Only ONE app can use that port, and it’s uTorrent in this case.
What other firewalls have is interconnection between a generic L3-packet filter (Network Monitor in our case) and upper application-bound layers (Application Monitor). For example, if uTorrents creates a listening port, it is automatically open by packet filter casue the user already had confirmed this action. It makes the personal firewall more transparent both to the user and the application. This approach is better as it requires less headache from the user (consider this counting numerous topics considering P2P configuration. )and provides more secure environment where no extensively open ports exist. The third advantage is that it allows transparent work for any applications requiring listening a priori unknown to the user ports (some apps create random listening ports). Thus, I suggest some redesign of CPF core structure intended for more flexibility, transparency and security. I would appreciate if you forward this message to the developers (BTW, are there any on the forum?). Already found the support tracker, yet I wonder what I must enter into Order Number OR Domain Name field.
PS: Please, don’t touch the experts, or they’ll bite you ;D (as matousec already had done).
