Correct way to setup UserID redistribution

[Jean-Damien]

Hi there,

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.

[reaper]

firewalls only share information they 'learned locally' to redistribution, so anything they learn FROM redistribution won't be fed back into it

(the above is outdated info)

Firewalls will redistribute all user-id mapping except the ones learned from TS-agent, so ideally all user-id should be collected in one central place (like Panorama) and then redistributed to all firewalls that need the information to prevent loops from forming 

[aleksandar.astardzhiev]

Hi @reaper,

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.

[Sec101]

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. 

[padden]

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.

[Sec101]

Don't do it with panorama.    set aside firewalls dedicated to UID redistribution, and do it that way.

[padden]

Would you care to expand as why not to use panorama as a userid redist?
I have 2 M600 and they should have the cpu to do the job?

[Sec101]

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.

[padden]

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

[mb_equate]

I'm about to do exactly this for a customer, but in my lab I'm having a similar issue. Panorama reflects the mapping obtained by a GP gateway to the spokes but without a username. I also found the TTL of the GP source at the source was sometimes 0 which I suspect is why local mappings are being overwritten by the blank user.

I ended up ditching Panorama as a hub which is easy with 2 gateways, although means I can't use the one template to drive redistribution unless I want the gateways getting mappings from themselves 🙂

All seems well however still seeing the blank mappings reflected back to the source by the peer device - in this case it doesn't get overwritten but I'm still concerned that blank mappings are being redistributed - what gives?