The log entry will NOT appear if the DPI simply failed to detect the application
The Admin will NOT see the “Allow due to insufficient app data” indication under the “Action” column in the logs if the DPI (network application) failed to detect after 12 packets.
If the network application wasn’t detected after 12 packets then the Advanced Cloud Firewall (ACFW) will try to match on the “leaf” data already assembled: so TCP + SSL/TLS + HTTPS for example when a complete leaf might look like TCP + SSL/TLS + HTTPS + Salesforce (with Salesforce as the network app in this example). If there was a rule for either TCP or SSL/TLS or HTTPS then that indication will be given in the logs instead.
The conditions when the log entry appears:
The Admin will only see the “Allow due to insufficient app data” indication under the “Action” column in the logs if the session was terminated gracefully or suddenly before the network application identification process could finish. The network application identification process occurs on or before the 12th packet but mostly between packets 3 to 7 and as counted from those sent from the user /session-initiator perspective.
Getting the “Allow due to insufficient app data” indication assumes the ACFW rule was ranked appropriately versus other possible ACFW rules so that TCP and then SSL/TLS and then HTTPS were not blocked prior to the rule with the Saleforce application identification failure. It is these few (more than 1 but less than 13) packets associated to the precursor identification “leaves” that was the allowed traffic referenced by “allow due to insufficient app data”.
As distinct from network applications, network services are just protocol (TCP, UDP) + dest:port and so always match on the first packet. The user will never see an “Allow due to insufficient app data” message because of a network service condition in a CFW rule.
Best practice tip
The use of network applications in Advanced CFW rules is a tradeoff between certainty (network applications are the highest confidence identifications) and delay (can identify as late as the 12th packet of any given flow or not at all).
When a rule has a network application, then all qualifying flows will potentially match the rule until the network application is identified and the condition is either true or false. It is therefore recommended that whenever possible, rules containing network applications are generally ranked lower than rules where a first packet identification is possible and in particular rules where block actions occurs. This allows for those rules to match and take their configured action whereas only a subset of all flows are examined as part of the network application identification.