Custom Region

[jdprovine]

Has anyone created a custon region and later found out that there was alrady a built in region for that country? How did you deal with it?

[BPry]

@jdprovine,

That sounds exactly like what they should have recommended.  In this case 'commit force' is actually needed after resetting the idmgr like this. Once you've followed those steps you'll see the idmgr return to normal and 'US' will leave your listed regions. 

[BPry]

@reaper,

I actually retraced this on a PA-220 in a remote office as well to make sure that I wasn't forgetting anything. It was a nice exercise with this again. 

If you actually rename everything to BE-Custom for example and commit it'll commit fine as long as you remove all references to BE. Once the commit has finished you can then go back to put in the default BE group and everything continues to function as it should. However, the ID-Manager will maintain the BE listing until you fully restart the device or reset the id-manager. 

[reaper]

@BPry

i skipped that step as @jdprovine mentioned explicitly using the 'original' name without having first added a new custom object, (so my objects only contained the BE-custom, but my security policy had a 'BE' in it. because ID manager still has the original entry, the GUI allows you to add the original object) which leads to the failed commit

[jdprovine]

@reaper @BPry

Even worse than making the autocommit fail during upgrade, neither US or US-Custom work in the security rule, it blocked traffic, I had to remove those region and replace it with any

[jdprovine]

@reaper @BPry

And again all I did up update the existing custom region name from US to US-Custom, commited them and then started putting US back on my rules and it broke my rule had to change to any instead of US or US-Custom

[jdprovine]

@reaper

how are you verifying which one is the built in region

[reaper]

@jdprovine

the 2 letter, all capitals, object is always the built in

if you create a custom object and name it exactly the same as the built in, the system will use the built in

you can see all the built in regions at system level through this command:

> debug device-server dump idmgr type shared-region all 

these are the 'shared' (system level, shared between all vsys) objects

any custom regions you create will be in vsys1 or others if you have multiple, but will basically point (shortcut) to the system ones if you name it the same

[reaper]

I'd reach out to support and have them investigate this (feel free to refer them to me 😉 )

imho you should not be able to re-use your built in region in it's original formn after you renamed the object and have not yet created a replacement object for the original

either this is an operation not anticipated, or a behavior we could document and discourage somehow

[jdprovine]

@reaper

I opened a case on 1/26/2018 CASE 00823180, about the autocommit failure and it lead to an issue of the custom region.  I have been through two or three maybe more engineers trying to find out what is causing the issue and come up with a permanent fix. I have had some good, alot of bad help. Communication is a really really big problem

[jdprovine]

@reaper

So Tom when the custom region US was created did it merge somehow with the existing built in region or become a pointer? Because the custom US region that was created has no properties or criteria in it at all, and it shows up in objects/region on the firewall. Then the choice of US (united states) disappeared from the region selections in the security policy. Then when I added Custom to the name, making it US-Custom) both the US-Custom and US (united states) became available in the drop down in the security policy and you saw the out put from my ID managers dump show the ID 1025 for US and 1026 for US-Custom.

I did some testing last night and the US(united states) worked but the US-Custom did not.  I think that covers it now to get a permanent solution that does not allow people to create a custom region with the exact same name as the built in region (turned that into my SE) and clean up my custom regions that were created by someone by accident.

Here is a pic of the custom region "setting"

[jdprovine]

@BPry

You mean remove all the BE region setting from all your security rule

[jdprovine]

@reaper@BPry

Okay I went through all the rules with US-Custom and changed them to US (united states) and it looks like it is all working again. 

[BPry]

@jdprovine,

I could be wrong; but even when you create a custom region and call is "US", you don't somehow magically get rid of the default "US" region. It's simply in an unexpected part of the configuration, which leads to issues since parsing gets effected pretty heavily when you include entries that aren't expected. 

Once you rename the "US" entry you created to "US-Custom" it essentially corrects the parsing issue, but you confuse the daylight out of id-manager, which is why you have to reset it to get things functional again.

The "US-Custom" region doesn't work because it no longer has any matching criteria associated with it. If you attempt to use the US-Custom region at that time it won't work because it doesn't actually mean anything anymore; traffic will never match the security policy where US-Custom is used. 

[jdprovine]

@BPry

That is the 65.000 dollar question for sure - what really happens to the built in region US when you create a custom region with the identical same name. But now that I have renamed the custom region name from US to US-Custom, in the drop down listing the regions in a security rule suddenly US (united states) is listed about US-Custom.

[jdprovine]

@BPry @reaper

this looks like an old link but it might explain what happens

https://live.paloaltonetworks.com/t5/Management-Articles/Region-Object-Not-Working-in-Security-Polic...