Food for Thought - Data Redistribution during HA Failover - User-ID

[nohash4u]

Hi All, 

I thought I would share something that gave me grief this week. 

Background

• Firewall A and firewall B are in an HA pair. 
• Both firewalls are configured to connect to a User-ID agent sitting on a Windows host within the environment. 
• Firewall A is configured as the data redistribution agent to redistribute User-ID information to other firewalls (data redistribution clients) in the environment (firewall B, firewall C, firewall D, etc.) 

Problem

Upon reviewing system logs from firewalls B, C, D, etc. I found a common alert: 'connect-agent-failure'. The initial thought was something broke in the initial configuration.

Investigation

I reviewed the troubleshooting steps outlined here only to discover that the data redistribution agent (firewall A) was not connected to the data redistribution clients (firewalls B,C, D, and so forth). 

After further analysis I deemed the system alert was due to the fact that firewall A had recently become the passive unit in the HA pair, so the configuration on the data redistribution clients pointing to firewall A would amount to nothing, as the passive unit does not redistribute username-to-IP-address mappings. Please note this was a hypothesis at the time. Logically, this makes sense to me as the passive unit does not pass traffic, however, I find this interesting as it requires you to have a second data redistribution configuration pointing to firewall B (data redistribution agent configured on firewall B, and data redistribution client configured on firewalls B, C, D, etc.). The result of such a configuration is one of the connections will always be up (to the active unit), while the other will always be down (to the passive unit). 

I am aware that there are configurations where this could be avoided, such as the use of Panorama as an intermediary, but I appreciate that Panorama is not in use in every environment! 

Solution

To remedy the issue I added a second data redistribution configuration within the environment where the clients (firewalls B, C, D, etc.) point to the agent on firewall B. Some additional takeaways from this configuration process were: 

1. The management interface of the data redistribution agent firewall needs to allow User-ID traffic. 
2. The paloalto-userid-agent application and associated port (default - 5007) must be allowed in security policy between the data redistribution agent and the data redistribution clients, as well as the data redistribution agent (node) firewall and the User-ID agent sitting on the Windows host. If you are adding another configuration (such was my case), then you will need to tinker with existing policy rules to include the relevant IP address of firewall B. 

The only area in the existing documentation that I could find which references anything similar to this discussion is here, however, the documentation references behaviour in an Active/Active situation, which was not the configuration used in my case. 

TLDR

Data redistribution was broken in my environment. The cause was determined to be there was only one configuration on the data redistribution clients pointing to firewall A. When firewall B became the active peer, the redistribution chain broke. This was resolved by adding a second data redistribution client configuration pointing to firewall B. The documentation is unclear on this behaviour, but logically it makes sense. Other configurations can be used to avoid this problem, but this is dependent on your environment. 

Additional Source(s)

Configure Data Redistribution 

User-ID NGFW 

[kiwi]

Hi @nohash4u ,

Thanks for sharing !