Perform a Config Audit
Table of Contents
Perform a Config Audit
Perform a configuration audit to assess and document impact of configuration changes
for Next-Gen firewalls.
Perform a config audit to assess and document impact of configuration changes, trace
back changes in case of an outage, and perform regular audits in order to adhere to
security compliance standards. For firewall in an active/passive high availability
(HA) configuration, you can only perform a config audit on the
active HA peer. Performing a config audit on the
secondary HA peer is not supported.
The Config Audit Change Summary supports config changes up to
25 MB in size. You can use the XML Diff if the config change
size for the selected config versions is larger than 25 MB. A warning message is
displayed when you view the Change Summary in the event one
of the selected config versions has config changes larger than 25 MB.
- Log in to the firewall web interface.Select .A summary audit of the local and running conf version, previous config versions, and saved config versions is displayed.
- Versions—The commit version for a particular commit. The version is assigned to a config commit by default and is sequential.(Panorama managed firewalls) The Previous Merged Running Config option supports both a successfully merged and failed merged configuration pushed from Panorama.
- Committed By—Administrator that committed the config change.
- Commit Date—Date and time the config was committed.
- Objects—Summary of config changes that occurred in the commit version. The config change summary displayed is relative to the running config at the time of the commit.
- —New configuration objects or policy rules were created as part of the commit.
![]()
- —Existing configuration objects or policy rules were deleted as part of the commit.
![]()
- —Existing configuration objects or policy rules were modified as part of the commit.
![]()
- Description—Commit description if added.
![]()
Select up two config versions and Compare Versions.When you select two versions that have multiple commit versions between them, the config audit displays the total sum of changes between the oldest and most recent config version. For example, when you compare versions 1 and 7, the config audit also displays all changes made in commit versions 2 through 6.The XML Diff displays a side-by-side comparison of the XML file differences between the two selected config versions.The left-hand XML is the older version and the right-hand XML is the newer version. Objects highlighted in green newly added configuration objects. Objects highlighted in red are deleted configuration objects. Objects highlighted in yellow are existing configuration objects that were modified.![]()
The Change Summary displays a detailed list of the configuration objects associated with the selected config versions.Review the change summary details to understand where and what configuration changes were made. Specifically, the Operation column displays what specific action was taken for the impacted configuration objects.Select a specific Object Name to view the Object Level Changes for the configuration object between the selected config versions. This shows you an XML snippet highlighting what changed.- Set—New configuration object was added.
- Edit—Existing configuration object was modified.
- Rename—Existing configuration object was renamed.
- Move—Reordering or moving policy rules within a rulebase.
- Delete—Configuration object was deleted.
The following operations may display as either two separate operations, or may not be displayed at all.- Renaming an existing configuration object is displayed as two separate changes. The first is a delete rename operation of the object with the old name. The second is a edit create for the same object with the new name.
- The Move operation is displayed only in the Change Summary. Policy rules that are moved are not displayed in the XML Diff.
- Config Audit cannot capture Load and Revert operations.
- (HA only) For firewalls in an Active/Passive high availability (HA) configuration, a config audit is supported only on the primary HA peer. You cannot perform a config audit from the web interface of the secondary HA peer.
![]()
