Panorama On Boarding

[chens]

Hi.

For the last 10 years, i am in charge of 3 PA devices.

Device #1 (HA Pair of 1410) in the main site.

Device #2 (460) in the DR site.

Device #3 (440) in 2nd DR site.

I have recently purchased Panorama to make it easier to deploy some shared policies and objects (right now I am doing this manually on each).

I have already registered the devices, which are log forwarding to the Panorama.

I have been trying for 5 weeks without success to start the main mission which is the policy deployments.

i did the import from devices, but I have a total mess and the push is not working (a lot of errors regarding profile groups).

I also heard the I will need to clear all devices in order to let Panorama to push them the policy (which will lead to downtime),

Ideas? Help plz...

[TomYoung · Accepted solution]

Hi @chens ,

Great question!  Adding a locally managed NGFW to Panorama is tricky.  You have to do it a few times to get used to it.  Here are the steps:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CloRCAS

https://docs.paloaltonetworks.com/panorama/9-1/panorama-admin/manage-firewalls/transition-a-firewall...

However, in the long run, it will be worth it because you can change something once and push it to your NGFWs.  Here are some pointers:

1. The HA pair document has extra steps.  Be sure to go through those.  My step #s below refer to the top URL.
2. When you import the device configuration, it will create a new device group and template.
   1. Uncheck "Import devices's shared objects into Panorama's shared context (device group specific objects will be created if unique)" if you have LOTS of objects.  Otherwise you can get conflicts and commit errors.  You can move your objects to the Shared device group and resolve duplicates after the NGFWs are imported.
   2. I usually import my rules into the Post Rulebase.
   3. Do not make any changes to the device group or template until after you are finished with these steps.
   4. You can always rename the device group and/or template any time.  Don't worry about it for now.
3. Step 5 is very important!  (Step 4 on the HA doc.). Do not do the 1st push from the Commit menu.  Push & Commit from the Panorama > Setup > Operations > Export or push device config bundle menu.  This step deletes the local policies and objects so that you will not have duplicate object commit errors.  After this step, push normally.
4. Finally, the top URL document above is not complete!  (The HA one has this step.). If you want to managed the Network and Device configuration from Panorama, select Force Template Values in step 6.
   1. This will override IP addresses, etc. So, make sure you have automated commit recovery enabled so that if the NGFW cannot communicate with Panorama it revert the configuration.  This is critical if the NGFW is at a remote location.
   2. Like step 5, this only needs to be done once.

Try it out!

Thanks,

Tom

[JeriShubert]

Thanks for the link, I appreciate you. It is helpful for me.

[chens]

Ok thanks.

Done.

Now i have the managed policy in yellow\orange.

What if the Panorama is not available (since it's on central location), and i need to make urgent policy change or rule disable in the running managed firewall? i saw i can add local rules to policy, but i have no options beside read only on the yellow\orange rules

[TomYoung]

Hi @chens ,

Correct.   You cannot edit or override device group configurations (Policies or Objects) on the local NGFW.  It is important to know the hierarchy of the rules on the NGFW.  https://docs.paloaltonetworks.com/panorama/9-1/panorama-admin/panorama-overview/centralized-firewall...

So, any rules that may block critical traffic should be place in the Panorama post-rules section.  Then, any locally created rules will take precedence.

If my original answer solved your problem, please mark it as the solution!

Thanks,

Tom

[chens]

Thanks for the answer.

Still, something doesn't make sense for me.

Our risk management must have a solution in case of Panorama lost.

What if we have a deny rule from the shared DG rules. And we need to bypass it somehow, locally.

To add post rule (local) will not help here.

[TomYoung]

Hi @chens ,

I did not say local post-rule.  Any deny rules that may need to be bypassed should be in the Panorama post-rules section.  If you look at the URL I posted you will see that local rules come before Panorama post-rules.  You will be able to add a local rule that is matched before the deny rule.

Thanks,

Tom

[chens]

This mean i have to re-design all my policy, because i have deny rules per zones. For example deny outbound ldap before allow any. 

Sound like very hard mission, this Panorama deployment 

[TomYoung]

Hi @chens ,

You do not need to redesign all of your policy.  Are your security policy rules in the Panorama pre-rules or post-rules section?

Thanks,

Tom

[chens]

Just import them to as your first answer recommendation . I have import all to pre-rules.

[TomYoung]

Hi @chens ,

Simply use the Move button on the bottom of the page to move your rules to post-rules one rule at a time. You can start at the bottom and then move each rule to the top of the post-rules section.  Once you are done, the order on the NGFW will be the same.

In my first answer I recommended moving all the rules to post-rules, but i understand that pre-rules is the default.  I usually use pre-rules only for Shared rules which I push out to all NGFWs.

Thanks,

Tom

[chens]

Ok cool.

So once all of them will be in post-rules, i will actually have the option to add local rules that will take place before them?

[TomYoung · Accepted solution]

Exactly!

[chens]

Hi @TomYoung 

After playing arround, i feel ready to onboard HA pair.

I am working with this:

https://docs.paloaltonetworks.com/panorama/9-1/panorama-admin/manage-firewalls/transition-a-firewall...

But something is bothering me:

Step 5 (of HA) tells me to consolidate both peers to the same device group (which makes sense) and alto to same template stack.

SubStep F tells me to add the 2nd peer to the 1st peer stack, but what about 2nd peer template?

Not using the 2nd template will override all device configs including the management interface, and HA as well.

On the other hand,  SubStep G  tells me to remote the HA template. Since the config import created only one template for each peer, removing the HA config from the 1st (merged) template will override and destroy the HA in both peers.

Sounds scary a little bit 

[TomYoung]

Hi @chens ,

Good questions.  Yes, add both NGFWs to the same template stack.  The NGFW is smart enough NOT to used the Panorama-pushed configuration for the management interface, even when you Force Template Values.  I have done it many times, and never lost connectivity.

With regard to HA, you have 2 options:

1. Delete the HA config in Panorama, which means the HA will remain locally configured.  Panorama does not remove Network or Device configuration if it doesn't have it.  It stays on the NGFW.
2. Use template variables for the HA IP addresses.  This is a little more complicated, but you get to manage the configuration from Panorama.  If you get it wrong, HA won't work.  Generally you do not lose connectivity to Panorama.  If the HA pair is in production at a remote site from Panorama, you may want to be on site.  If HA fails, both NGFWs may become active, and you may have connectivity issues.

https://www.youtube.com/watch?v=MxAy_7X5g3E

Thanks,

Tom