@marcelocampos,
can I assume that traffic is not establishing a session and that the policy is doing its job of accepting "ANYDESK" and denying everything else?
That's not really correct. Incomplete traffic is simply caused by the three-way handshake not completing, or by traffic which doesn't pass enough traffic for the application to be identified. Once enough traffic is passed to actually identify the traffic properly however, the traffic would be re-analyzed and no longer match your security rulebase entry allowing anydesk traffic.
And the last one, when I configure a security policy towards any internet, only specifying the application and its dependencies, am I opening a communication flow towards any destination according to the applications and dependencies?
example a conection ssl to microsoft destination can forward by the policy maked for anydesk?
This depends on how you have your security rulebase actually built out. If you included the application members [ anydesk ssl ] to satisfy the dependency within the same policy, then you are by virtue allowing all traffic identified as ssl through this policy. As long as you are satisfying the application dependency somewhere in your rulebase, you don't need to include ssl within the anydesk entry and can just leave the application as anydesk.
I wouldn't really worry too much about the incomplete traffic; that will be allowed in your rulebase as soon as you add a security entry utilizing app-id, the traffic will just match the first rule which allows it access across that zone.
For your next question I would generally recommend not including common dependencies directly in your AnyDesk rule, because it's likely already being satisfied in your rulebase. Just have leave anydesk in this security entry, so that the rule being hit actually makes sense (IE: AnyDesk traffic matches your AnyDesk allow entry, while SSL traffic matches your general browsing access).
Hopefully that helps make things a bit more clear.
... View more