How To - Understanding & Creating Network Control Rules properly

If you’re like me, your experience with software firewalls has primarily been an application is trying to receive/send some form of communication… do you wish to allow it?… we say yes/no, choose whether it should remember our answer, and life continues until the next prompt.

Not that there is anything wrong with that experience, that was the norm for our beloved firewalls of old… until one day we realize that the product(s) we’ve stuck with (or flipped between) hasn’t been updated for months/years, or is a resource hog, etc… and found ourselves searching for, finding, and installing Comodo Personal Firewall (CPF).

We open up CPF for the first time, see an Application Monitor, and get all excited like we found our comfort zone once again. And for the most part, we are right, but here is where our education begins, as Application Control Rules don’t operate alone… they require Network Control Rules (within the Network Monitor) to set the stage for all communication flow. (I think I have read this referred to as Traffic Shaping.)

Now we can bring a quick end to our education by using the Add a trusted zone Wizard (within Tasks) which will help create some core rules to let some basic communication flow in/out of our PC… but where is the fun in that? And what would we have learned?

(if you are interested in the learning curve I went through, check out [url],1102.0.html[/url])

So let’s start the education!

Now before we jump into Network Control Rule creation, let’s get the Rules Terminology straight.

Network Control Rule’s Terminology

Rule ID - sets the order Rules are applied. A communication attempt starts at the top of the Network Control Rules (ID 0), and works it’s way down through the Rules (unless stopped/blocked) until it finds a Rule that allows the comminication (unless blocked before it hits that Rule).

Action/Permission - when a communication attempt occurs, do we want to Allow or Block it?

Protocol - “A convention or standard that controls or enables the connection, communication, and data transfer between two computing endpoints.” Or more simply put, the type of communication (i.e. IP, TCP, UDP, etc…) [url][/url]

Port - TCP and UDP protocols typically use ports to map data to a particular process running on a computer. As an example, a server used for sending and receiving email may provide both an SMTP and a POP3 service; these will be handled by different server processes, and the port number will be used to determine which data is associated with which process. [url][/url]

Direction: Communication requests can hit our PC whether we’ve asked for it or not

  • Inbound Rule - defines unrequested inbound communication (for the selected Protocol)… like hackers probing our ports, or a friend on our LAN trying to join the FPS/RTS game we are hosting.
  • Outbound Rule - defines requested inbound communication (for the selected Protocol)… like opening IE, “requesting” google to load, and receiving the inbound homepage

Source IP - who made the request for communication (IP address or Range/Zone)

Remote IP - who is responding to a request for communication, or is the expected responder (IP address or Range/Zone)

*** For more verbose terminology definitions for these and other things, please refer to Ewen’s Internet and Networking Terminology for Beginners ***

One of the most important observations on the definitions above (other than the heirarchy of the Rules set by the Rule ID) is that both InBound Rules and OutBound Rules both control information comming into our PC. InBound Rules deal with incoming information/communication we didn’t ask to happen (but may want to happen), while OutBound Rules deal with incoming information/communication we asked to happen.

Ok, assuming that my definitions are well in hand, let’s start putting some of them together; specifically showing how Source and Remote relate to Inbound Rules and OutBound Rules.


  • InBound Rules use Source to define who is trying to send our PC information. Like another PC on our LAN, or a hacker sitting in his/her mom’s basement on some other continent. :slight_smile:
  • OutBound Rules will always have a Source of our PC (whether we specifically set its IP address, its subnet / Zone, or use Any)… when we launch IE to browse Google, it is us on our PC making the request to open the webpage.


  • InBound Rules will always have a Remote of our PC (whether we specifically set its IP address, its subnet / Zone, or use Any)… whether its another PC on our LAN looking for Shares/Printers or to join a game hosted on our PC, or the hacker in his/her mom’s basement, ourt PC is the expected responder.
  • OutBound Rules use Remote to define who is the expected responder to our request for communication/information… the rule needs to know we are expecting google to respond to our request to load the google homepage.

