Palo commit and rollback

pushing policies and rolling back changes

26 October 2022   12 min read

Palo Alto firewalls use the concept of a running config to hold the devices live configuration and the candidate config is copy of the running config where changes are made. A Commit operation causes the running config to be overwritten by the candidate config activating the changes.

Within the GUI all the configuration file options can be found under Device » Setup » Operations » Configuration Management.


Table Of Contents



Viewing config changes

The running config is stored in running-config.xml and the candidate config in the hidden file .snapshot.xml. Below are some useful commands for viewing running config versions and changes made to the candidate config.

show log config                                    Audit of actions performed by users and from what medium (CLI or WEB)
show config audit info Shows all the previous versions, dates, job numbers and description
show job id job_id Shows a specific commit job with and warnings or details
show config audit version version Show the running config for a version, can filter with 'match' and 'except'
show config running Committed running config (XML only), can be filter to a specific section using 'xpath'

show config list change-summary The config section where changes have been made, this info can used in a partial commit or validation
show config list changes List of changed objects, is not raw config rather the xpath of the changed object
show config diff Raw config of the changes made + and - for diffs), can be view in xml, json or set
show config candidate View any non-committed saved or unsaved changes (XML only)

In the CLI it is only possible to compare the candidate and running config, I haven’t found a way to compare either of these against any of the past versions of the running config. Device » Config Audit allows for the comparison of any of the previous config versions, context is the number of lines to display either side of a difference.

The command diff config runs a ‘Preview-Chg’ job (like if doing a diff in the GUI), but as you cant select versions or view I am not sure of its purpose is. A reddit post suggested using it to set the number of context lines for show config diff but it didn’t seem to make any difference.

ste@HME-PAL-OEW1> diff config 
Preview Changes job enqueued with jobid 62
62
ste@HME-PAL-OEW1> show jobs id 62
Enqueued              Dequeued           ID                              Type                         Status Result Completed 
------------------------------------------------------------------------------------------------------------------------------
2022/10/23 10:29:39   10:29:39           62                       Preview-Chg                            FIN     OK 10:29:39  

When the firewalls are manged by Panorama can use a few additional commands on the firewall to view pushed and merged configuration.

show config pushed-shared-policy                   Displays only the policies and objects pushed from Panorama
show config pushed-template Displays only template device and network configuration (includes variables) pushed from Panorama
show config merged Displays merged local and panorama pushed (templates) device and network configuration

Rollback non-committed changes

There are 2 methods available to undo saved or unsaved changes (revert candidate config) that don’t touch the running config as nothing has been committing to it at this stage.

load config last-saved: Remove all unsaved changes by restoring the default candidate config snapshot (.snapshot.xml) overwriting the current unsaved candidate config (Revert Changes or Device » Setup » Operations » Config mgmt » Revert to last saved configuration).

ste@HME-PAL-OEW1# set address test_server ip-netmask 3.3.3.3/32
[edit] 
ste@HME-PAL-OEW1# run show config diff
               description "CatchAll PAT address for all other Internet traffic";
               ip-netmask 192.168.1.204;
             }
