Device Group Data

device_state_cfg\device_state_cfg\sp\vsys1\sp-config.xml

Template Data

device_state_cfg\device_state_cfg\template\template-config.xml

Local Data <code>device_state_cfg\device_state_cfg\running-config.xml<code>

• ./opt/pancfg\mgmt/saved-configs/merged-running-config.xml - main config file. * ./tmp/cli/techsupport_hostname_date_time.txt - Lots of output from lots of commands * ./tmp/cli/logs/* - half a dozen files with cmd output and history * ./var/log/appweb/* - web server log files * ./var/log/* loads of log files * ./opt/pancfg/mgmt/ - configuration files * ./opt/pancfg/mgmt/saved-configs/ - this is where you can find running-config.xml ===== Edit Local Firewall Configuration ===== To get a configuration out of a tech support file, unzip the file and go to \opt\pancfg\mgmt\saved-configs and open running-config.xml To get system info tmp\cli ===== Edit Panorama Pre Rules ===== If you break access from a remote site to Panorama by putting a “deny all” in pre-rules, you can’t override the rule to fix the issue. I used to disable/copy Panorama rules to make the config local, fix the issue, reconnected and force a push from Panorama. I’ve just found out that you can on the firewall, - export the device state file from the firewall. - open the zip file - copy sp-config.xml from device_state_cfg.tar\sp\vsys1\sp-config.xml'' to anther folder (e.g. Desktop)

1. edit it to remove the bad rule
2. copy the file back in to the zip file
3. save it
4. import device state to firewall
5. commit to firewall

Much simpler than disconnecting from Panorama, fixing and reconnecting.

Alternatively PAN-OS 9.1+ has a feature where the firewall checks connectivity to Panorama after a commit and rolls back if the commit breaks Panorama access.