For usability reasons, the firewall will not terminate previously allowed existing connections when you switch firewall modes, unless you use block all mode. When you switch to custom ruleset, you will only get an alert for new attempted connection requests when there is not rule defined for the connection request.
Blue Testa describes that incoming traffic that comes in reply to a connection request from your computer will be allowed. That is how a Stateful Inspection Firewall like CIS works and is supposed to work. When there is incoming traffic that is not in answer to request from your computer it should be blocked or you should be asked.
Unsolicited incoming traffic first goes through Global Rules (you will be asked or it will be blocked depending on how you set the Global Rules with the Stealth Ports Wizard) and then through Application Rules. In my case I have a port open for eMule in Global Rules to allow for incoming traffic. The problem I am seeing is with the handling of the Application Rule for eMule. It does not mean Global Rules as set by Stealth Ports Wizard is not working.
Thanks for the info. So if unknown applications are allowed as outgoing only, they are allowed to establish incoming connections as well?. I mean, is it a risk allowing unknown apps treated as outgoing only? (except of course autosandbox can reduce further damages).
No, if an unknown application is able to receive incoming connections by listening on a given port number, you first need to have a global rule that will allow the connection attempt through, then you would be asked if the application is allowed to receive the connection unless a rule for the application is set to deal with the request.
Return traffic from an outgoing connection does not mean an incoming connection. The connection direction is based on which direction it originates from, your system to a remote host = outgoing connection, a remote host wants to start a connection to your host is a incoming connection request.