Custom URL Categories

Anyone having some design challenges on how to setup different custom categories and policies in Zscaler? Our proxy policies are very restrictive on different sets of servers, which also require different sets of whitelists. Zscaler only uses one category on its processing, so if one specific site is included in two or more different custom categories, chances are some requests got denied since the other custom category is not used. Anyone having the same concern and have solution, or maybe someone can enlighten me if I am doing something wrong?

@Ganeshkrishnan Do you remember what we did to get around this?

Hi Philip,
if you give certain example and elaborate the example, it will help me to share our experience. We seen similar issue in Zshift. How in ZIA, we didn’t face much challenge.

ZIA:
When you add url in custom categories, try to add under “URLs Retaining Parent Category”. This will append your custom category to that url along with other parent category [predefined]. Now the Url filtering rules are processed from top to bottom. Make sure your restricted policies are called at top with custom categories. your default “Allow all” Url filtering policy will be placed at last after “Block Malicious”. You can choose to add this Custom category in Either “Allow All” or “Block Malicious” Ulr filtering rule. if you miss to choose the custom category, then it will be allowed for everyone unless it is restricted/block in any rules at top.

Zshift:
Url which are part of multiple categories will be blocked if all the parent categories are not Allowed. Zscaler made some changes in Zshift as fix. Added to that, a Url cannot be more than 5 categories [pre-defined + Custome defined]. Zscaler planned to increase this limit in the future.

Hi @Ganeshkrishnan,
For servers, we usually have deny ALL policy at the bottom, and only allow specific websites for each set of sources. Let’s say we have two sets of Servers, ServersA and ServersB which have two separate custom category based on their whitelist, CategoryA and CategoryB, respectively. So each sets of servers are only allowed to access their corresponding whitelist category. Issue is i.e. we have www.test.com whitelisted for both, so we add this on both CategoryA and CategoryB. There are occurrences that www.test.com is denied from ServersB because Zscaler processed the site to belong only on CategoryA.

There’s also an issue where ServerA servers are permitted to all subdomains for test.com, and ServerB to only a specific subdomain, sample.test.com. Now ServersA, expected to be able to access sample.test.com as well, is now blocked because Zscaler only tags the site to CategoryB.

Does “URLs Retaining Parent Category” also append other custom categories?

Hello, we got around this issue by creating categories that would be used in both policies. For example create a “ServersA” and “ServersB” category which contains only the URLs that are specific to those groups. Then create a “Multiuse_Servers” category that contains any URLS that will be used by both groups. In your ServersA policy, you should select both “ServersA” and “Multiuse_Servers” categories. In your ServersB policy, you should select both “ServersB” and “Multiuse_Servers” categories. I agree that you should add the URLs in “Retain parent category” whenever possible to avoid conflicts between policies. With that being said, you will still have a challenge with the “longest-match” rule for things like sample.test.com. If you have test.com in one category and sample.test.com in another category, you will have issues with users getting blocked/allowed unexpectedly to sample.test.com. When you have a “longest-match” conflict, add the matching URL in the other policy. For example, you want ServersA group to be permitted to test.com, but you want ServersB group to only be permitted to sample.test.com. In ServersA category you must permit both test.com and sample.test.com to avoid the conflict of the longest-match in ServersB policy (sample.test.com). Feel free to reach out to me if you’d like to discuss over a call. Hope this helps!