Create a Post
Showing results for 
Search instead for 
Did you mean: 

is it possible to change settings for how application control works?



We have an odd problem that I was hoping someone could shed some light on. The rules below is what is the issue.

2019-05-02 08_20_30-sod-as23613 - sod-as23613 - Remote Desktop Connection.png


Normally both these rules are active. We have a web application that is a bit special, so it's not detectable by checkpoint application control. But that's OK, it's allowed in rule 105.13 we thought.

However, it seems that once the application control blade is activated, it stays active for all the rules following? We get the following error on rule 105.13 with the application rule active, and we don't get it when that rule is disabled.

2019-05-02 08_26_07-sod-as23613 - sod-as23613 - Remote Desktop Connection.png


Question 1: Can you change the settings for application control somewhere to tune this error?

Question 2: How come application control is activated first when there is a rule with application, and then staying active after that rule?

6 Replies


yeah, i saw that one. But is the only way to change settings for application control to turn it of in the kernel? Seems a bit blunt.


Unfortunately there is no way to create the equivalent of a TP exception for APCL/URLF-inspected traffic in a case such as this.  Even creating an explicit APCL/URLF rule matching this traffic will result in APCL still trying to classify it, no matter what the action is set to  in that rule.  With ordered layers what you would need to do is construct your APCL/URLF-related rulebase to ensure that the subject traffic "falls off" the end of the APCL/URLF layer and hits the implicit cleanup rule (action Accept) to avoid that inspection completely.  For inline layers, try creating a new http-noinspect service set for port 80, Protocol Signature not checked, and put it in the service of that rule.

Alternatively you could essentially "whitelist" this traffic directly in SecureXL to avoid APCL/URLF and TP for this traffic completely in R80.10, see here: sk139772: SecureXL Fast Accelerator (sim fastaccel) for Non Scalable Platforms 


"Max Capture: Know Your Packets" Video Series
now available at

Alright. Thanks for the explanation. 🙂



Hi Albin,

This is not an application control action per-se but rather a log that says that while Application Control was working on this connection (inspecting it on the HTTP level) it had an issue with the HTTP response (which was non RFC-compliant).

When you activated the APCL blade you actually made the GW inspect HTTP and therefore you got this error.


The solution should be to go to the "Non Compliant HTTP" setting under "Inspection Settings" (you can get there from the Smartconsole policy tab - under "shared policies" there's a shortcut there. Then either change the advanced setttings of this setting or move it to Allow such that it won't Drop non-compliant requests. Just make sure to edit this protection on the settings profile assigned to your gateway.




The way to do it in the GUI is per the screenshot below. Please note that the hierarchy is as follows: You can make a new profile > edit its characteristics under General > and then apply it to a Gateway OR you can add an exception to an already existing profile and then apply it to a gateway OR you can add an exception to all profiles in place. The sequence of events as far as the GUI can be a bit confusing here. Do note that in order to apply this you have to install both Threat Prevention and Access Control policies. 





0 Kudos