Configuration changed on standby member-paloaltonetworks-panos

Configuration changed on standby member-paloaltonetworks-panos
1.0 1

Configuration changed on standby member-paloaltonetworks-panos

Vendor: paloaltonetworks

OS: panos

Description:
Generally, making configuration changes to the standby member of a device is not recommended. indeni will trigger an issue if this happens.

Remediation Steps:
Make the configuration changes to the active member of the cluster.

How does this work?
This alert logs into the Palo Alto Networks firewall through SSH and retrieves the difference between the committed configuration and the saved configuration. If a change is found, an alert is issued.

Why is this important?
After changing the configuration of a device it is always important to remember to commit the changes. In the case of Palo Alto Networks, without committing the changes they will not take effect. A common issue is when an administrator makes certain changes, does not commit them, and walks away. Another administrator will log on later, make their own changes and commit them. In the process, they will be committing the other administrator’s changes, potentially causing issues.

Without Indeni how would you find this?
The web interface on a Palo Alto Networks firewall provides an indication of whether or not there is a change which requires committing. Failing to notice that, a user would run into the problem described above.

panos-show-config-diff

Failed to fetch the data: https://bitbucket.org/indeni/indeni-knowledge/src/master/parsers/src/panw/panos/show-config-diff.ind

panos-show-high-availability-all-monitoring

Failed to fetch the data: https://bitbucket.org/indeni/indeni-knowledge/src/master/parsers/src/panw/panos/show-high-availability-all-monitoring.ind

panos-show-high-availability-all-monitoring

Failed to fetch the data: https://bitbucket.org/indeni/indeni-knowledge/src/master/parsers/src/panw/panos/show-high-availability-all-monitoring.ind

cross_vendor_config_change_on_standby

Failed to fetch the data: https://bitbucket.org/indeni/indeni-knowledge/src/master/rules/sync_core_rules/ConfigChangeOnStandbyMemberRule.scala

This is somewhat irrelevant on a Palo Alto HA deployment. This should be deprecated for Palo Alto in my opinion.

Changes can be made on the secondary and they sync to the primary just the same as they are done in reverse with a few exceptions if multiple people are making changes and the primary has a config-lock. While not typical, there isn’t a reason you couldn’t do it that way and be successful. Most changes would just be made from Panorama though really.

Quoted from the admin guide:
“To avoid configuration conflicts, always make configuration changes on the active (active/passive) or active-primary (active/active) peer and wait for the changes to sync to the peer before making any additional configuration changes.
Only committed configurations synchronize between HA peers. Any configuration in the commit queue at the time of an HA sync will not be synchronized.”

As a firewall admin I would appreciate Indeni showing the config diff adding value to this alert should it be kept. Another though is this alert would clear after the commit and would only be caught if the commit didn’t occur before the polling of the script occurred. Therefore a config change could occur on the secondary without Indeni knowing anyway.

Also, there are several items on a standby member that need to be configured locally that are not synchronized to the primary. These items would trigger this alert until they are committed.
https://docs.paloaltonetworks.com/pan-os/7-1/pan-os-admin/high-availability/reference-ha-synchronization