Still confused - using "both" directions in network rules

Last week there were a lot of posts about this topic. I have read and re-read them multiple times but still do not understand something.

Is there a way to use one network rule to allow traffic to go both directions with another PC? For example my main pc is network master browser, running comodo at IP 10.0.0.1. I want unrestricted access between it and another pc at 10.0.0.29.

Now please understand I know how to define 10.0.0.29 as a trusted zone, which in turn creates two network rules. Every other firewall I have used had some mechanism that would allow such a relationship with just one rule. Comodo seems like it should be able to do this as the choice of “both” directions is there. Since source and destination change with direction this gets all mucked up though.

The last post on this topic veered into a discussion of application rules (only) which eventually made sense. I don’t think network rules have been addressed though. Why offer a choice of “both” directions in network rules if it cannot be effectively used? Having to use two rules for each pc on the network clutters things twice as fast as using one would.

And yes, I really like Comodo. This new version has allowed me to finally change some of my other machines from Outpost. But this bit about having to use two network rules seems stupid.

Hey Gravy,

You can have a single rule to cover both in and out bound communications. In the window where you define the rule, on the drop list for “Direction’, you have the choice of “In”, “Out” and In/Out”.

As you’ve already said, Comodo’s default setup create a separate inbound rule and a separate outbound rule. This is purely so it is easier to monitor connections and tweak rules. It cold just as easily have been set up as an “In/Out” rule, though.

In a nutshell, to allow unrestricted traffic from 10.0.0.1 and 10.0.0.29 and vice versa, the following rules are required;

TO ALLOW DATA IN TO 10.0.0.1 FROM 10.0.0.29
Action : Allow
Direction : In/Out
Protocol : IP
Source : 10.0.0.29 (We could also have used a Zone here)
Destination : 10.0.0.1 (Again, a zone would have covered this)
Port : ANY

TO ALLOW DATA OUT FROM 10.0.0.1 FROM 10.0.0.29
Action : Allow
Direction : In/Out
Protocol : IP
Source : 10.0.0.1 (We could also have used a Zone here)
Destination : 10.0.0.20 (Again, a zone would have covered this)
Port : ANY

We still need to have two rules, as we are covering two separate, discrete communications streams - “from 10.0.0.1 to 10.0.0.29” and from “10.0.0.29 to 10.0.0.1”. You could amalgamate them together with a zone based rules, where the source and destination are the defined zone, but it is easier to trouble shoot and refine is the rules are created as separate entities.

Hope this helps,
Ewen :slight_smile: