SRX

Hi all. 

I got into a discussion with some colleagues here today. I would like to get your feedback on this. 

In Juniper SRX there are two different kinds of policies: 

zone specific policies: 

Here you need to use ONE source zone and ONE destination zone with "from-zone X to-zone Y" statement. 

global policies:

Here it is possible to use "Any" or multiple zones as both source zone and destination zone.

The thing is that it is possible to define a global policy with ONE source zone and ONE destination zone in the same way as in a zone specific policy. 

Your question is then: If we don't use any zone specific policies, but define ONE-to-ONE zone policies as global policies... will this affect performance? 

I see that it will be harder to keep track of policies since we then are unable to do a lookup of policies with "show security policies from-zone X to-zone Y". But if we put this aside... are there any other thoughts on why not to do this?

Until somewhat recently, you were a bit limited on what you could do with global policies as far as unified policies (using AppID) were concerned. With newer versions of JunOS, these limitations have fallen off. There may be other things that are not supported in global policies, but nothing comes to mind right now.

If global policies support everything that zone-based policies can do, then I suppose it becomes just a matter of secondary objectives (e.g. perhaps you want to keep separate hit counts for some reason?) and preference. I don't have benchmarks, but I doubt zone-based vs. global policy processing would have appreciable performance difference.

Hi all. 

I got into a discussion with some colleagues here today. I would like to get your feedback on this. 

In Juniper SRX there are two different kinds of policies: 

zone specific policies: 

Here you need to use ONE source zone and ONE destination zone with "from-zone X to-zone Y" statement. 

global policies:

Here it is possible to use "Any" or multiple zones as both source zone and destination zone.

The thing is that it is possible to define a global policy with ONE source zone and ONE destination zone in the same way as in a zone specific policy. 

Your question is then: If we don't use any zone specific policies, but define ONE-to-ONE zone policies as global policies... will this affect performance? 

I see that it will be harder to keep track of policies since we then are unable to do a lookup of policies with "show security policies from-zone X to-zone Y". But if we put this aside... are there any other thoughts on why not to do this?

Thanks a lot Nikolay. Very useful input. 

Anyone else know of any differences in feature for global vs sone policies? 

Until somewhat recently, you were a bit limited on what you could do with global policies as far as unified policies (using AppID) were concerned. With newer versions of JunOS, these limitations have fallen off. There may be other things that are not supported in global policies, but nothing comes to mind right now.

If global policies support everything that zone-based policies can do, then I suppose it becomes just a matter of secondary objectives (e.g. perhaps you want to keep separate hit counts for some reason?) and preference. I don't have benchmarks, but I doubt zone-based vs. global policy processing would have appreciable performance difference.

Hi all. 

I got into a discussion with some colleagues here today. I would like to get your feedback on this. 

In Juniper SRX there are two different kinds of policies: 

zone specific policies: 

Here you need to use ONE source zone and ONE destination zone with "from-zone X to-zone Y" statement. 

global policies:

Here it is possible to use "Any" or multiple zones as both source zone and destination zone.

The thing is that it is possible to define a global policy with ONE source zone and ONE destination zone in the same way as in a zone specific policy. 

Your question is then: If we don't use any zone specific policies, but define ONE-to-ONE zone policies as global policies... will this affect performance? 

I see that it will be harder to keep track of policies since we then are unable to do a lookup of policies with "show security policies from-zone X to-zone Y". But if we put this aside... are there any other thoughts on why not to do this?

The biggest issue I've seen is when you try to use both some zone and some global policy.  the final policy in any zone to zone interaction is default deny silently.

So if the traffic is seen as zone to zone and there is no policy for the match it will be dropped even if there is a global allow in place that would match the traffic.

Thanks a lot Nikolay. Very useful input. 

Anyone else know of any differences in feature for global vs sone policies? 

------------------------------
Best regards
Vidar Stokke

Original Message:
Sent: 04-15-2024 14:07
From: Nikolay Semov
Subject: SRX - global or zone specific policy?

Until somewhat recently, you were a bit limited on what you could do with global policies as far as unified policies (using AppID) were concerned. With newer versions of JunOS, these limitations have fallen off. There may be other things that are not supported in global policies, but nothing comes to mind right now.

