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

Layers and the cleanup rule

An important aspect in R80.10 security management and gateways is the clean-up rule at the end of every layer.

Ordered and Inline layers in R80.10 always end with a clean-up rule. This makes sure that there is always a match.

So even if a user tries to remove the last rule:

He will get this message that basically says there's an implicit cleanup rule on the gateway.

(you can actually follow-up on the best practice to keep an explicit cleanup rule by using the Compliance blade)

So what's new?

In our previous versions, the clean-up rule was a constant value:

  • Any, any, drop at the end of the Firewall layer
  • Any, any, accept at the end of the Applications layer

(either as an implicit rule or explicitly visible in SmartDashboard/SmartConsole)

With R80.10:

  • You get better visualization of that behavior (as seen in the screenshot above)
  • You can configure the action: accept or drop.

You can control the action of that implicit cleanup rule by editing the layer. This will only matter if there's no explicitly defined cleanup rule at the end of the layer.

Let's see how this can look like in different usages of layers:

Inline Layers:

The fact that there is always a match in the inline layer, eliminates any impact of the inline layer's rules outside the inline layer.

In this example, rule 5 has an inline layer.

  • When changing the inline layer's rules, we can't change the enforcement for rules 1-4, because they will always be matched before rules 5-12.
  • When changing the inline layer's rules, we can't change the enforcement for rules 6-11, because matching on rule 5 always ends with matching any of the rules 5.1-5.7. There will always be a match, because the cleanup is always present.

Ordered Layers:

Some ordered layers can work in whitelist mode, while others can work in blacklist mode. For example, you can work with an ordered layer of "blocked unaccepted traffic" which accepts only on the last rule.

Or you can work with an ordered layer of "accepted specific web applications" which blocks the rest of the web applications.

Either way, it is OK to put an "any, any, accept" rule as the clean-up rule for an ordered layer while still ensuring unexpected traffic will be dropped, by providing an additional ordered layer with an "any, any" drop" rule.

Read more about using layers here: Layers in R80 

Note: Multi-domain layers work differently here.

A local policy can have global rules and a "Domain layer" between them. When the gateway evaluates the rules in the local policy, if there was no match for the global rules at the top of the rulebase, it starts to evaluate the rules from the domain layer. If there was still no match for those rules, the global rules that were created below the domain layer are evaluated. So there is no cleanup rule before or after the domain layer.

Read more about Domain Layers here: 

3 Replies

I really do appreciate the cue from SmartConsole on the implicit rule (both the fact it automatically creates one and tells you what happens if you delete/misconfigure it).

One other visual cue that would be nice to add is when you use ordered layers is something that tells you that "Accept" really means "move to next layer." 

So, for example, where you are managing a pre-R80 gateway, the Access layer rule has actions that say "Accept (Move to Application Layer)" or something similar.


In the thread High CPU after upgrade from 77.30 to 80.10 Timothy Hall was explaining that configuring an explicit clean-up rule 'Allow All' application control layer causes all traffic to pass through PXL.

I believe this should no longer be an issue with Layers as taking the above example, rule 5 has destination 'Internet'. But what above the clean-up rule at the end (bottom) of the policy, will this have the same impact as before?

0 Kudos

I assume you are looking at the last screenshot above.  Parent rule 5 can only catch traffic from the internal network to the Internet (this assumes the firewall's topology is completely and correctly defined and object "Internet" is being calculated correctly) and that is typically where we want APCL/URLF processing in PXL as a result. 

If there is an explicit cleanup rule at the end of this policy with a destination of "Any" and an action of Accept, it could cause internal-to-internal traffic to get sucked into PXL at LAN speeds depending on how the Source is defined.  A destination of "Any" in an ordered APCL/URLF layer rule should definitely ring alarm bells for optimization.  In an inline layer capable of APCL/URLF use of "Any" in a destination could also be cause for concern, but not in sub-rule 5.7 above because the firewall can't reach that rule unless the destination has already matched "Internet" (not Any) on parent rule 5.

Hopefully I'm understanding your question correctly.

Second Edition of my "Max Power" Firewall Book
Now Available at

Gaia 3.10 Immersion Self-paced Video Series
now available at