On PA5050 running 7.1.5, in the monitor:traffic logs section, traffic that matches interzone default rule shows up as matching the first rule in the list. The first rule is configured like so:
source zone: any, source address: any, user: any, destination zone: any, destination address: any, application: I picked one that is not in-use e.g. 'docstoc-base'. That is, the rule is configured to match on any source/dest/user and to match a specific application.
When I apply this rule, traffic flows as expected: firewall rules lower in the list are applied to allow desirable traffic, and undesireable traffic is denied by interzone-default rule at bottom.
However, the traffic logs show traffic being dropped by that first rule instead of interzone-default.
I opened a support case because I expected to see 'interzone-default' rule (it is set for log-at-session-end) in the log when traffic is blocked because it does not match an explicit allow rule higher up in the list. I was told that this is expected behavior because traffic is matched 'left-to-right' and then 'top-to-bottom' (per this article: https://live.paloaltonetworks.com/t5/Management-Articles/quot-Not-applicable-quot-in-Traffic-Logs/ta...). That is, app-id settings are not applied until after to/from/ zone/address is evaluated. However, this doesn't make sense to me because if it were true:
I feel like I must be misunderstanding something, can anyone educate me on this?
Your first rule will match all traffic initially when evaluated, because the first packet is not enough to identify the application. Every time the application shifts (as the firewall learns more about the traffic with subsequent packets) it will re-evaluate the rules.
Think of it this way:
1. The firewall gets a packet on some port that *could* be docstoc-base. The rule has "any" for everything else, so it goes ahead and transmits the packet tentatively matching the first rule. Remember app-id has not been completed yet so nothing will be denied yet
2. One or several more packets arrive, and the firewall now sees that the traffic is something that can still shift to another app, like web-browsing. The firewall re-evaluates the policy again, and this time only rule 1 could possibly match (maybe you have other rules for other apps).
3. More packets arrive, and the firewall can now determine that the app is NOT docstoc-base, and with no other rules matching it finds the intrazone-deny rule.
Because the traffic last matched the first rule, which was an allow rule, that's the rule that is shown.
If the firewall was unable to match any rules on the first packet, you would see the "not-applicable" app and it would hit the intrazone-deny policy.
To address your bullet points:
You might want to take a look at the life of a packet document. It goes through a lot of the deeper details about this whole process:
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!