- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
11-27-2023 04:56 AM
Hi All,
current setup more or less..
|---PAN FW1---|
internet -->--- Ext LB---- ---Int LB--------Azure Env
|---PAN FW2---|
PAN FW1 and PAN FW2 are standalone FWs sitting between an ext and internal Load balancer and managed by panorama under the same template / device group stack so a policy pushed will push to both.. they are standalone and does not share session tables etc.
Looking at doing global protect and just need to clarify the best way to achieve this..
has anyone done this before?
i am thinking of allocating one public IP on the Ext LB, that will loadbalance to the FW1 and FW2 (sticky sessions) and this should work?
any thoughts?
thanks in advance.
11-27-2023 05:22 AM
I would
- either loadbalance the portal or have portal on each firewall node (with distinct public IPs)
- have gateway on each firewall node (distinct public IPs, distinct pool, ...)
The gateway split requires to have template stacks on panorama (the "highest" stack member only needs to contain the gateway configs and all it direct depends on)
11-30-2023 05:14 AM
Thanks for the reply..
planning this currently with load balancing the portal. we will be using a DNS name ie vpn.company.com which will use a cname to direct traffic towards the traffic manager in Azure.
traffic manager will then redirect this to the external load balancer's public IP which will then load balance between FW1 and FW2
I think this should work with configuring GP in this stack on panorama and pushing the same config (certs,portal/gateway etc) to both FWs. my other concern is IP Pools, as FW1 and FW2 are not aware of one another.. i might have to do an overide to have each FW use its own IP Pools.
So will test this with a self singed cert for now (imported into test machines so they are trusted) with a few local user accounts etc..
if this works next step would be saml integration and a trusted ca cert.
will also be doing hip profiling at a later stage.
any potential issues you can see for now? i will start with a test next week to see how it goes, and if it works, will post a short description of steps how to get it working.
thanks
12-12-2023 07:07 AM
Bit old school write up.. but managed to get this working with a base config. still lots to be done.
Config steps for GP via Azure traffic manager / Ext Load Balancer connecting to 2 active/active gateways.
for this i am using a local user account on palo alto fws and should allow me different IP pools per gateway
This is a phase1 approach and very basic. I Still need to do SAML, trusted CA cert and HIP profiling added.. but thought i would add this if anyone ever needed to do something similar.
lesson learnt for me.. 'know your Variables' - they are the way to go.
USing Panorama 10.1.10 with templates and device groups.
we have FW01 and FW02 sandwiched between an Azure internal and External loadbalancer. the FWs are in standalone mode (essentially the LB's do the active/active) so the FWs do not know of one another.
They do howerver belong to the same device group and template stack on panorama.
In the template group, I created a tunnel interface (tunnel.10) and assigned it to the trust VR and created a new zone to it (in my case i created a GP_Zone)
Created a self-signed CA Cert to the fqdn of the domain name ie vpn.company.com (in my case this DNS vpn.company.com is pointing to cname companyvpn.trafficmanager.net which points to the Ext LB public IP created
by the azure teams (which will pass this onto ext LB public IP)
Created a SSL/TLS profile pointing to new cert vpn.company.com
created local user in local user database
create an auth profile and add new user(s) to allow list
Portal and Gateway config - this is where it can get tricky.
need to use Variables for this to work.
Under my template, selected manage and created a Variable for $ETH1_1 (this is the variable for ethernet1/1 - untrust) and set it to 'none'. same for $GP_IPPool (ip pools for gp users) set to none.
Then under Panorama/Managed Devices/Summary select the FW01 and edit variable, then select to overdide the variables for FW01 IP and IP Pool and define their indiv IP addresses and IP Pools, and do the same for FW02 IP and its IP Pool
$ETH1_1 - FW untrust IP (FW01 5.5.5.1/28) (FW02 - 5.5.5.2/28)
$GP_IPPOOL - will define the IP Pools per FW (FW01 - 10.10.10.1-100) (FW02 - 10.10.11.1-100)
once done, if you go back to template and in your template stack, select to view under device key value.. you should see FW01 and FW02 showing their indiv IPs and separate IP Pools per FW
Create GP portal
few things to note.. in here under network settings, select the interface (in my case untrust ethernet1/1) and IPv4 only, for the IPv4 Address specify the variable instead of the actual IP ie $ETH1_1
Auth tab - add ssl/tsl profie created earlier, add client authorization and select the auth profile create earlier.
Under agent, give it a random name, config selection criteria set to any)
under External, add both gateways FW01 and FW02, fqdn for both is vpn.company.com and set source region restrictions if needed.
I added also my cert and seleted to install it to the local root cert store. (i think this is optional)
Create Gateway
create gateway, same for interface IP specify the variable instead of the real IP ie $ETH1_1
Authentication - again complete this section (add ssl/tsl profile created earlier, add client auth config similar to done in gateway portal.
Under agent, create in tunnel mode, specify the tunnel interface. (i kept ipsec disabled as i kept getting notifications popup when loggin in suspect udp 4501 being blocked so it reverts from ipsec back to ssl)
In Client settings, under IP Pool, add the variable created earlier ie $GP_IPPool
split tunnel - if you are using this, then you can add your routes to include here
under Client IP Pool tab, i left this blank.
network services tab.. add dns IPs etc in here.
.
in policy create security rules for gp_zone to your networks as per normal process to allow gp users to talk internally and externally if needed.
That I think is about it.
I had a few hicups with templates as i inherited these FWs and some of the template settings were overridden so had to make some
local policy changes (areas where variable was not showing as an optional in my template config on Panorama (in tunnel confg etc).. but unlikely you might have the same issue.
any enhancement ideas welcome.
cheers
12-12-2023 08:57 AM
Hello,
Just thinking outside the box to keep things simple, why not use HA on the PAN's in Azure, get rid of the external load balancers (unless you need them for other things) and use the built in global protect to decide where the GP client connects to?
HA in Azure: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClD9CAK
If you dont need the internal LB's you can get rid of them as well.
Just my thoughts.
12-13-2023 08:53 AM
Hello,
While I have not done this, it should work, however I think an active/passive HA for the PAN's might be smoother?
Regards,
12-13-2023 10:11 PM
It does work..I tested it in a live azure environment, also adding SAML was a breeze.. which to my surprise was very easy actually.. the only niggle I do find is that whilst GP APP can connect to both gateways, the LB still dictates where the initial connection goes, so gp app might report it is connected to gateway01, where in fact it might be connected to gateway02 - don't think there is a way around this but it is not critical unless the user specifcally wants to connect to a specific gateway which is unlikely.
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!