R80 Inline Layer Issue

[Gaurav_Pandya]

Hi,

I created an inline policy on R80.20.  I did it by going through the logs to see which access control rule was used for each app control rule.  Then I created layers and pasted all of the app control rules into appropriate layers assigned to each access rule per the action column.  I left entire the app control policy in place and pushed this policy out, and everything broke.  In the logs, I saw a lot of CP Early Drop.  A lot of the logs were the remote users trying to get DNS, but I know that more than only that traffic broke.  I restored an old policy to get it back up.

I’m not sure what I did wrong.  The CP Early Drop indicates the packets had no way out of the new policy.  I was sure to set each layer to implicit allow, and remove the default clean up rule that is added to each layer.  One possibility was that it was failing because I didn’t add a specific allow rule at the bottom of each layer.  However, I have not been able to replicate that as a problem in my lab.  Does anyone have any ideas?

[Alessandro_Marr]

do you have a application control blade and firewall inside and enable on this inline layer? and https inspection too? 

did you enable drop templates on secureXL?

[Daniel_Westlund]

Yes, Firewall and Applications & URL Filtering are the enabled blades on this and all layers.  HTTPS Inspection is not enabled.  Drop templates are also not enabled. 

[Alessandro_Marr]

How is fail mode configured in advanced settings of application control?

[Daniel_Westlund]

Do you mean in the layer?  In the layer, Implicit CleanUp Action is set to Accept.  In the Application Control policy, there is an Any Any Allow rule explicitly at the bottom.  I am not aware of a fail mode configuration in advanced settings for the Application Control policy.  If there is such a thing, can you point me toward it?

[Daniel_Westlund]

What I mean is, I know where this setting is in R77.30 but not R80.20.  I would think fail open but don't know where to check.

[Alessandro_Marr]

Menu:

Manage & settings...

Blades...

Application Control & URL filtering...

Advanced Settings...

[Daniel_Westlund]

I may have an answer.  I noticed that the Policy layer has both blades Network and Application Control.  This is because we wanted to have the Application Control layer as a backup in case something didn't work with the Inline layer.  However, I didn't realize until now that in the Network layer (/blade), only Firewall is checked.  Not Application Control + URL Filtering.  So the packet gets to the old access rule that allowed it out, but since it's not doing Application Control, it can't get out from the Network blade?  I will report back once I test.

[Gaurav_Pandya]

ok. This logic seems to be reason. 

[Daniel_Westlund]

Thanks everyone.  Yes this was the problem.  It would make a good SK.  Below, I have the Application Blade here because I'm not going to remove the Application policy until I know my inline layers are working.

However, I needed to click the menu to the right of the Security Blade in Access Control, and choose Edit Layer.  From there I had to enable the Application and URL "Blade" inside the Security "Blade".

This was a very easy mistake to make and a hard one to fix, and it was a big deal for one customer and would have been a huge deal for the next if I didn't find the check box.  Probably the best thing would be for Check Point to not allow you to install policy to a Security Blade with Inline Application Control rules if App & URL Filtering aren't checked.

[Gaurav_Pandya]

Yes Correct. If App & URL filtering is not checked then it should give warning message when we create rule for this.

[PhoneBoy]

Ronen Zel‌ think it's a good idea to turn into an SK.

[PhoneBoy]

If you have an Explicit "any any allow" rule at the bottom of your App Control rulebase and/or the Implicit Cleanup rule for the layer is set to Accept, it should get through.

Am curious if the "early drop" is happening in the first layer instead (which adding App Control to won't necessarily solve).

[Daniel_Westlund]

Yes, it was happening in the first layer.  It showed the blade as Security Inline Policy, and then CP Early Drop.  I think the packet hit the Security Rule with the Inline layer, but then couldn't get out on the Inline (App Control) rule because that blade wasn't on in the Security Blade, so the packet had no way out of Security.

[Alessandro_Marr]

Inline layer.