password not working in active device

[Aftab_786]

We have an Active/Passive Palo Alto HA setup with IPs .135 (primary/active) and .136 (secondary/passive). About a month ago, when logging in via the VIP, I landed on .136 (active at that time not sure how it became active ) and was able to access it, but couldn't log in directly on .135. Last week, following an issue, the roles switched—.136 became passive and .135 active now. However, the credentials that used to work on .135 no longer do, including a test user account I created in April 2025 for emergency access, which still works on .136 but not on .135.

Complicating this, HA configuration sync between the units hasn’t been functioning for over a year, which went unnoticed until now.

Since we can’t access the active primary (.135), we can’t switch traffic manually from primary to secondary using failover commands. I am considering the following approach and would appreciate community feedback:

1. Log into .136 (currently passive).

2. Manually make .136 active by lowering its HA priority from 100 to 50.

3. Reboot the current active firewall (.135).

4. Once .136 becomes active, perform config sync from .136 to .135.

5. Verify access and HA state.

Alternatively, would simply rebooting the active firewall (.135), which has been up for about 700 days, potentially resolve the login issue if the problem is related to resource exhaustion or a system fault?

What is the best practice in this scenario to regain control without losing network availability or risking misconfiguration? Any guidance on handling stale HA sync issues along with access lockout is also appreciated.

Thank you in advance for your support!

[BPry]

@Aftab_786,

Oh man ... that's a whole lot of unknowns when you have so many variables in play. I would 100% not move forward with anything outside of a maintenance window if things are currently working if you haven't had config sync in a year. It doesn't seem like you have traffic impacting config drift with a years worth of changes missing, but in most environments that would mean you're missing rules you would likely need. However 700 days without an update perhaps that isn't the case in your environment.

2. Manually make .136 active by lowering its HA priority from 100 to 50.

Do you have preempt enabled so that this would actually work? 

4. Once .136 becomes active, perform config sync from .136 to .135.

Do you want the config from 136? If 135 is your primary and supposedly where any configuration changes would have been made, that should be your most current configuration should it not? I would be looking at the diff between peers and seeing which config you actually want to take over or at least have the knowledge needed to 'rebuild' any required changes.

Alternatively, would simply rebooting the active firewall (.135), which has been up for about 700 days, potentially resolve the login issue if the problem is related to resource exhaustion or a system fault?

You have recent experience that your failover is functional, so you do have the option of simply rebooting .135 and allowing your passive firewall to take over things and seeing if that addresses your access issues. This would be my recommendation (within a maintenance window) and then you can see if that fixes your login issues and then deal with the configuration sync problems. 

[Aftab_786]

Oh man ... that's a whole lot of unknowns when you have so many variables in play. I would 100% not move forward with anything outside of a maintenance window if things are currently working if you haven't had config sync in a year. It doesn't seem like you have traffic impacting config drift with a years worth of changes missing, but in most environments that would mean you're missing rules you would likely need. However 700 days without an update perhaps that isn't the case in your environment.

2. Manually make .136 active by lowering its HA priority from 100 to 50.---question--p-if i make .136(currently passive) reduce the priority to 50 will it become active as .135 (currently active) already have priority as 50?

What about this command "request high-availability state" in the passive (.136) firewall...will this work ...if yes..then do we need to lower the priority in passive(.136)?

Do you have preempt enabled so that this would actually work? ---from the below logs it looks like preempt is not enabled

<high-availability> (from passive got this one from 1 of the old backup)
<group>
<group-id>1</group-id>
<peer-ip>1.1.1.1</peer-ip>
<mode>
<active-passive>
<passive-link-state>auto</passive-link-state>
</active-passive>
</mode>
<preemptive>no</preemptive>

<high-availability> (from active got this one from old backup)
<group>
<group-id>1</group-id>
<peer-ip>1.1.1.2</peer-ip>
<mode>
<active-passive>
<passive-link-state>auto</passive-link-state>
</active-passive>
</mode>
<device-priority>50</device-priority>
<preemptive>no</preemptive>

4. Once .136 becomes active, perform config sync from .136 to .135.

Do you want the config from 136? If 135 is your primary and supposedly where any configuration changes would have been made, that should be your most current configuration should it not? I would be looking at the diff between peers and seeing which config you actually want to take over or at least have the knowledge needed to 'rebuild' any required changes.

There are not much configuration changes are done on these firewalls as we used these firewalls very less as there is only 1 server behind it there is no issue if the config got sync from .136 to .135 but i should not loose the login, i was aware of similar kind of ha issue might happen in future so i made a test user and if do a config audit from the passive(.136) .i can login with the created user aftabtest in passive (screenshot of the config audit attached)