I have set the following application rules for svchost.exe and System
Allow IP Out From IP Any To IP Any Where Protocol Is Any
Allow IP In From In [LAN Zone] To IP Any Where Protocol Is Any
Where LAN Zone includes two different sets of addresses
IP In [192.168.0.0 / 255.255.0.0]
IP In [10.10.10.0 / 255.255.255.0]
But I still get alarm for inbound traffic coming from LAN Zone to these applications
Is this a bug or do I miss somthing ?
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
I’m still waiting for someone to help
I first posted this topic in the bug report section but a moderator moved it here
Now if that moderator believes that this is not a bug, please let me know the answer
I would appreciate
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 ?
Please use CFP configuretion Report to attach your current CFP configuration to your post.
Please attach a screenshot about the alerts you see too and any other useful info as described in ATTN: HOW TO PROPERLY POST FOR HELP
OK, here I try to explain with screen shots
Case 1:
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.
Case 2:
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
Case 3:
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.
[attachment deleted by admin]
in case 2 what happens if you change netmask notation to use IP range notation in your LAN zone?
eg: IP In [192.168.0.0 - 192.168.255.255 ], IP In [10.10.10.0 - 10.10.10.255]
BTW your netmask info looks like a bit off
instead of
IP In [192.168.0.0 / 255.255.0.0] class C
IP In [10.10.10.0 / 255.255.255.0] class A
shouldn’t it be?
IP In [192.168.0.0 /255.255.255.0]
IP In [10.10.10.0 / 255.255.0.0 ]
can you post a cfp report of a non working case 2?
As I told this before (2nd or 3rd post in this topic), even using ANY in the zone won’t help
As you see in the screen shots, 192.168.0.0 / 255.255.0.0 is working for me when it is defined directly inside the rule (not in zones)
If it helps, however I got tired of this issue, I think the dev group should handle the rest
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
-----------------------------------------------------------------------------------------
[0] IP In [224.0.0.0-224.0.0.255]
[1] IP In [239.0.0.0-239.255.255.255]
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.
I have encountered this problem too. So its not just one user’s configuration.
Mouse1
My configuration. The .html file has been renamed .txt
Many thanks
[attachment deleted by admin]
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.
CFP Report is attached
By looking at the report file, you’ll find an strange thing
While I have a zone called “LAN Zone” defined as
IP In [192.168.0.0 / 255.255.255.0]
It is not reported, whereas it is there inside rules
[attachment deleted by admin]
Thanks for the report.
CFP 3.0.25 has a bug which cause Network zones to not be saved during shutdown.
Just in case this was caused by a corrupt registry please export
HKEY_LOCAL_MACHINE\SYSTEM\Software\Comodo\Firewall Pro\Configurations\0\Firewall\Network Aliases branch
Please confirn this was the config that caused svchost blocked connections.
Finally somebody admitted the bug
The registry export is attached
[attachment deleted by admin]
There are already few threads about that but your previous screenshoot showed something different.
So it still not clear if this is something already reported or if it is something new.
The unzipped reg file appears corrupted but there is only one entry about localhost (please zip it an post it again just in case).
Did you take that network zones screenshoot soon after you edited your network zones?