+            test_server {
+              ip-netmask 3.3.3.3/32;
+            }
           }
           address-group {
             grp_blu_zone {
[edit] 
ste@HME-PAL-OEW1# load config last-saved
Config loaded from .snapshot.xml
[edit] 
ste@HME-PAL-OEW1# run show config diff
[edit]
ste@HME-PAL-OEW1# 

Revert config: Revert all saved and unsaved changes made to the candidate config by loading the current running config, the configuration from last commit (Device » Setup » Operations » Config mgmt » Revert to running configuration)

ste@HME-PAL-OEW1# set tag TEST4
[edit] 
ste@HME-PAL-OEW1# save config
Config saved to .snapshot.xml
[edit]
ste@HME-PAL-OEW1# set address test_server ip-netmask 3.3.3.3/32
[edit]
ste@HME-PAL-OEW1# run show config list changes
xpath: /config/devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']/tag
owner: ste
action:  EDIT
other admins:ste
dirty id:10
prev dirty id:0
replaydbIds: 402
xpath: /config/devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']/address/entry[@name='test_server']
owner: ste
action:  CREATE
other admins:ste
dirty id:10
prev dirty id:0
replaydbIds: 403
[edit] 
ste@HME-PAL-OEW1# revert config
All changes were reverted from configuration
[edit]
ste@HME-PAL-OEW1# run show config list changes
There are no pending changes in journal.

Commit

Saved changes are written to the candidate config, these are not active, installed or implemented. The candidate config is reflected in the GUI and updated each time a change is made prior to a commit. Committing a change installs the changes in the candidate config into the running config.

Upon commit the device performs both a syntactic validation (of config syntax) and a semantic validation (whether the config is complete and makes sense). Palo recommends to perform a manual validation prior to a commit to catch any errors early rather than having a commit fail.

Both validations and commits are performed in configure mode and can be performed partially or on everything.

# validate partial device-and-network excluded policy-and-objects excluded
# validate full

# commit partial device-and-network excluded policy-and-objects excluded shared-object excluded
# commit description 'blah, blah, blah'

Below shows a full validation that failed.

# validate full
Validate job enqueued with jobid 26
26
[edit]
ste@HME-PAL-OEW1# run show jobs id 26
Enqueued              Dequeued           ID                              Type                         Status Result Completed
------------------------------------------------------------------------------------------------------------------------------
2022/07/31 11:28:07   11:28:07           26                          Validate                            FIN   FAIL 11:28:12
Warnings:
Details:Validation Error:
 rulebase -> security -> rules -> NTP -> to  is invalid. 'any' should not be used with another value
 rulebase -> security -> rules -> NTP -> to is invalid
 rulebase -> security -> rules is invalid
 rulebase -> security is invalid
 rulebase is invalid
 vsys is invalid
 devices is invalid

Prior to committing a candidate config there are a few useful commands available to compare what will be changed by this commit.

ste@HME-PAL-OEW1# run show config list change-summary 
Policy and Objects
[edit]
ste@HME-PAL-OEW1# run show config list changes 
xpath: /config/devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']/tag/entry[@name='COMPUTE']
owner: ste
action:  CREATE
other admins:ste
dirty id:6
prev dirty id:0
replaydbIds: 365
[edit]
ste@HME-PAL-OEW1# run set cli config-output-format set 
[edit]
ste@HME-PAL-OEW1# run show config diff
 set config devices localhost.localdomain vsys vsys1 tag "Network Services" comments "Network Services (NST) objects and rules"
 set config devices localhost.localdomain vsys vsys1 tag Red color color1
 set config devices localhost.localdomain vsys vsys1 tag Red comments "Red zone (RED) objects and rules"
+set config devices localhost.localdomain vsys vsys1 tag COMPUTE color color42
+set config devices localhost.localdomain vsys vsys1 tag COMPUTE comments "Compute tag"
 set config devices localhost.localdomain vsys vsys1 address net_blu_aggr tag Blue
 set config devices localhost.localdomain vsys vsys1 address net_blu_aggr ip-netmask 10.10.0.0/18
 set config devices localhost.localdomain vsys vsys1 address net_blu_lp12 tag Blue

The progress or results of a commit can be viewed as a job.

# commit description "Added Compute tag" 
Commit job 20 is in progress. Use Ctrl+C to return to command prompt
............55%.70%.98%..............100%
Configuration committed successfully
[edit]
# run show jobs id 20 
Enqueued              Dequeued           ID                              Type                         Status Result Completed 
------------------------------------------------------------------------------------------------------------------------------
2022/10/17 19:04:23   19:04:23           20                            Commit                            FIN     OK 19:05:15  
Warnings:
Details:Configuration committed successfully
Description: Added Compute tag

More detailed info can be gathered on the last commit, this includes things such as the phases it goes through and the processes it touches.

ste@HME-PAL-OEW1> show system last-commit-info 
Jobid: 53, User: ste, Type: Commit, Start: 2022/10/20 18:51:23, Fin: 2022/10/20 18:52:16
Committed Total Size: 13104683
Phase                Start                Finish               Total               
================
precommit            2022/10/20 18:51:24  2022/10/20 18:51:27  3                   
validate             2022/10/20 18:51:27  2022/10/20 18:51:27  0                   
p1                   2022/10/20 18:51:38  2022/10/20 18:51:58  20                  
p2                   2022/10/20 18:52:02  2022/10/20 18:52:05  3                   
postcommit           2022/10/20 18:52:05  2022/10/20 18:52:15  10                  
================
Client               P1Start              P1Finish             P1Total              P2Start              P2Finish             P2Total             
pppoed               2022/10/20 18:51:47  2022/10/20 18:51:47  0                    2022/10/20 18:52:02  2022/10/20 18:52:02  0                   
authd                2022/10/20 18:51:47  2022/10/20 18:51:47  0                    2022/10/20 18:52:02  2022/10/20 18:52:02  0  

Panorama commit and commit-all

When using Panorama there is one more stage where commit-all is used to push the committed changes to the individual firewalls. Panorama uses device-groups and templates as the partial options of commit and commit-all as the managed firewall configuration resolves around these.

# set device-group ste_global tag TEST comments "TEST tag" 
[edit]  
# commit partial device-group [ ste_global ] description "Added tag"
Commit job 13823 is in progress. Use Ctrl+C to return to command prompt
..12%.26%37%43%99%.................100%
Partial changes to commit: changes to configuration by all administrators
Changes to device-group configuration: (ste_global)
Configuration committed successfully

The serial number and vsys (vsys1 if not using multi-vsys) identify the devices that commit-all will push the committed configuration to.

> show devices connected
Serial                   Hostname        IPv4            IPv6                             Connected
--------------------------------------------------------------------------
001234000567890          cld-pal-oew01   172.22.241.6      unknown                                yes
Wildfire Real-time Stream Disablednot deactivated  VPN Disable Mode: no
  Operational Mode: normal
  HA Cluster State: cluster-unknown
  Certificate Status:
  Certificate subject Name: xxx-xx-xxx-xx-xxx
  Certificate expiry at: 2022/11/03 10:28:43
  Connected at: 2022/10/13 13:29:06
  Custom certificate Used: no
  Virtual Systems:
    vsys1(vsys1) shared policy md5sum:xxxxxxx()
           shared policy version:383
  Last masterkey push status: Unknown
  Last masterkey push timestamp:  none
  Express mode: no
Device cert present : Valid
Device cert expiry date : 2022/11/03 11:07:33 GMT
> commit-all shared-policy merge-with-candidate-cfg yes device-group ste_global devices 001234000567890 vsys vsys1
Job enqueued with jobid 13845
13845 
> show jobs id 13845
Enqueued              Dequeued           ID                              Type                         Status Result Completed
------------------------------------------------------------------------------------------------------------------------------
2022/10/23 12:21:46   12:21:46        13845                         CommitAll                            FIN     OK 100 %    
Description:
 -  001234000567890 commit succeeded with war     OK 12:21:46 12:22:33

If the Merge with Candidate Config is enabled the config sent from Panorama is first merged with any pending changes in the local candidate-config (intermediate commit) and then used to replace hte tunning-config on the device. This is the default option in the GUI, the logic is you would disable this if changes are also committed locally on the firewalls.

Rollback committed changes

Rollback is enacted by loading a previous version of the configuration to overwrite the current candidate config. As it is loading a previous configuration this operation undoes all changes that every administrator made to the candidate config since that commit.

  • Load config version: Load any of the previous versions (labeled by the date and time) that were automatically created by each commit
  • Load config from: Load a specific configuration file, could be a previously saved configuration or an imported configuration

Past commits with descriptions can be viewed in the CLI using show config audit info, there is no way to compare anything other than the running and candidate configurations from here. The only way to compare any 2 versions of the configurations is from Device » Config Audit, context is the number of lines to display either side of a difference.

Once loaded the configuration will not be used until it is committed. The only difference in this instance is that show config list changes can not be used to verify the changes.

ste@HME-PAL-OEW1# load config version 50 
Config loaded from 50
[edit]
ste@HME-PAL-OEW1# run show config list changes 
Partial operation is not allowed after a load operation. Full commit must be completed.
ste@HME-PAL-OEW1# run show config diff 
         predefined saas-application-usage-report;
       }
     }
