Source/Remote IP confusion

Sorry if I have misunderstood something but cannot fathom how you would be able to apply these if you set up a single rule for both inbound and outbound traffic.
For example, I may want to allow any traffic to or from a particular server.
If I create a seperate inbound rule it would have the servers IP for source and mine for remote.
If I create a seperate outbound rule it would have my IP for the source and the servers for remote.
However, if I try to create a single rule for both inbound and outbound there is no way for it to work as the source/remote IP’s would switch depending on the direction of the traffic.
For most firewalls you specify local and remote IP’s where local would always be your IP and remote the, well the remote one. This way it doesn’t matter what direction the traffic is in.

Am I just being stupid or do I have to create a load of seperate rules ?

Not sure if this posting will help…worth a look:,668.0.html

Thanks for the reply garry,
Unfortunately that just confirms things.
You should not really have to enter your local IP as the remote address for inbound, it’s backwards and , as I said originally, means I cannot see how you could create an inbound/outbound combined rule :frowning:

Well, I asked myself the same question ?

any answers for the developers ???

Just goto Security>>>Tasks and add a Trusted Network and add the IP of the server. Next click Add Trusted Zone and select the server in the drop down. It will do the rest for you!


But can you explain the issue with remote and source, if direction is BOTH ???

Trusted zone gets around the issue but it seems extreme to have to do this to allow access to a single server.
So far comodo has been very good (barring a few niggles) and this might seem like a small issue but it could lead people with less knowledge to create erroneous rules and potentially open themselves up trying to solve it.
Remote should always be relative to your PC and source should be renamed to local and mean it.

I have ALOT of knowledge of Ip addressing and rules based firewalling, but i am sometimes slow or may have had a few beers (-: .

The reason i am “Tooting my own horn” is because i am trying to emphasize how this confusion worries a technical person (-: . And perticularly if i have had a few beers, i may not be up-with it FULLY.

My problem is that with this issue it is so critical their needs to be 100% understanding what the source and destination mean, the consequances are great.

Cheers, rotty

Inbound would mean access to you and would need your IP for this. When I have my son remote in to my pc, the inbound must be used with my local IP and when I remote into his, his inbound is his local IP. If outgoing, that would be his IP and vice versa. I may be wrong here but you have to “talk” to the remote pc in order for it to communicate with you. The set of rules would be your local + remote local to communicate. So really it isn’t backwards. Inbound is your inbound traffic which the remote needs your IP for communication. The outbound, you need to communicate with remote, hence the remote’s IP. It makes sense to me. Just for the record, I am horrible at explaining so I apologize. If you create a rule for this, you could remote into a pc which allows you and you would need the remote IP, but still allow your IP for communication. You could block remoting into yours however, but I do believe your local is still needed.

Just a note, i am tired so if this seems like soup, i’ll re-read it in the morning and fix my mistakes,lol. :wink:



I am running into a lot of frustration with this issue also. As pointed out, since source and remote change according to the direction there is no way to have a single rule with direction set as “both”. Once I came to grips with this I soon understood why the default rules always had separate in and out rules for each item that needed to be resolved.

If this is to remain why even bother having a direction choice of “both” or “in and out”?

Thats exactly why I proposed this app rule structure:

There should be Local Port (in) - Remote Port (out). Also there could be also Local IP column, for situations where there is for exaple more than one network adapter and the user wants to limit the rule only to one of them.

There is no Remote in CPF starting from the CPF 2.3 which is going to be released on thursday. Source and Destination are the naming convention from now on.


Did you take a look at the picture I posted? I’m allready using the source - destination terminology for IP there, but you can’t use it for the port as it’s always the destination port.

Moreover, this terminology change doesn’t fix the In/Out rule problem.

IF the direction is BOTH, this means dont care the direction but just match the other parameters. Direction here is the physical direction of the packets. Namely, if packets are coming to your host or going out of your host.

If you specify a direction in the rule, CPF will only apply that rule to the packets in that physical direction. If you select BOTH, then CPF will apply the rule to both directions.

Now, that’s exactly what doesn’t give any sense. The rule allows you to specify only the remote IP and remote port, but remote for outgoing communication is not the same as remote for incoming communication. For outgoing, it is the remote adress and port of computer you are connecting to, for incoming, it is your local adress and port, where it should be the remote adress of computer that is trying to connect to you and your local port, it is trying to connect to.

There is no problem. Direction is explicit. It means to or from your host.

Lets assume your computer’s IP address is And you want to create a rule for another host

Lets say we want to block incoming traffic from to our host.


These 2 rules do the same job. But the second rule is applied to the outgoing traffic, which is guaranteed not to match because → can not be an outgoing traffic. Direction field is there for you to write more optimized rules.

Here are some UNLOGICAL rule examples:

BLOCK TCP IN FROM TO ( → can not be an inbound connection request) .

BLOCK TCP OUT FROM TO ( → can not be an outbound connection request. Note that this type of traffic can occur but only as a reply to a previously established connection for which stateful inspection forces CPF to skip the rule) .

Rules must follow the logic otherwise they will not work as expected.

Thats why the name Remote is changed to Destination. If inbound destination is your address. if outbound destination is remote address.

We are talking here about the IN/OUT rule, correct? So, what would you call the IP and Port in this case? Destination? Source? For what direction IN … or OUT?
All other firewall programs either don’t have an IN/OUT rule, or they allow to specify separate IP/Port for both IN and OUT communication in one rule. The way it is now in Comodo doesn’t realy give any sense.

Well. Lets go over examples otherwise noone will be able to follow this thread:

Here is a case you are refering to: “ALLOW IN/OUT TCP TO IP ON PORT 80 for iexplore.exe”. Such a rule is a valid but quite a poor rule.

When iexplore.exe connects to, then this rule will allow it. This rule will also mean “If iexplore.exe tries to accept a connection on LOCAL IP ON LOCAL port 80, ALLOW”

Application rules doe not have source IP/port fields/ So everything means destination in that context.

for the application rules, IN/OUT could only be useful while creating ANY IP ANY PORT type rules.



It is useful to reduce those 2 rules into one rule. In my previous messages, I was refering to network monitor rules.

Application rules interface is being redesigned. So you will be able to create powerful rules as in the network monitor in the future versions.


Finaly an example, that makes sense (and confirms the problem with current IN/OUT app rules logic). Realy looking forward to the new app rules interface.