Using "Any" as zone for a converted policy

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Using "Any" as zone for a converted policy

Hi

I'm converting a security policy from a Check Point device to a PAN device using the PAN converter. By default the converter sets source and destination zones as "Any". Can I use the rule like that? Is there any problem that such configuration might cause in the future or after replacing the devices? Do I need to specify zones in the rules? Please send me your comments. Thanks.

1 accepted solution

Accepted Solutions

L6 Presenter

The zones can be compared to "vlans". Instead of just specify the interface you specify the zone (a single interface can have one or multiple zones or if you want to call them vlans).

The point of specify to/from zone is to limit which traffic is allowed (or for that matter denied).

For example if you wish all hosts to query your dns-servers then you can select source-zone: any. But lets say you wish to limit so only clients from the client-zone should be able to do this then you set the source-zone to "clients" (or whatever you might call that zone).

Or the other way around, if you want any hosts except those from client-zone you can first have a deny for traffic from client-zone to dns-zone (and appid: dns) followed by a rule that allows any zone to the dns-zone (and appid: dns).

Using any as zone is good in the moment of first test but I would recommend you to tighten up the rules so only the traffic that should be allowed really is allowed.

View solution in original post

2 REPLIES 2

L6 Presenter

The zones can be compared to "vlans". Instead of just specify the interface you specify the zone (a single interface can have one or multiple zones or if you want to call them vlans).

The point of specify to/from zone is to limit which traffic is allowed (or for that matter denied).

For example if you wish all hosts to query your dns-servers then you can select source-zone: any. But lets say you wish to limit so only clients from the client-zone should be able to do this then you set the source-zone to "clients" (or whatever you might call that zone).

Or the other way around, if you want any hosts except those from client-zone you can first have a deny for traffic from client-zone to dns-zone (and appid: dns) followed by a rule that allows any zone to the dns-zone (and appid: dns).

Using any as zone is good in the moment of first test but I would recommend you to tighten up the rules so only the traffic that should be allowed really is allowed.

While automated converters do the bulk of job, such migration projects would need some additional "human" touch. It will be good to perform one round of manual analysis and use specific zones as source & destination rather than any. Other learning from such migration projects is that sometimes the source or destination is spread across all the zones hence we might be tempted to leave it as "any". It may be a good practice to select all zones by name rather than "any". Because subsequently in future, when we add new zones, we may have to spend more time in analyzing the impact on old rules with "any" zone. This little time spent will help in future troubleshooting of existing rules based on zone names.

  • 1 accepted solution
  • 2285 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!