What is means "remote ip" in appication rules with dir= inbound ?

And of cause, what is meant with it, if direction is In/Out ??

Is it meant my computer or the other one ?

I ask this, because I think, that CPF is preventing any traffic to a port, if you specify other than “any” in an inbound rule.

See, when an app starts to listen on a port, it dont know the IP of wich, maybe, an request will come !

Any knowings ?

THX

When I was prompted for an incoming connection to svchost.exe on port 135, I denied, then opened up the rule. The ip address was set to 0.0.0.0, so I’m guessing that is my computer. I’m also guessing that setting to “any” would refer to all remote addresses.

:slight_smile:

What I meant was: for example in network mon. rules, if I have direction=out, then the remote is the “outside” computer. If I have direction=in, then remote is my computer. ( In Sygate, this was called like the “point of view logic”). This is, as I found it explained by egeman in this forum.

So, if I take direction= in/out (both), what logic applys ??

The same could be in question for application rules.

I hope I made clear what I meant now.

Now:

Ok, I installed the new beta. Now it seems its all new logic in the popups.

Now, Internet Explorer isn’t needing “act as server”, I am even not prompted for that. I think, this is because the old version had some flaws in decide what is real inbound or outbound.

Eveb if I turn off “skip loopback” for TCP and UDP, I dont get a message that IE is trying to “act as server”.

I’m not sure wich version is “right”.

Greetz

Remote IP/Port refers to the other computer and Source IP/Port, your computer.

:slight_smile:

Hmm, well that is not true, if this forum (egeman) is right.

I read, that remote is your computer for inbound traffic and for outbound the other way round.
This is because I asked, what applies if direction is BOTH, lol.

greetz

Are you sure that isn’t reffering to application rules? If that is the case, now I’m confused ???.

:slight_smile:

THis issue wth Remote IP and Source needs to be sorted out once and for-all. I also would really like an “Allow Loopback” button for each application in the application control, so you can allow loopback for each process.

Cheers, rotty

Hi Guys,

That Remote keyword has been changed to “Destination” starting from the release of 2.3. So I think it wont be confusing anymore.

Egemen

If you have created a rule controlling outbound traffic then the source should be your own network and the destination the internet address(s).

If it is controlling inbound traffic then source is the internet address(s) and the destination is your own network?

Is this correct?

Cheers, rotty

Why not have “local” for your computer and “remote” for all other computers. That way, local will always be known as your computer and remote, everything else.

:slight_smile:

I agree.

Cheers, Rotty

I think this is what egeman meant with “destination” in next release.

But for now: In app rules, I think “remote” is ALLWAYS the “outside” computer.

Is this right, egeman ??

hmm, now I’m thinking twice!

so does the sense of the term “remote” (or “destination”) CHANGE with respect to the connection DIRECTION in application rules

I tend to agree that perhaps LOCAL and REMOTE might be better choices since there is never an ambiguity… yes/no?

I’ve tested this as oart of another thread.
https://forums.comodo.com/index.php/topic,838.0.html

“Remote” changes depending on whther the connection is inbound or outbound. Currently this is confusing and could lead to issues.

Changing Remote to Destination would help remove the confusion BUT does not really resolve the issue.
Most other applications use Remote/Local and so would it easier to understand if you have used a firewall before.
More importantly, by having the IP fields switch dependent on direction means you cannot have a rule for combined in/out as the IP’s you have entered will be the wrong way round for one diection, yet this is an option in the dialogue when setting up the rule.

This really does need resolving.