I'm looking for the correct way to build our UserID redistribution topology based on our enterprise needs.
We have 1 Panorama appliance, 4 PA3020 hosting a GP Gateway component and 50 PA3020 for remote offices.
Our only source for UserID is the GP Gateways.
I've set up Panorama to retrieve UserID information from our 4 GP Gateway and our remote offices firewalls to pull UserID from Panorama, this works just fine.
I also need to have our whole company UserID database on the 4 GP Gateways. Won't it create a topology loop if I tell our GP Gateways to also retrieve UserID from Panorama?
Thanks for your help.
I was hoping for what you said to be true, but in our environment we see the opposite.
We have two separate firewalls with GP portal and gateway on each. We have configured user-id redistribution between the two firewalls (in both directions). So each FW1 should redistribute user-id from local gp to FW2 and vice versa.
From the user-id logs below you can see that when user connect to GP on FW1 it will redistribute it to FW2, but FW2 will redistribute the same entry back to FW1.
It is probably worth mentioning that we are using pre-logon GP and fw receives only the username (without the domain) from gp, so we had to put the domain in authentication profile. This probably explain why "user provided by source" for any gp related logs is only username.
I am looking for a way to avoid this "redistribution loop", but so far no luck.
I had this happen with Panorama in past. Appeared that FW1 would learn from GP gateway on FW1, then push to panorama, then panorama would push to FW2. Panorama would also learn from FW2, then push back that entry back to the FW1, and in some case FW 2 would not have that IP to user mapping entry. Would mess with user to ip mapping big time, and in some cases clear that mapping if the other firewall didn't have it in time. I removed Panorama from that mix and just let firewalls talk directly, and haven't had an issue.
Thanks for sharing this info, I opened a case about this in trying to figure out the best redist in a large enterprise with 4 pairs of 7080 with 100s' of vsys and 90 gp gateways. would be nice of Palo Alto could post an approved large scale KB that shows to do this in an approved method (with dual panoramas, multiple firewalls, with multiple vsys, and multiple gp gateways on the vsys) so that we can all setup this up without melting down our networks.
It's going to pass on whatever it receives to whoever is subscribing is my understanding of it. I could be wrong, but it seems as once it gets something and needs to redistribute it, there is no check against if a fw device has already learned that mapping, it's going to pass it on regardless, and possibility overwrite what the device may have learned already (if there is another source feeding that fw). The firewall won't care either, it will just take the last update it sees. I would guess that setting up in a non-redundant fashion would solve that problem, but just be aware that the possibility of overwrites exist if the fw learns from multiple sources or a loop gets introduced.
I had a hour long meeting with a Palo engineer about large enterprise userid redist where a (2) hub and spoke design is recommended.
The hubs could be vm50 or vm300s or 3200 series (due to support of 512K of ip/username mappings).
The spoke firewalls could be multi-vsys firewalls, where there can be multiple vpn gateways in different vsys.
In both hubs, you would configure user-id agents to point to each vsys that you want to collect userids.
Then in each multi-vsys firewall you would configure a user-id hub.
The userid hub in each spoke would also be configured as a userid agent pointing to both hubs.
Both hubs would need to haver user-id redist configured in the same vsys as the list of user-id agents
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!