On with some Rules!

Alright, I think we have enough to try creating our first Network Control Rules. So let’s think about what we want, then try using the building blocks of the Rules (our terminology definitions) we’ve looked at to create a rule for it.

Rule A
Where should we start? How about keeping that hacker, probing for ports, off our PC? Good plan! I like how you think. :slight_smile:

I want to… Block attempts by an hacker (outside my network/PC) from reaching my PC, regardless of what protocol they try use.

Using the Rule building blocks: (after selecting to Add a new Rule)
Action: Block (we want to make a rule to stop the hacker) (I also suggest checking the “create an alert if this rule is fired” option so that attempts [good or bad] blocked by this rule are logged)
Protocol/Direction: IP In (The hackers communication attempt will be one we didn’t request to occur)
Source IP: Any (I know what your thinking… we said we wanted to stop communication from outside our network, and Any would also mean the LAN!! Good observation. We’ll need another rule to fix that by allowing the LAN communication before it hits this Block All catch rule… so let’s make that rule next [Rule B])
Remote IP: Any (remember, InBound Rules will always have a Remote of our PC [whether we specifically set its IP address, its subnet / Zone, or use Any])
IP Protocol: Any (regardless of what protocol they try and use. Did you notice when you selected Any from the dropdown list here all the protocol types Any covers?)

And there is our First Network Control Rule!

Rule B
So we discovered that Rule A was pretty agressive and even Blocked our LAN. But remember what we learned about Rule ID’s and the order Rules are applied? If we put a new Rule (Rule B) before Rule A that Allows other PC’s on our LAN to send communication requests, we should be Ok, right? Right. :wink:

And what if you aren’t on a LAN? Then this rule means nothing to you.

Note: Now before we get started on this Rule, I want to mention something useful that we’ll want to make sure we have set. I don’t know about you, but I don’t want to have to type the IP addresses (or ranges) for the PC’s on my netweork when I’m defining Rules, so unless you have a [LAN] or [Home Network] Zone defined, please do that now by switching to the Tasks tab, and pressing the Add a New Zone button… give it a name and a start/end range. Good!

I want to… Allow all requests for communication from other PC’s on my LAN to my PC

Using the Rule building blocks: (now we could select to Add a new Rule and move it above Rule A, or you could right-click Rule AAdd RuleAdd Before [either way works])
Action: Allow (we want to make a rule to let the other LAN PC’s make requests to us)
Protocol/Direction: IP In (The LAN communication attempt will be one we didn’t request to occur, but we expect that)
Source IP: Zone: [LAN] (Any PC on our LAN can now send our PC information/requests)
Remote IP: Any (remember, InBound Rules will always have a Remote of our PC [whether we specifically set its IP address, its subnet / Zone, or use Any])
IP Protocol: Any (All request/communication types [similar to Rule A, except this time we are Allowing])

And there is our Second Network Control Rule!

Rule C
So far we have set the way we want CPF to handle incoming communication to our PC that wasn’t requested by us. So I guess our next rule should take care of incoming replies to requests we made for communication, like to support our IE/Firefox requests for webpages, or us trying to join a friend who is hosting a LAN game.

I want to… Allow responses to come back to my PC from anywhere (the Web or the LAN) that were requested from my PC.

Using the Rule building blocks: (just as with Rule B, we could select to Add a new Rule and move it above Rule A, or you could right-click Rule AAdd RuleAdd Before [either way works])
Action: Allow (we want to make a rule to let our PC receive a response to a request it made)
Protocol/Direction: IP Out (We are starting a request that will return a response)
Source IP: Any (remember, OutBound Rules will always have a Source of our PC [whether we specifically set its IP address, its subnet / Zone, or use Any])
Remote IP: Any (let the responder to our request come from anywhere, LAN or Web)
IP Protocol: Any (All request/communication types [similar to Rule B])

