We had a remote session with Check Point TAC, kudos to TAC for being extremely efficient here even though I created the ticket as a low-priority case.
It all made sense from a technical standpoint. We know how to successfully create these kinds of rules, and it's something I should have been aware of myself considering the FW chains and their order.
With R80+ and the introduction of the unified policy, you are able to utilise applications directly in the ruleset. There is no longer a need for a separate ordered layer for application control. This makes it way more flexible, and from what I understand the unified policy is the recommended way of utilising application control on R80+ as with ordered layers all your rules have to first match the network policy, then match the application control policy. With a unified policy, you are supposed to just hit one rule and be done. It's more efficient. Being able to utilise applications directly in the network policy is also more flexible and will lower the complexity.
But it doesn't seem like the software on the gateways have been fully optimised to take a unified policy into consideration. And this is what was causing this to fail. You can't simply create a flat rule in a unified policy and utilise an application and expect it to work. The traffic still needs a regular firewall rule allowing for the traffic for application control to be able to kick in.
This made it really confusing. So when we have a regular firewall rule not utilising application control saying src: 192.168.1.10, dst: Internet, service: https, action: drop it doesn't matter if this rule is above or below the rule containing the application. FW blade comes before application control in the FW chain so even if you have it like this:
Rule 1:
src: 192.168.1.10, dst: Internet, application: vg.no (*.vg.no), action: accept
Rule 5000:
src: 192.168.1.10, dst: Internet, service: https, action: drop
Rule 1 won't work. Rule 1 is utilising application control, the initial traffic will hit an FW Blade rule first, and if there is no FW Blade rule allowing for the https to happen in the first place, your application control rule no matter where it is within the policy will never be taken into account.
This is obviously extremely confusing. And to be honest it feels like an oversight? With older versions where the unified policy was not a thing, this would never be a problem as traffic would never reach the application control policy as you would only move to the next ordered policy after getting accepted in the first policy. You would never have, or expect your application control rules to be taken into account unless you had an FW blade rule in your network policy allowing the traffic in the first place.
This same logic still applies in R81.10, even though with a unified policy enabled. Making it all really confusing as it doesn't really make much sense unless you know how the FW chains work. So you have to ensure that you have an FW blade allowing for the https traffic to work, only then will the application control rule be able to work. And to make this extra confusing the rule numbering doesn't matter, you can have FW blade rule allowing for https at rule number 5000, and your rule using an application at rule number 1. It doesn't matter, it will still get its https accepted in rule 5000, and then utilise rule 1 for application control even when all of this lives in the same network policy as a unified policy.
Knowing all this it obviously makes sense, and it also means that if you are going to utilise applications in a unified policy you should put it into an inline layer as that's the only way to ensure that it looks organised and structured. If you try to put this flat without inline layers it becomes a real mess rather quickly considering knowing how FW blade rules will be taken into account before any rules using applications regardless of their rule number.
It's not all that bad as it makes sense to strive for using inline layers for these kinds of rules, to begin with, but the fact that you don't even get a policy verification error when using application controls flat in a unified policy when you have rules that will clearly not work is not great. This is something that should be added for a better user experience. When the logic behind the behaviour doesn't really make much sense for anyone not knowing the FW chain logic behind it all there should at least be some feedback within Smart Console telling users that they are trying to apply non-working application rules.
But to be honest this feels like an oversight more than anything else. When R80+ provides you with the capability of utilising applications within a unified policy there should be some logic making this work automatically. There should be some functionality here recognising the fact that the user has created a flat rule saying src: 192.168.1.10, dst: Internet, app: vg.no (*.vg.no) and automatically have the FW blade recognise this and make sure that http+https from 192.168.1.10 for this should be implicitly allowed. There is really no reason to expect otherwise. Why else would the user create such a rule in the first place? It just add additional complexity, steps and confusion. Especially considering the applications themselves tells the users that the application allows for services: web browsing and the settings for application control tells you that this entails http, https, http_proxy an https_proxy services.
Certifications: CCSA, CCSE, CCSM, CCSM ELITE, CCTA, CCTE, CCVS, CCME