- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-07-2025 12:50 PM
Hi All,
I thought I would share something that gave me grief this week.
Background
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:
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)
02-10-2025 01:14 AM
Hi @nohash4u ,
Thanks for sharing !
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!