Panorama Frustrations with Global Protect

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.

Panorama Frustrations with Global Protect

L3 Networker

I am hoping someone here may be able to help me with this.  I have had this discussion with numerous PAN SEs and customers and lots of people over time but have never really been given a solution to the problem.  I continue to run into the problem in various customers and I am hoping there is some solution.  I am going to describe the current situation I am working on in hopes someone can provide some better guidance on how to achieve my goal.


I have a customer that purchased PAN NGFWs to support a Global VPN deployment for their organization.  They have nine locations they wanted to enable for GP connectivity.  Eight of these locations have identical physical connectivity, one of them - their main HQ - is using aggregate ethernet interfaces on the inside and outside for redundancy.  They also have varying authentication/connectivity requirements depending on certain factors.


Currently, the eight non-HQ locations are configured each with a Portal and a Gateway which allows users to connect directly to the location of their choice or be rerouted to to another one based upon latency, etc.  This configuration requires machine certificates for authentication as well as user/password.  The HQ location has two portals and two gateways.  The reason they have this second set is because they wanted a way to allow for authentication in the event a machine doesn't have a cert so it can be provisioned or so outside contractors can connect without one.  They are requiring RSA tokens for this access.


To configure all of this in Panorama, we created two different template stacks that are independent of one another.  Since the physical connectivity of the HQ firewall compared to the others is different, I didn't see any way to accomplish this using only one as the GP configs all reference physical interface names.  Right now when changes are made we have to make them to both templates, and push them out separately to the two different groups of firewalls.


Due to COVID-19, the customer is hoping to enable this secondary authentication mechanism for other geographic locations.  But only two of them.


I can't figure out how to properly do this with Panorama.  If I use the existing template to build this configuration, it would apply to other six firewalls as well which is not intended.  If we could target templates like we can with policy rules I could see using this as a workaround.  But, alas, this is not possible.  The most ideal option would be to allow templates to reference elements from other templates within a stack.  This is also not possible unfortunately due to Panorama's architecture.


The other option I see would be to build another template template/template stack specifically for the two firewalls they wanted to enable the second Portal/Gateway on.  The problem here is that these items need to reference the same physical interfaces that are already defined in the other template.  I've had all sorts of issues when pushing templates with duplicate values in the past, and am extremely hesitant to do so.


So what can be done here?  Is the only real solution to forgo Panorama at this point and just configure this stuff locally on the firewalls?


Constantly I run into issues like this when using Panorama for GP configuration across multiple firewalls if they have any small differences in either physical connectivity or user connectivity requirements.


Does anyone have a solution to make Panorama less painful?  I would be forever grateful.

  • 0 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!