buggy rules?

I’ve seen this happen a few times. i create a rule in “network control rules” then i use it for a bit and then i go back and change it - it fails to apply even if it lists the change in the rule. If i delete the rule and create it new the way i want it, it works well.

As an example, try to create a tcp/udp allow in/out rule, move it up to the top of the list and then go do the shields up common ports test. Then change the rule to tcp/udp in only, and see that it fails to apply (using shieldsup test again). Then delete that one and create a new tcp/udp in, and see that it applies.

This is a dangerous bug, i think, specially because i’ve seen it across computers. Maybe an “apply” or “ok” button could solve it?

GRC | ShieldsUP! — Internet Vulnerability Profiling   → shields up test, press “proceed” and then “common ports”. In order to do the test more than once you should have to always go back to this initial page

i have to correct myself a bit. Even if apparently verifiable, there seems to be more complexity to this error than what i mentioned. Though, you should still try it. Either way, to me it seems the rules hierarchy apparently becomes flawed even with the delete/re-add method.

I’m no guru, so i would appreciate refutation or opinions on this.

bump

okay, i’m still trying to figure this out. I add a tcp/udp allow in all to network monitor and it allows a ping reply? Why?!
All windows services that were detected through the “scan for known applications” task are blocked (alg.exe lsass.exe services.exe svchost.exe system.exe, etc), and the advanced options are set to default except for disabled “automatically approve safe applications” and “secure the host while booting”.

Now if i understood correctly for In communications the network monitor is the first line of defense. On default rules it blocks everything. But if i add a rule above the Block IP In rule that partially disallows it - like allow tcp/udp in - the traffic is then analysed by the second and third lines of defense- application monitor and component monitor. Now… i didnt allow any of my programs to respond to that ping. What exactly is responding to it?

Plus, if i remember correctly ping is part of icmp protocol :frowning: ICMP “echo request”. So this whole thing gets even more bleak.

I’ll go with my first option: nasty things in my computer. I’m doing an online check right now.
After this i’ll see what else.

Are you behind a router. If yes the problem stands on your routers firewall and not on CPF

I think I may have a “buggy rule” offering…

I’ve been tying to come up with a combination of application rules that keep an application restricted to the Home Network. [url]https://forums.comodo.com/index.php/topic,829.0.html[/url]

I thought I had it licked with the first application I tried it on. I made 3 rules, the application worked without any more firewall propmts for further access, i was happy…

Application Rule #1
App/Parent: SKIP, Action : ALLOW, Protocol :TCP/UDP, Direction : Out, Remote : ZONE:[Home Network], Remote Port: Any, Misc: ALLOW Invisible

Application Rule #2
App/Parent: SKIP, Action : BLOCK, Protocol :TCP/UDP, Direction : Out, Remote : NOT IN ZONE:[Home Network], Remote Port: Any, Misc: ALLOW Invisible

Application Rule #3
App/Parent: SKIP, Action : ALLOW, Protocol :TCP/UDP, Direction : In, Remote : Any, Remote Port: Any, Misc: ALLOW Invisible

… Then i tried to apply the rules to another application. I scrolled down the list to verify what I had entered, and for some reason there were only 2 rules…

Application Rule #2
App/Parent: SKIP, Action : BLOCK, Protocol :TCP/UDP, Direction : Out, Remote : NOT IN ZONE:[Home Network], Remote Port: Any, Misc: ALLOW Invisible

Application Rule #3
App/Parent: SKIP, Action : ALLOW, Protocol :TCP/UDP, Direction : In, Remote : Any, Remote Port: Any, Misc: ALLOW Invisible

I scrolled further down, and noticed that my first application also only had 2 rules now as well. If I try re-adding the “missing” rule, it replaces the existing… rule #1 & #2 seem to want to displace the other.

I’m thinking what’s happening is…
Rules 1 & 2 are seen as being so close by CPF that it merged the 2 rules… unfortunately Block All but Home Network does not mean Allow Home Network… (or is that a bug?) as I would start getting prompts for Home network access if the Block Rule had survived.

My Work-A-Round
I decided to see if I could alter one of the rules enough so that CPF would stop merging them, but still keep the functionality, and came up with the following…

Application Rule #1
App/Parent: SKIP, Action : ALLOW, Protocol :TCP/UDP, Direction : Out, Remote : ZONE:[Home Network], Remote Port: 0-65535 (instead of Any), Misc: ALLOW Invisible

Application Rule #2

App/Parent: SKIP, Action : BLOCK, Protocol :TCP/UDP, Direction : Out, Remote : NOT IN ZONE:[Home Network], Remote Port: Any, Misc: ALLOW Invisible

Application Rule #3
App/Parent: SKIP, Action : ALLOW, Protocol :TCP/UDP, Direction : In, Remote : Any, Remote Port: Any, Misc: ALLOW Invisible

Wouldn’t it work if you had a rule like the following

Action : Allow
Direction : In/Out
Protocol : Any
Source : ZONE
Remote : ZONE
Misc : Allow Invisible

Let us know if this works.

Cheers,
Ewen :slight_smile:

I’ve tried something similar, but the issue was that when the application tried to do things like a broadcast to 255.255.255.255, or hit a remote server for updates, I would get prompted with more popups.

If the Block All Except Home also implied that Home was allowed, then I could get by with 2 rules, but until then, I need the 3rd rule to lock all data flow to the LAN, and be popup-free.

No router, just a cheap USB adsl modem. Any other suggestions? Please try to emulate the problem.