I discovered that this problem only happens when I define the rule’s source address using the zone option
But with the same ip addresses defined directly inside the rule (using the IP mask option), it works correctly
It doesn’t matter how many groups of IP addresses are defined inside a zone, even a single IP range doesn’t work
The funny thing is that even defining the zone as ANY ADDRESSES won’t work either
I have to admit that, when “automatically detect new private networks” option is enabled, CFP’s automatic generated rules for allowing file sharing work properly. But my rules which have the same meaning don’t.
One other thing that is confusing me is that CFP generates two pairs of rules to allow full access to the machine from automatically detected zones. The first pair is added to the System process (in application rules) to allow inbound/outbound connection from/to the zone. The second pair is the same as the first but is added to the global rules. However, the global pair seems to be redundant. Although CFP says “For Incoming connection attempts, the global rules are consulted first and the application rules second.” but deleting the global pair has no effect on allowing full access to the zone. A request coming from the zone to System will at last be matched through the application rules whether or not a global rule rejects it. So, adding an Accept rule to the global rules has the same effect as adding no rule. The same is true for outbound connections. So the global pair is completely redundant and CFP should not automatically generate them.
according to this, I thought adding an rule to the global rules would resolve the problem, but it didn’t either
Are you behind a router/modem with a hardware firewall? I have my svchost and system to outbound only. If you search the forum you will find your answer. You do not need svchost and system to go in and out. What your properly seeing is router chatter. Like I said if you have a hardware firewall you need to configure that first.
It doesn’t matter where I am (behind a hardware firewall or not)
Its seems you didn’t understand the problem
Should I explain further ? does any one of you (comodo developers) want to know ? or I’m just wasting my time ?
global rules: attached glb_rules_1.png
application rules: attached app_rules_1.png
everything works as expected. requests coming from 10.10.10.0/255.255.255.0 and 192.168.0.0/255.255.0.0 are being accepted automatically.
global rules: same as case 1
application rules: attached app_rules_2.png
zones: attached zones.png
sample event generated after these rules are set: attached events.png
as you can see, the source ip address in the event is 10.10.10.1, shouldn’t it be accepted ?
attempts to open the shared folders of this computer from computers in this zone will fail too
I enable “automatically detect new private networks”
when the new private network is detected it asks if “I would like to be fully accessible to the other PCs in this network” and I say yes too
this will generate #1 a new zone called “local area network #1” defined as: IP In [10.10.10.11 / 255.255.255.0]
plus #2 two new rules under the System application
and #3 two new rules in the global rules section
#2 & #3 are to allow inbound/outbound traffic through the newly generated zone
in this case file sharing works correct. even if I delete those two global rules (#3) no problem occurs.
Now someone tell me what was the difference between case 2 and case 3 while one of them works but the other doesn’t.
I have a network zone to allow Multicast traffic and it works correctly using
Allow IP Out From IP Any To Zone [Special & Local Multicast] Where Protocol Is Any
with a zone using IP ranges
[Special & Local Multicast] is defined as
 IP In [18.104.22.168-22.214.171.124]
 IP In [126.96.36.199-188.8.131.52]
That’s why I asked for an IP range test.
Posting a full CFP report of a failing config it does help and it doesn’t even require much effort.
Despite problems being similar in appearance the underlying issue may be different.
Even if you are willing to consider this issue the same you got, this does not mean that eveyone will be able to reproduce it.
A CFP configuration report provide a standard output with enough information to reduce the number of troubleshooting steps and questions and usually provide enough info to reproduce issues.