If the first packet of a new connection matches all other rule criteria and the destination port number of a service with "Protocol Signature" enabled, in order to determine if the rule matches, the connection attempt is now allowed to proceed through its TCP 3-way handshake and pass a few data packets. Note that this occurs even though no rule has been conclusively matched yet. The data packets are evaluated by the protocol parser and the protocol type determined (HTTP, FTP, IMAP, etc.); this process causes additional overhead in the firewall vs. attempting to just match against a service object that does not have "Protocol Signature" checked, which is simply a port number match against the first packet of a new connection with no need to let the connection initially proceed further.
As the protocol has now been conclusively determined, the firewall looks at the protocol defined in the matched service object and if it is a match against what was detected in the connection that's great, all criteria in that particular rule have now been matched and whatever action specified in the rule is executed, usually it will be an Accept.
However if the protocol type does not match after all this, it is simply not a match against that particular rule and evaluation proceeds down the rule base looking for another rule match. Generally one will not be found and the connection will be dropped and killed, even though it was initially allowed to proceed just far enough to determine the protocol. This behavior will look strange to scanning tools like nmap and Nessus who will report that port as "open" even though there are additional restrictions being imposed on the connection such as protocol type, application, URL category etc.
From a rulebase lookup optimization perspective, it is beneficial to use service objects that do NOT have Protocol Signature selection selected in the first/Network layer in the case of ordered layers, then invoke applications or services with Protocol Signature set in the next layer which is typically the APCL/URLF ordered layer. In the case of inline/unified layers use services without Protocol Signature set in the top/parent layer, then invoke Protocol Signatures/APCL/URLF/Content Awareness in the sub-rules/sub-layers of that parent rule. Structuring rules like this allows the firewall to efficiently drop traffic based solely on the first packet of a connection and a straight port number match, with no need to let the connection proceed further for protocol evaluation (causing overhead) then ultimately dropping it. This approach also tends to make auditors much happier because they won't mistakenly see large numbers of ports as "open" in their scan results.
Before anyone freaks out about this "letting the connection start" behavior, it is clearly documented right in the SmartConsole itself. See attached screenshot.
New 2-day Live "Max Power" Series Course Now Available:
"Gateway Performance Optimization R81.20" at maxpowerfirewalls.com