If global policies support everything that zone-based policies can do, then I suppose it becomes just a matter of secondary objectives (e.g. perhaps you want to keep separate hit counts for some reason?) and preference. I don't have benchmarks, but I doubt zone-based vs. global policy processing would have appreciable performance difference.

Hi all. 

I got into a discussion with some colleagues here today. I would like to get your feedback on this. 

In Juniper SRX there are two different kinds of policies: 

zone specific policies: 

Here you need to use ONE source zone and ONE destination zone with "from-zone X to-zone Y" statement. 

global policies:

Here it is possible to use "Any" or multiple zones as both source zone and destination zone.

The thing is that it is possible to define a global policy with ONE source zone and ONE destination zone in the same way as in a zone specific policy. 

Your question is then: If we don't use any zone specific policies, but define ONE-to-ONE zone policies as global policies... will this affect performance? 

I see that it will be harder to keep track of policies since we then are unable to do a lookup of policies with "show security policies from-zone X to-zone Y". But if we put this aside... are there any other thoughts on why not to do this?

------------------------------
Best regards
Vidar Stokke
------------------------------

> The biggest issue I've seen is when you try to use both some zone and some global policy.  the final policy in any zone to zone interaction is default deny silently.

> So if the traffic is seen as zone to zone and there is no policy for the match it will be dropped even if there is a global allow in place that would match the traffic.

Are you sure about this?

I know it used to be a hidden "deny" at the end of zone specific policies, but I don't think that is correct anymore.

According to this site it should work "as expected" now as long as you don't create your own "catch all" in the zone specific rules:

https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/security-global-policies.html

NOTE: 

If you have a global policy, make sure you have not defined a "catch-all" rule such as, match source any, match destination any, or match application any in the intra-zone or inter-zone policies because the global policies will not be checked. If you do not have a global policy, then it is recommended that you include a "deny all" action in your intra-zone or inter-zone policies. If you do have a global policy, then you should include a "deny all" action in the global policy.

------------------------------
Ola Thoresen

Original Message:
Sent: 04-15-2024 19:38
From: spuluka
Subject: SRX - global or zone specific policy?

The biggest issue I've seen is when you try to use both some zone and some global policy.  the final policy in any zone to zone interaction is default deny silently.

So if the traffic is seen as zone to zone and there is no policy for the match it will be dropped even if there is a global allow in place that would match the traffic.

Thanks a lot Nikolay. Very useful input. 

Anyone else know of any differences in feature for global vs sone policies? 

------------------------------
Best regards
Vidar Stokke

Original Message:
Sent: 04-15-2024 14:07
From: Nikolay Semov
Subject: SRX - global or zone specific policy?

Until somewhat recently, you were a bit limited on what you could do with global policies as far as unified policies (using AppID) were concerned. With newer versions of JunOS, these limitations have fallen off. There may be other things that are not supported in global policies, but nothing comes to mind right now.

If global policies support everything that zone-based policies can do, then I suppose it becomes just a matter of secondary objectives (e.g. perhaps you want to keep separate hit counts for some reason?) and preference. I don't have benchmarks, but I doubt zone-based vs. global policy processing would have appreciable performance difference.

Hi all. 

I got into a discussion with some colleagues here today. I would like to get your feedback on this. 

In Juniper SRX there are two different kinds of policies: 

zone specific policies: 

Here you need to use ONE source zone and ONE destination zone with "from-zone X to-zone Y" statement. 

global policies:

Here it is possible to use "Any" or multiple zones as both source zone and destination zone.

The thing is that it is possible to define a global policy with ONE source zone and ONE destination zone in the same way as in a zone specific policy. 

Your question is then: If we don't use any zone specific policies, but define ONE-to-ONE zone policies as global policies... will this affect performance? 

I see that it will be harder to keep track of policies since we then are unable to do a lookup of policies with "show security policies from-zone X to-zone Y". But if we put this aside... are there any other thoughts on why not to do this?

------------------------------
Best regards
Vidar Stokke
------------------------------