And there is our Third Network Control Rule!

Rule D
Now sometimes a response to our communication request is going to come in on a diferent port. Take Bittorrent for example, we request a file and the download starts on a predetermined/configured TCP/UDP port, i.e. 6881 by default. For each file we want to download simultaneously, we need a new TCP/UDP port, i.e. to download 4 we would need 4 ports… 6881, 6882, 6883, & 6884. Similar to opening the ports on our Firewalls/Routers (without the need for forwarding, as the communication is already comming into our PC).

I want to… Allow requests for incoming TCP/UDP communication (on ports 6881, 6882, 6883, & 6884) from any PC on the web to my PC

Using the Rule building blocks: (just as with Rule B, we could select to Add a new Rule and move it above Rule A, or you could right-click Rule AAdd RuleAdd Before [either way works])
Action: Allow (we want to make a rule to let requests be made)
Protocol/Direction: TCP/UDP In (Even though we asked to dowload a file [feels outbound], the response is coming back on a different port than our request; therefore, it is going to look like the remote PC is trying to request in inbound communication)
Source IP: Any (Let the request come from anywhere… somewhere on the web in this case)
Remote IP: Zone: [LAN] (remember, InBound Rules will always have a Remote of our PC [whether we specifically set its IP address, its subnet / Zone, or use Any])
Source Port: Any (we don’t care what port it left the remote PC on in this case)
Remote Port: A set of ports [6881,6882,6883,6884] (we only want to allow the remote PC to sent to the ports we configured Bittorrent to use)

And there is our Fourth Network Control Rule!

Hopefully this has been enough combinations to give you the basis for thinking of new Network Control Rules you may need to define.

And if you’re still awake after reading my little novel here… I hope you learned as much reading it as I did learning about it before I was inspired to write this… And I’m spent… :smiley:

m0ng0d: Many tx - added to FAQ.

Great guide m0ng0d

Thanks guys. 8)

I’m hoping that this guide along with Ewen’s Internet and Networking Terminology for Beginners will create a good starting point for all who seek the knowledge.


I am a novice in computers and I have been trying to understand how the comodo firewall network rules work. I installed it and was confused on whether I had my computer safe or not. Is the configuration that is on the firewall all that you would need for most situations? I want to make sure my computer is safe.

Good work Mongod :slight_smile:

The default, Automatic Configuration, of CPF is quite robust and secure. You have nothing to worry about. I myself always use that configuration.

Would someone check these network rules?

  1. Allow IPIN ZONE Any
  2. Allow TCP/UDP Any Zone a set of ports(xxxxx)
  3. Block IPIN Any Any
  4. Allow IP out any Any

What ports do I need to allow in rule 2


Would you please check the network rules that I posted above and give me some feedback. Thanks in advance.

If your Rule #2 is TCP/UDP OUT… then set as :
2. Allow TCP/UDP OUT Any Any

Very well done m0ng0d, thanks. (:CLP)

Dude!! That rocks!!!

I was going to ask a question about my shared folder (on my router’ed network at home) - Listen carefully, here, Newbies …But I thought I would search around the forum for the answer first…

Well, I found this help on networking; and without even having read it yet, I’d bet my answer is here, and something about allowing the data flow through my firewall.

Thanks for the post, Mate



Egeman - I have not installed Comodo yet. I see your reply stating that automatic configuration is used most. Can you elaborate on automatic configuration? Do you set Comodo on auto during installation or after it’s up? I don’t have the computer education or desire to learn how to set up every action in Comodo. I would be happy with a set up like ZoneAlarm. I just don’t want to put up with the ZA problems any more. Is there a Comodo user manual I can look at before I install? I don’t want to uninstall my present set up and install Comodo only to find out that it’s over my head. Thanks in advance for any reassuring info you can pass on to me. :slight_smile:

An online form of the Guide within COMODO would be a great asset. (if their is a guide within COMODO)

