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 configAudit of actions performed by users and from what medium (CLI or WEB) show config audit infoShows all the previous versions, dates, job numbers and description show job idjob_id Shows a specific commit job with and warnings or details show config audit versionversion Show the running config for a version, can filter with 'match' and 'except' show config runningCommitted running config (XML only), can be filter to a specific section using 'xpath' show config list change-summaryThe config section where changes have been made, this info can used in a partial commit or validation show config list changesList of changed objects, is not raw config rather the xpath of the changed object show config diffRaw config of the changes made + and - for diffs), can be view in xml, json or set show config candidateView 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-policyDisplays only the policies and objects pushed from Panorama show config pushed-templateDisplays only template device and network configuration (includes variables) pushed from Panorama show config mergedDisplays 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 partialdevice-and-network excluded policy-and-objects excluded # validate full# commit partialdevice-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 fromxxxx.xml tousername@host:path > scp export device-state tousername@host:path > scp import device-state fromusername@host:path > scp import configuration fromusername@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.