Application Monitor

SPI is present in NetMon. Having a rule for OUT in conjunction with SPI means that i can receive packets from outside (lol), as long as they were requested by me, or from a comunication started by me (request webpage- got it).

The thing is, since AppMon apparently does not have SPI, sometimes it nees IN rules to allow comunication started by us.
It’s not an INbound rule in the true sense, since it’s not unsolicited. That’s why even if you open IN for Emule in AppMon, you still have a low id. You have to open a true INbound rule in NetMon for that specific port used by Emule to properly work as P2P, and accept incoming and unsolicited packets.

BUT then, what is IN rule in AppMon?? I’m sure there’s some rational explanation, but i do not have one lol.
Sometimes it’s needed, sometimes not. Why? What’s the mechanism that makes me need and IN rule for an application, or for that specific Port?

BTW, IN/OUT, unless it’s for Any-Any, seems non functional. If i specify a port or IP, who’s who (source and destination)? If it’s In, it’s one thing, if it’s Out, it’s another, for the same rule!?

Now picture Local and Remote :slight_smile:

Even with local and remote, the INbound rules for AppMon needs clarification (in my head it does!). Maybe better integration with NetMon’s SPI?

TIA to all those that can help me sort this out.

Welcome to the forums Pedro* 8)


The way I view NM and AM rules is simple this:

NM rules do the protocol stuff, that is open or block a port for a specific protocol.

AM rules make use of the open ports allowed by NM, but they still need to be told if it’s in or out…

btw have you read the:

How To - Understanding & Creating Network Control Rules properly

and maybe:

Advanced Application Monitor Rules for Proxomitron / Firefox and IE included.


Toggie :slight_smile:

Thanks Toggie, i do appreciate it. But there’s no answer to my questions in those links.

When does an application need INbound AppMon rules? I know how to work with NetMon, then i just allow whatever AppMon rules are needed, because they are NOT Inbound rules. What are they? Why and when do i need IN on AppMon?


Strangely enough, I can’t think of any specific occasions for when you would want and AM IN rule. The only IN rules I have in AM are for loopback.


Pedro and I have been PM’ing about this earlier. Aside from loopbacks and a required opened listening port for incoming connections in P2P applications, I also need it for Yahoo Messenger. I tried it before by blocking incoming in App Mon, was still able to log on, but it won’t function (can’t chat, broadcast webcam, etc.).

I’d forgotten about p2p, as I recently uninstalled mine. The Yahoo requirement is interesting…

A game that i occasionally play is America’s Army. For that i need some rule for UDP-IN, in AppMon, NOT NetMon. Checking the rules, it also displays as destination the IP for the corresponding server, so it either is not IN because destination is not me, or “destination” isn’t destination.

Ok I just tried this again. I only allowed all OUT for YM and delete the IN portion. Here are the following IN and port # alerts:
TCP 5052, UDP 1851, UDP 1852, TCP 5101, UDP 1854, TCP 5057. They were sequential within 5 seconds of each other without me doing anything but merely remaining idly logged in. Then I opened webcam and it alerted TCP IN 5103. Actually, I blocked that last one and webcam still works (although I don’t know if others can see me since none of my contacts were online).

Screenshot Sample shows it’s a listening port (my loopback checks are skipped). Why would an app require so many listen ports besides it being adware?

Edit: I blocked all TCP and UDP IN and can’t log on. Also, these specific port #'s seemed to be constant in that if I log out and back in, it doesn’t alert for others. Something with these are tied to YM (the latest ver).

[attachment deleted by admin]

Interesting :slight_smile:

The only info I could find on YM needing an IN port, was for:

Yahoo! Messenger Call Center

Protocol: UDP
Direction: Outbound
Remote Port(s): 6801
Action: Allow

Protocol: UDP
Direction: Inbound
Local Port(s): 5000, 5055
Action: Allow

Everything else seems to be OUT.

BTW I like this from the YM help site:

For most home editions of firewall software, you will need to open all outgoing TCP ports in the range of 5000 to 65535 so Yahoo! Messenger can make Yahoo! Voice calls.

Yea! just open everything :slight_smile:

Typical adware company slogan…tsk tsk


I’m not as worried with it being all OUT vs all IN, but then again, there’s no Network rules to allow incoming (except the reserved one for uTorrent), so my ports are still closed with YM on. Still goes back to Pedro’s original question why only some apps.

why only some apps.

Good question, but I really don’t have an answer right now :frowning: Maybe put Wireshark on the job and see what’s going on…

That’s the 2nd time Wireshark has been recommend to me. (I even have trouble with process explorer 88)).

I think that you also needs an Application IN rule to let the firewall knows that that application have permissions to listen packets on that port.
Otherwise, all the applications could listen the packets that you allowed on the Network IN rule or by SPI.
It’s a security extra…

A Network IN rule should be required only if need to receive some unsolicited packet…

The alert is also for the user notice that some application wants to acts like a server, and then decide if he/she needs to make an network rule to allow that traffic…

Thanks VC, that really helps me sort things out! Now i’ll digest that by using CPF (sinking that in my head, i’m like that…)

(maybe i’ll buy you a beer someday)

You are welcome :wink:

I guess one more question arises from the help file:

The Second Column (Destination) represents the remote IP Address of the application.
So why is it that sometimes, for an IN rule in AppMon, some have my internal IP (LAN/ 192.168.x.x), and some have the IP for the game server for instance? If it's the remote IP adress, my IP should never appear, if it's destination, the server would never appear. So ??? again


But you can want that the application only receive packets when you have a specific IP or when you sent from a specific IP… :wink:

It is all about flexibility…