cheers, rotty

How would Comodo handle this rule, which would seem to be logically, and functionally impossible; considering the current meaning of “source ip” and “destination ip”.

example Network Control Rule:

Action = Allow
Protocol = TCP/UDP
Direction = In/Out
Source IP = -this is my ip
Destination IP = -this is site X’s ip
Source port = Any
Destination port = Any


When my packet goes out the rule matches ok, but when sends a packet back to me the rule goes FALSE since is now the source. (According to current definition)

The same situation exists with one host being an IP or IP range when the other host is Any IP.

The only time an “In/Out” rule seems logically possible is when both the destination IP and source IP ranges are set to “Any”. IF Source IP was “Local Machine/Host” and Destination IP was “Remote Machine/Host” then the logic would work just fine and a single rule to cover In/Out would match the rule statement.

Therefore, is it logically or functionally possible to write a single rule to allow “In/Out” communication between MY ip range (or single address) and any other host?

I can see why the earlier definition of “Remote” was changed to “Destination”, but swapping which computer “source” and “destination” refers to, based on packet direction, makes the “In/Out” logic simply impossible…(unless the ip numbers switch computers too, at the same time)

edit 2006.09.21 0850hrs
If a list or set of ip’s were possible, the logic could be satisfied by using:
Source IP =,
Destination IP =,

How would Comodo parse and implement the example Network Control Rule? Since sets or lists of IP’s are not currently possible, would 2 rules need to be written to achieve the desired result?

After giving this some additional thought, and considering the latest definition of “Source IP” and “Destination IP”, and those limitations, the solutions i see are:

  1. Whenever “In/Out” is selected for a rule: source ip AND destination ip must default to “Any”. If u want an In AND Out rule for a specific addy or range then u will need to make 2 rules. The underlying firewall code and interface will need to be changed to “grey out” any choice except
    “Any” when an “In/Out” rule is selected.

  2. Change “Source IP” to mean (and display) “Local Host/Machine”. This will always be YOUR IP. Change “Destination IP” to mean (and display) "Remote Host/Machine. This will always be the remote host(s) IP specification. The underlying firewall code and interface will need to be changed.


Hey sticky,

Please bear in mind that teh following is just my opinion. I simply don’t use In/Out rules at all. I create separate In rules and separate Out rules. In the scenario you’ve outlined, this would necessitate four rules - in and out for each IP. I prefer this method as I can more readily monitor traffic in and out. Logs are easier to follow and diagnose, in the event of a stuffup, as well.

Hope this helps,
Ewen :slight_smile:

So if an In/Out rule is fired you can’t tell whether it was going in or out?

cheers, rotty

mOngOd -

TNX for the great explanation of NCR! I got a lot out of it. Good mental exercise; stretches my li’l brain. (:NRD)

I certainly agree about not using the “In/Out” rule in part. I wont use (or make) an "“In/Out” rule UNLESS “Source IP” and “Destination IP” both equal “Any”. Mainly because the logic is impossible if an IP range or address is used in either field. (add “Source Port” and “Destination Port” to our equation… (my head hurts, anybody got an aspirin? ;D))

My only real point is that I wanted everyone to be aware of the impossible logic that currently exists when trying to make such a rule under the current definitions of “Source IP” and “Destination IP”.

I might make an “In/Out” rule with a specified IP if anyone knows how the rule would be parsed by the firewall…
I could fire up something like Ethereal and get a friend online to test what the firewall will do, but at this stage of the firewall’s development this is a job for the developers… (even if i reported the results, this is a problem that will need the developers’ attention anyway. I believe that if they haven’t done this yet, they certainly will… ;))

It really does need to be fixed one way or another…

I have only been using Comodo firewall for several days now, and except for this one irritating issue, like many others I think that (R). With just a bit more tuning it might go into history with the likes of Kerio 2.1.5… High praise indeed.

Thanks for the feedback, I do appreciate it. (:KWL)