-    content-preview;
   }
   devices {
     localhost.localdomain {
@@ -823,11 +822,7 @@
               color color42;
               comments "Compute tag";
             }
-            TEST {
-              color color33;
-            }
-            TEST1;
-            TEST4;
+            TEST;
           }
           address {
             net_blu_aggr {
[edit]                  
ste@HME-PAL-OEW1# commit description "Rollback tags"
Commit job 59 is in progress. Use Ctrl+C to return to command prompt
..............55%.70%.98%.............100%
Configuration committed successfully

[edit]

Configuration Management

On top of rollbacks Configuration Management can be used for backups, moving configuration between devices and replacing or merging it.

Import/ Export

Can import or export (to an XML file ) the current running config, a version of the running config or a candidate config snapshot. A standalone firewall can import or export a device state bundle that contains things such as running config, device-group and template.

Panorama allows for the importing of a devices complete configuration (automatically creates a template and device-group) or the exporting of the complete the configuration to a firewall without loading it (must load from firewalls cli).

> scp export configuration from xxxx.xml to username@host:path
> scp export device-state to username@host:path

> scp import device-state from username@host:path
> scp import configuration from username@host:path

Save

A device state bundle contains the running config, device-group, template settings and GlobalProtect portal certificate and satellite information of a firewall. This can be created locally on the firewall or from Panorama for any of the firewalls it manages

# save device-state 
# save device-state device <serial_number>

Depending on whether the save is done on the local firewall or Panorama a devices full configuration or a partial snapshot can be saved to file.

palo-fw# save config to [running-config.xml | <filename>]
palo-fw# save config partial device-and-network excluded 
+ policy-and-objects   policy-and-objects 
+ shared-object        shared-object 
+ to                   Filename

panorama# save config to [running-config.xml | <filename>]
panorama# save config partial no-device-group
+ device-and-network              device-and-network
+ shared-object                   shared-object
+ to                              Filename
> admin                           admin
> log-collector                   log-collector
> log-collector-group             log-collector-group
> no-log-collector                no-log-collector
> no-log-collector-group          no-log-collector-group
> no-template                     no-template
> no-template-stack               no-template-stack
> no-wildfire-appliance           no-wildfire-appliance
> no-wildfire-appliance-cluster   no-wildfire-appliance-cluster
> template                        template
> template-stack                  template-stack
> wildfire-appliance              wildfire-appliance
> wildfire-appliance-cluster      wildfire-appliance-cluster
  <Enter>                         Finish input

Load

A full or partial configuration can be loaded onto a device from an XML file . If loading an imported configuration that contains passwords and/or private keys the master key of the firewall or Panorama from which it was imported must also entered. If required it is also possible generate new UUIDs for all rules in the loaded configuration.

The XML formatted PAN-OS configuration uses x-path to allow the configuration to be navigated kind of like a tree, so each section can be filtered in a similar manner to how you do with JSON. This is very important when it comes to loading partial configurations as it is used to define the source and destination levels of the configuration to use.

This document gives good examples on how to format the from-xpath and to-xpath on different types of devices. To assist with finding the x-path location either enabling debug mode in the CLI or use https://device_ip/api » Configuration Commands » Devices, both are explained in more details in the Palo KB article.

ste@HME-PAL-OEW1# run debug cli on
[edit] 
ste@HME-PAL-OEW1# show address-group 
(container-tag: address-group)
((eol-matched: . #t) (eol-matched: . #t) (eol-matched: . #t) (xpath-prefix: . /config/devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']) (context-inserted-at-end-p: . #f))
/usr/local/bin/pan_ms_client --config-mode=default --set-prefix='set ' --cookie=5694476246776065 <<'EOF'  |sed 2>/dev/null -e 's/devices localhost.localdomain//'  |/usr/bin/less -X -E -M
<request cmd="get" obj="/config/devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']/address-group"></request>
EOF
address-group {
  grp_blu_zone {
    description "All Blue subnets";
    tag Blue;
    static [ net_blu_aggr net_blu_lp12 net_vpn_aggr];
  }
  grp_grn_zone {
    description "All Green subnets";
    tag Green;
    static net_grn_aggr;
  }

The load config command specifies the loaded configuration XML node that it is being copied from (from-xpath), and the candidate configuration XML node that it is being copied to (to-xpath). The to-xpath begins at /config whereas the from-xpath begins at devices or shared, if in doubt can always check with show config running xpath

# run show config running xpath devices/entry[@name='localhost.localdomain']/vsys/entry[@name='vsys1']/address-group
# load config partial mode [append|merge|replace] from-xpath <source-xpath> to-xpath <destination-xpath> from <filename>

Reference

Palo KB articles on Backing Up and Restoring Configurations, Export Device State, Saving Candidate config and Commit Configurations from CLI.
Palo KB articles on finding the xpath values, xpath location formats and loading partial configurations.
This is a good non-palo post explaining the configuration management operations, although this doesn’t really have explanations it shows you the different GUI and CLI location for configuration management operations.