In-Line rules, can they 'do nothing' as the last rule

[George_Ellis]

I am confident that the answer is no for in-line rules.  You can drop or allow, but not 'do nothing, pass to the next rule'.  Of course, the standard answer is it will be in the next version...

The reason I ask is that we have a global rule that wants to use a complex service, ALL_DCE_RPC.  SecureXL stops at that rule.
With In-Line rules, you could 'hide' ALL_DCE_RPC away from the normal acceleration line.  But rules cover a large group of IPs, so will match some parameter.  But as the inline runs its course, I would want to use it as a filter and continue with the rest of the rules. 

Like I said, this I do something that is not covered in the process,  But if you know a way, please share.

[Timothy_Hall · Accepted solution]

I think what you are asking is that if a top/parent rule is matched (say rule 3), and we descend into the sub-rules (3.x) and then if no explicit sub-rules match is there a way to "do nothing" and continue rulebase evaluation at top/parent rule 4?

If I understand you correctly the answer is no.  There is an implied cleanup rule at the end of the sub-layer that will either drop or accept according to the layer property and it is over at that point as a decision has been rendered, there is no way to continue with next parent/top rule right under the sub-layer.

[George_Ellis]

That is the way I know it would work.  I was just having a hope on hope that there was a trick to bend it to my will.  Fixed in R90 probably... 😉

[the_rock]

R100 would be more appropriate mate ; - )

[the_rock · Accepted solution]

Im pretty confident answer is no and Im more than confident that it will NOT be in the next version either : - ). As you said, the best you can do is set it to allow or drop. Sadly, you cant change it in below field either...

 

[PhoneBoy]

There is a DCE-RCE-Protocol "Application" in Application Control that should be SecureXL friendly.
Of course, that assumes you're using Application Control on the relevant gateways...

[George_Ellis]

Maybe it is time to reevaluate AC 🙂

[Timothy_Hall]

Yes and no.  While the use of that DCE/RPC application-based object will prevent SecureXL templating from being stopped (reported by fwaccel stat) as opposed to using a simple DCE/RPC service, doing so requires APCL/URLF to be enabled in that first layer along with the Firewall blade.  Once you do that fwaccel stat will report templating "enabled" with no rule stopping it, but the actual live templating rate will always be zero as shown by fwaccel stats -s. 

This is a consequence of using application objects in your first layer along with the Firewall blade and why it is recommended to not invoke APCL/URLF/Content Awareness in the first layer of an ordered implementation, Firewall should be all by itself in that first layer.  For inline layers the top/parent layer should only use simple services, while APCL/URLF/Content Awareness objects are only invoked in sub-layers.

Admittedly I haven't checked this behavior since R80.40 and it may have changed in the latest releases (but I doubt it), will check today.