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

Moving to Unified Policy

Our customer has a policy that has seperate policies for firewall rules and Application control.

 

Of course it's better if they move to a Unified Policy for all obvious reasons. But our customer does not want this move as a "big bang", but rather see the Application Control rules be moved into the Unified policy over a period of time (controlled move).

 

I'm worried however that running Application Control from the Unified rulebase followed by having traffic handled by a seperate Application Control layer might be too much for the firewall (see the Policies2 image). Has anyone tried this?

 

 

0 Kudos
7 Replies
PhoneBoy
Admin
Admin

With the column-based rule matching in R8x, this is not really a concern.
What is a concern with this "phased" approach is the possible complexity of the policy.

the_rock
Legend
Legend

I can tell you, in my opinion, and this actually always proves to be the best method, you can have 2 ordered layers, network layer with firewall blade ONLY and then application layer with urlf/appc blades enabled. Then, on appc/urlf ordered layer, block whatever has to be blocked and make sure last rule is any any allow. Obviously, last rule on network layer should be any any block (impicit clean up rule), but then you can create many inline layers and by default, those will have expicit clean up rules at the bottom.

Idea is that with ordered layers, traffic has to be accepted on every ordered layer. Im happy to show you this in my lab, where I have many ordered layers, plus https inspection enabled.

Hope that helps.

Andy

the_rock
Legend
Legend

By the way, I would disagree with your comment that its better if they moved to unified policy. I always found traffic gets processed faster when you have separate layers with corresponding blades enabled inside of them.

0 Kudos
pietervs
Participant

Hi the_rock, Phoneboy,

 

I've had several discussions with TAC regarding the policies, and each time I was told that traffic was going through your policies twice: once for the firewall rules and once for Application/URL Filtering. This would cause unnecessary strain on the appliance, particularly if that appliance is already being pushed to it's limits. Besides, having an "all in one" policy would make things easier to oversee. 

 

A simple example: you want a computer to be able to reach only website X and it's subdomains. You create a rule in the firewall policy stating computer => internet, services http/https allow, and then in the Application Control layer you specifiy the website(s)  in an custom application and add a block rule underneath. Using a Unified policy there's no need for the seperate firewall rule.

 

That's why I've been looking at a Unified Policy. Should we go in another direction then?

0 Kudos
the_rock
Legend
Legend

I get that point, but in my view, layered policy is better and less resource consuming. But as @PhoneBoy  said, in R80+ is not a huge concern. Personally though, I always go with ordered layers, find its the best approach.

0 Kudos
Alex-
Advisor
Advisor

I prefer inline layers to orders layers in terms of readability for the example you describe, like Any to Internet then more specific rules only for Internet access and classical rules for the rest, in a nutshell.

Ordered layers work of course but have the disadvantage of logging everything twice since for instance a simple ping allowed in the Network policy must then also allowed in the next layer and both will produce a log. So your manager will get more log files for the same traffic.

0 Kudos
pietervs
Participant

Hi Alex-

indeed, logging is another concern. Our customer likes to have everything logged so there's full logging on both the firewall layer as well as the Application Layer (in spite of the fact that best practices dictate otherwise).

 

But going from the_rocks and Phoneboys comments, I think we'll keep things the way they are for now.

 

Everyone thanks for your input.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events