Rule matching: left-to-right question, unexpected output in traffic log

Announcements

ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

Reply
Highlighted
L0 Member

Rule matching: left-to-right question, unexpected output in traffic log

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:

 

  • You wouldn't be able to create a rule blocking an application without to/from zone/address criteria
  • If you did create an application blocking rule, your to/from zone/address criteria to the left of it would be evaluated first, and then the firewall wouldn't ever evaluate the application rule.
  • I should not be able to pass any traffic past rule 1 (it should block everything, by left-to-right logic mentioned above) because I have it configured for from:any to:any, but yet, I can pass traffic as expected and rules below rule 1 are evaluated as expected.

I feel like I must be misunderstanding something, can anyone educate me on this?

 

 

Highlighted
L7 Applicator

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 can always deny a specific app regardless of whether or not you define the zones/addresses in the rule. The firewall itself cannot determine the app until the zones/addresses are evaluated, but that happens with that first packet. It's just that the app won't be known on the first packet.
  • Sort of. If your policy has a zone/address and an application, and the rule is set to deny, it won't actually hit that rule and deny the traffic before the app is determined. The exception to this is if you define the port. The app is irrelevant if you're denying the port as well, since it won't matter what the app turns out to be if you're going to deny it anyway.
  • See my first point above. It passes the first rule but tentatively shows it as matching since the app hasn't been determined yet.

 

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:

https://live.paloaltonetworks.com/t5/Learning-Articles/Packet-Flow-Sequence-in-PAN-OS/ta-p/56081

 

Best regards,

Greg

edit: formatting

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!