Possible bug in SmartLog traffic to rule attribution

[Vladimir]

I've run into this issue:

Two layers containing firewall blade.

First one consists of just two rules, with second being cleanup pass-on to the second layer with no logging.

Second layer actually contains the rules that are expected to log the traffic.

But when the log for the rule in the second layer is viewed, it idicated that the rule two of the first layer is handling this traffic.

While in a sence it is true, it missrepresents the subsequent processing.

Excluding rule 2 from the log returns empty screen:

[PhoneBoy]

What if you pull up the log card for one of the logs?

[Vladimir]

The log card itsels still climing "Rule 2 cleanup:"

Buth the "Matched Rules" tab does show the entire path:

If this is by design, I think it is a questionable idea as there are no indication in the logs of the actual traffic processing by rule 7.3, including missing NAT information.

Also, when Geo Policy is enabled (or, perhaps, when I am using geo objects in the rulebase), the SmartLog simply lists traffic as allowed. You have to actually open the log card to see the reason for it:

Perhaps I'm simply unaware of how to differentiate those logs properly, but I could not find any way of making it clear in the running log why this traffic is allowed.

[PhoneBoy]

In the SmartView "running log" list, we only show one rule and we seem to show the first rule that matches in the first layer (even if that rule isn't set to log).
I've seen that before myself, and believe it's expected behavior.
It's clearly not optimal in this case.

It also looks like you're using the legacy Geo Protection, which applies before the regular Access Policy similar to "Core Protections" in IPS.
Whether you should be using that is a separate question.

Also, this particular use of Layers is interesting and, I have to admit, it hadn't occurred to me.
But, if you're using legacy features, this would actually be a clever way to handle it.
I am curious why are you using a legacy-type rule for Remote Access. 

[Vladimir]

I'd like to try multilayer processing with different blades to see if same behavior persists. If it does, it is a problem, since we are not seeing final rule that allows the communication to take place and, as I have mentioned before, NAT.

Legacy Geo I can do away with but, I suspect (without looking a the screen to verify), we can differentiate when the log is generated by IPS in the running log at a glance on the left side of the screen.

The reason I am using this dirty hack for legacy remote access is my luck with one of the clients: they cannot get approval for the implementation of IA, nor the LDAP account units with the rights CP requires and have requested a way to implement Remote Access solution with 2FA with no RADIUS access. So I was left with legacy remote access with local users and dynamic ID via email to handle it. Thus the requirement for the additional firewall layer:)

Do let me know if it could've been handled differently please.