A Palo Alto firewall change has broken an application. You click Revert to running configuration, but the outage remains. The key distinction: that operation discards uncommitted candidate edits; it does not undo the configuration that is already running. To restore an older committed firewall configuration, load the intended saved version and commit it after reviewing the differences.[1]
This guide answers how to roll back a Palo Alto configuration safely, including the additional deployment boundary introduced by Panorama. It provides a decision table, a change-control worksheet and a recovery acceptance matrix. The workflow is an original operational recommendation, not a record of a production incident or a tested recovery-time guarantee.
First decide: uncommitted edit or committed outage?
PAN-OS revert and load operations replace settings in the candidate configuration; applying an older loaded configuration to the running system requires a commit.[1] Panorama also distinguishes its candidate and running configurations, and a commit to Panorama is separate from a push to managed firewalls.[2][5]
Use the following table to choose the configuration layer before touching a rollback control. The operation semantics come from the vendor documentation; the evidence gates are recommended safeguards.[1][2][5]
| Current situation | Appropriate starting operation | What must still be verified |
|---|---|---|
| Unwanted firewall edits have not been committed | Revert the relevant pending changes, or revert to running configuration with the correct scope | Other administrators' pending work is preserved; no running outage is being mistaken for a candidate problem |
| An unwanted local firewall change is already committed | Load the approved previous configuration version or named snapshot; review and commit | The selected version predates the fault and does not remove later legitimate changes |
| Panorama edits are still uncommitted | Revert the appropriate Panorama candidate scope | Correct device groups, templates and shared dependencies are included |
| Bad change is committed on Panorama but not pushed | Restore/correct the Panorama configuration and commit through the approved procedure | No affected device actually received the bad configuration; pending pushes cannot deploy it later |
| Bad Panorama change reached managed firewalls | Restore/correct it at the Panorama layer, commit, and push to the intended devices | Per-device deployment result, effective configuration and application behavior |
| Administrative access is lost or the deployment state is unknown | Use the established console/out-of-band recovery path and establish actual state | Reachability, credentials, device identity and configuration ownership before any further load/push |
Do not use “last version” as a synonym for “known good.” In your worksheet, identify the version by timestamp, change description and reviewed content. If unrelated changes landed after your baseline, decide explicitly whether to preserve them with a corrective edit or accept their removal as part of a broader restoration.
Pre-change worksheet: make rollback an executable decision
Complete this worksheet before a risky policy, NAT, routing or template change. Store configuration files and diffs in an access-controlled repository, not in a public ticket attachment. These fields are recommendations rather than vendor-mandated values.
| Field | What to record | Stop condition |
|---|---|---|
| Owner and scope | Local firewall or Panorama; affected configuration areas; exact intended deployment targets | Ownership or blast radius is unclear |
| Software and privileges | Actual PAN-OS/Panorama release, authorized operator and reviewed release-specific procedure | Operator cannot perform the required restore/commit |
| Baseline | Known-good configuration version or named export, timestamp and baseline test evidence | File exists but content or applicability has not been checked |
| Concurrent work | Pending changes and later committed changes from all affected administrators | Restore would silently erase unrelated work |
| Access recovery | Tested console/out-of-band route and approved emergency access process | Change can remove the only available management path |
| Panorama push options | Device groups/templates, selected devices, local candidate merge decision and any overrides | Default selections have not been inspected |
| Trigger | Which application failures or security regressions require rollback | Decision depends only on a green commit result |
| Recovery gate | Application owner, negative security tests and observation period | Nobody owns acceptance of the recovered service |
Palo Alto documents that a firewall saves a running configuration version on each commit and supports loading those versions, named snapshots and imported configuration files.[1] Treat the existence of a version as a recovery input, not proof that it is the right baseline.
For Panorama management-server configuration restoration, the documentation specifies a full commit and a superuser; do not assume an account that can perform ordinary scoped edits can execute every restoration operation.[2] Check the relevant procedure and privileges before the maintenance window.
Local firewall workflow: load, inspect, then commit
1. Establish the fault boundary
Record the last successful application transaction, the relevant change job and the current configuration state. If the change was not committed, investigate whether the reported outage belongs to an earlier event before assuming the candidate edits caused it. Freeze overlapping changes for the recovery window with the relevant administrators.
2. Preserve evidence before replacement
Capture the current running configuration, pending candidate work and the difference you intend to reverse. Retain the broken state privately for diagnosis, but never leave recovery dependent on a file whose origin you cannot explain.
A firewall configuration snapshot and an exported device-state bundle are not interchangeable concepts: the vendor describes device state as including running configuration plus Panorama-pushed device group/template information and, for a GlobalProtect portal, additional certificate and satellite information.[1] Replacement-device restoration is therefore outside this simple change-rollback checklist; use the specific restore procedure for that scenario.
3. Load the approved version into the candidate configuration
The vendor GUI workflow uses Device > Setup > Operations for the load/revert controls, and its CLI example uses load config in configuration mode.[3] The exact screen labels and available choices should be checked against your deployed release.
The following is an unexecuted CLI template, not a paste-and-run recovery script. Replace the placeholder with a version you have independently reviewed. Stop after the load to inspect the candidate difference; the later commit is a separate approval gate.[1][3]
configure
load config version <APPROVED_VERSION>
Check that the candidate contains the intended restoration and no unrelated management, routing, policy or object changes. Resolve validation errors and dependencies before proceeding. Do not turn a narrow application incident into an unreviewed whole-device restoration.
Only after that review, the vendor's documented activation step is:[3]
commit
exit
Loading alone is not the completed rollback. The running configuration is overwritten when the restored candidate is committed.[1] Conversely, loading a version and then casually discarding candidate changes would abandon the prepared restoration rather than activate it.
4. Prove recovery, not just commit completion
Record the commit outcome, then run the acceptance matrix below from the affected client path. Do not declare success based solely on a configuration job. Retain the before/after evidence and have the application owner confirm the business transaction.
Panorama rollback: two configuration boundaries to verify
A Panorama commit activates changes in Panorama's own configuration; Commit to Panorama does not push those changes to managed firewalls.[5] Modern Panorama pushes its running configuration, so the intended correction must be committed there before deployment to devices.[5]
A practical recovery sequence is:
- Identify whether the fault originated in a device group, template/template stack, shared configuration or a separate local firewall edit.
- Review a known-good Panorama version or make a targeted corrective change. Choose the smallest dependency-complete restoration that meets the approved recovery scope.
- Inspect the diff, permissions and commit requirements. Complete the Panorama commit and record its result.
- Inspect Push Scope and the actual selected firewalls before deployment. Do not assume all out-of-sync devices belong to this incident.
- Validate the applicable device-group/template push and resolve errors. Push the reviewed correction.
- Inspect every intended device's result; compare the deployed state with your scope worksheet and then test the applications.
The documented push scope can include out-of-sync entities, and the interface provides Edit Selections to change the deployment targets.[5] This is why a correct configuration restoration still needs a separate target review.
The local candidate merge trap
The documented Merge with Candidate Config option is selected by default and merges pending local firewall edits with the Panorama push; that push triggers a commit of the merged configuration.[5] If local work is managed independently and must not be committed as part of recovery, the documentation says to clear this selection.[5]
Do not treat this checkbox as a universal on/off rule. Record the intended behavior, inspect pending local edits and approve the resulting scope. Otherwise the recovery push can become an unintended release of unrelated candidate work.
Similarly, Force Template Values replaces locally overridden values with template values where applicable; the vendor explicitly warns to inspect overrides before using it.[5] It is not a generic “make rollback work” switch.
Recovery acceptance matrix: copy into the change record
This matrix is an original recommended test asset. Define expected results and observation windows before the change; no production tests or measured recovery times are claimed here.
| Test | Before-change evidence | Recovery pass criterion | If it fails |
|---|---|---|---|
| Administrative access | Approved management and emergency-access paths work | Intended access restored without broadening administrative exposure | Stop further remote edits; use the approved recovery path |
| Configuration deployment | Baseline version and owning configuration layer recorded | Intended correction is present on every target; no unexplained target omitted | Reconcile per-device job results and deployment scope |
| Positive application transaction | Successful login plus representative read/write or business operation | Same operation succeeds from the affected client location | Investigate the specific traffic path rather than reloading more versions |
| Negative security control | Explicitly forbidden test remains blocked | Forbidden path is still blocked after restoration | Treat apparent service recovery as incomplete |
| NAT and return path | Intended translation and reachability evidence retained | Fresh test traffic follows the expected path and translation | Compare restored policy, routing and surrounding network state |
| VPN-dependent service, if applicable | Application transaction across the tunnel succeeds | Application works, not merely tunnel status | Use the dedicated IPsec troubleshooting matrix linked below |
| Unrelated critical service | A control service outside the change's purpose works | Control service still works | Check whether the selected baseline removed later valid work |
| Monitoring and handover | Logs/alerts visible and application owner named | Evidence is retained, monitoring is healthy and owner accepts recovery | Keep the incident open and document residual risk |
For an application path that is still broken after configuration recovery, continue with the Palo Alto IPsec tunnel-up/no-traffic troubleshooting matrix or the GlobalProtect connected-but-no-access checklist, as appropriate. These diagnose traffic failures; they do not replace verification of the rollback itself.
Isolated lab exercise before the real maintenance window
Use a disposable, isolated lab and a harmless configuration change, not a production default route or administrative access rule. First record a working baseline. Make an uncommitted edit and observe the effect of reverting to running configuration. Then make and commit a harmless edit, load the earlier reviewed version, and observe the distinction between the loaded candidate and the running configuration before committing it.
If you operate Panorama, repeat the exercise with a single lab target. Record Panorama commit completion separately from device push completion, and examine local pending candidate work before choosing the merge behavior. Use a disposable local description change to demonstrate scope, not a permissive security rule. The expected configuration-state distinctions are documented by Palo Alto; this exercise has not been executed for this article.[1][2][5]
Practical takeaways
- Uncommitted mistake: revert the intended candidate scope; reverting to running discards pending edits.[1]
- Committed local mistake: load the reviewed known-good version and commit it after checking the diff.[1][3]
- Committed-and-pushed Panorama mistake: recover the source configuration, commit it on Panorama, deploy the correction to the intended devices and verify each result.[2][5]
- Operational acceptance: require application success, preserved security boundaries and a clear record of unrelated changes retained or intentionally reversed.
The durable asset is not the command pair. It is the combination of an identified baseline, a reviewed deployment scope and a repeatable recovery test. Browse Start Here for related networking guides and the Resources page for reference tools.
Sources
- [1] https://docs.paloaltonetworks.com/ngfw/administration/firewall-administration/manage-configuration-backups/revert-firewall-configuration-changes
- [2] https://docs.paloaltonetworks.com/panorama/administration/administer-panorama/manage-panorama-and-firewall-configuration-backups/revert-panorama-configuration-changes
- [3] https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm9uCAC
- [5] https://docs.paloaltonetworks.com/ngfw/help/12-2/panorama-web-interface/panorama-commit-operations
Post a Comment