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?

[jdprovine]

@reaper

I thought they should be able to live side by side too but the I put US and US-Custom it broke the rule and stopped traffic

[jdprovine]

@reaper @BPry

I have changed all my affected security rules regions from US-Custom to US (united states). Can I deleted US-Custom? Can I verify that the US (united states) is the built in region and if so how is that done? What is my next step? I haven't run the debug device-server reset id-manager type vsys-region,  because TAC told me to do it during a maintenance window. Do I have do it on both firewalls or only the active?

[reaper]

@jdprovine

They should, but possibly if you run into the situation with the 'ghost' region there could be an issue until you reset the id-manager

I've just set up a test where i block the built in 'US' and a custom 'tom-land' (where i put 1 ip belonging to my server located in the US)

all connections to random US based sites are blocked with region 'US', all connections to my server are blocked as region 'tom-land'

according to the article when you create a custom region that is named identical to the built-in, you override the built in, so if you leave that object empty, nothing happens. if you then rename, the ghost still exists so the built-in is still overridden until you reset the idmanager

I've experimented a little on PAN-OS 8.0 and while i do see the ghost i can't seem to 'break' my firewall

To reset your situation you could delete all the custom regions, remove regions from your policies, reset the id-manager, commit. then you should be on a clean slate

repeat this on firewall 2

Then add the regions directly into security policy, add custom regiuons where needed (name them something more 'custom') and add these too, commit (this part should automatically sync over to firewall 2)

then you should be good

I would recommend doing this in a maintenance window, but if you use the below reset command, there should not be an impact on anything else but the regions:

> debug device-server reset id-manager type vsys-region 

[jdprovine]

@reaper

This is where I am at in the process - all of this has only been done on the active firewall

1. Update the custom region US to US-Custom (commit)
2.Security policies changed to US-Custom and US (united states )are now options that show up in the list drop down list in the security rules
3. Changed the security policies from US-Custom to US (commit)

Do you have to have some kind of settings in your custom region? This is how it was created (not by me 😉 ) and this is the one that breaks the rules

[jdprovine]

@reaper

So does this set them back to the default regions? 

> debug device-server reset id-manager type vsys-region

I would assume this only occurs after the custom regions have been deleted? 

[reaper]

an empty custom region is not going to be able to match anything, so if you have it set for a blocking policy, you will not block, if you have it set for an allow rule, you will not allow (my custom object has an IP in there)

also, don't forget to reset the id manager, else you will bump into the 'ghost' object

resetting the idmanager clears out the remnants after you rename/delete your custom regions, this will ensure you're back to the built-in

[jdprovine]

@reaper

I didn't have it on a deny policy  but I did have it on an allow policy, but your comment "an empty custom region is not going to be able to match anything" tells me it will act as a block on some rules.

So I have to delete the custom regions, di the rest of the idmanager and commit force - 1st on the active and then the passive.

But what is really confusing me is this - I can not reconcile all these objects

Under the security policy - 

In the objects/region

In the CLI

debug device-server dump idmgr type vsys-region all

ID Name
---------- --------------------
1024 vsys1+BR
1025 vsys1+US  (is this the over written built in with all the properties? It doesn't show up in objects/regions) 
1026 vsys1+US-Custom (did renaming it disassociate it with the built in and why? now it has no properties)

Type: 36 Last id: 1027 Mismatch cnt: 0

[jdprovine]

@reaper

I don't mean to spam you but TAC can't seem to answer these questions

So are you saying my current US (united states) needs to be removed from all my security rules before I do the idmanager reset?

Or do I have to remove all of my regions from all my security rules before I do the idmanager reset?

I can't delete anything but the US-Custom but it looks like the US and US-Custom show up in the idmanager dump and does that mean they are both custom regions?

[reaper]

Hi @jdprovine

The security policy will allow you to add all the pre-built countries without needing a custom object, so if you simply want to block/allow certain countries, you can do that directly from the security policy, no need to build objects

your currently only have 1 custom object, so the vsys1-BR and vsys1-US objects are 'ghost' remnants of objects you once created and have since removed/renamed to US-custom. these 2 should not be there and  need to be cleared out with 

debug device-server reset id-manager type vsys-region 

1. make sure there are no custom regions left that are identical to a built-in country
2. reset the id manager
3. commit force
4. reset id manager on firewall 2
5. commit force on firewall 2
6. verify on both members that only ID 1024 vsys1-US-custom exists
7. good to go

please feel free to keep spamming me, that's what I'm here for 🙂

regions have proven to be a little more challenging than I expected so I understand 😉

[jdprovine]

@reaper

Your the best and TAC is currently ignoring my ticket so I am getting very frustrated. Let me say what i think my steps are 

1. I have set all of my security rules from US-Custom to US (united states -added through the drop down list in the security policy) on the primary firewall and it synched to the

      secondary

2. I am going to go an delete the custom region US-Custom (commit) let it synch to the secondary)

3.  run "debug deviice-server reset id-manager type vsys-region" on the primary firewall during a maintenance window

4.  configure/commit force on the primary firewall

5.  run "debug deviice-server reset id-manager type vsys-region" on the secondary firewall during a maintenance window

6.  run "debug device-server dump idmgr type vsys-region all"

7. Shouldn't all the custom regions be gone after a reset and i should see nothing? Aren't these refering to custom regions?

ID Name
---------- --------------------
1024 vsys1+BR
1025 vsys1+US
1026 vsys1+US-Custom

Type: 36 Last id: 1027 Mismatch cnt: 0

[reaper]

if you also delete US-Custom, all regions will be gone after executing the reset command

add step 5.5: config + commit force on secondary

step 6 should show nomore entries on either firewall

[jdprovine]

@reaper

But i want all the custom region gone don't I, so the ones that were over written will be fixed by the reset, reset being back to the built inregions.  So what will happen to the security rules that I have region settings (especially US and BR), the ones I chose from the dropdown US (united states) and BR?

Are these all custom regions?

1024 vsys1+BR - 
1025 vsys1+US ( is this the custom combined with the built in)
1026 vsys1+US-Custom

[jdprovine]

@reaper

Was it a mistake to rename my US custom region to US-Custom and then commit?

[reaper]

@jdprovine

don't worry, follow the steps we outlined above and you will be alright (you can leave the US and BR ones in the security policy)

[jdprovine]

@reaper

Ah ha I found a way to tell which one is the built in from the custom one

Just curious what the risk of doing the reset outside of a maintenance window