Automating the Palo Alto NGFW's Process/Deamon Restarts

Showing results for 
Show  only  | Search instead for 
Did you mean: 
L6 Presenter
100% helpful (4/4)


The Palo Alto NGFW has a great API interface and there is even an integrated tool to view the API commands, called api browser that is located at the <firewall ip>/api and it is described at Use the API Browser (there is even a debug window for API traffic. You can also read Use the Web Interface to Find XML API Syntax or Use the CLI to Find XML API Syntax ) but it does not provide access to the operational commands that are starting with "debug xxxx" but why do we need access to those commands?







The answer to the previous question is to restart some palo alto processes without rebooting the full firewall.


For example "debug software restart process web-server" is to restart the backend web-server that is responsible for the PAN-OS GUI. I also suggest checking the articles below:



The issue that the API does not have access to the debug commands is that we can't use something like Ansible "paloaltonetworks.panos.panos_op modulewhich allows to execute random operational commands with Ansible. Ansible has a separate module to run random config commands called panos_config_element and another one called panos_type_cmd (panos_type_cmd seems older one and does not do good checks when pushing commands). We also can't use the Palo Alto XSOAR PAN-OS integration that is shown herebut the XSOAR RemoteAccessV2 is another option to push a debug commands, using SSH, to reboot a process.


As a note, Terraform is more limited to triggering custom commands with its Resources (similar to Ansible modules with tasks) on the Palo Alto Firewalls compared to Ansible (panos_type_cmd/ panos_config_element and panos_op) or Cortex XSOAR (the PAN-OS or RemoteAccessV2 integrations) as Terraform's idea is to have predefined Resources and there is Terraform resource like in Ansible to send custom Operational or Type (configuration) commands if they are available through the Palo Alto API, so only the predefined resources can be used and you can check out this page from Terraform.


Example Playbook for operational commands (except debug commands). For everything else Ansible and XSOAR are still good options (you may need to do things like"pip install pan-os-python " as for some reason when the Ansible collection is installed this is missing.





- name: Palo Alto Provision

  hosts: palo

  connection: local

  gather_facts: false




   api_key: xxxxxx

   ip_address: "{{ ansible_host }}"



- paloaltonetworks.panos



- name: show list of all interfaces


     provider: '{{ provider }}'

     cmd: 'show interface all'



The solution to this issue are the good old TCL Expect scripts! Some may not know but this is one of the first ways to do automation by using SSH even before API was an option. As noted leave the "management-server" process for last if you need to restart it together with other processes as it can kill the script's ssh connection!


Example of a TCL expect script (when the management server is restarted nothing is seen in the CLI, so we can't use "expect" and the ssh connection is terminated, so this process should be restarted at the end):




#!/usr/bin/expect -f


# Get the commands to run, one per line

set timeout 60

spawn $env(SHELL)

set DEBUG 1

set USER xxxx

set PASS xxxx

set IP_AD xxxx


spawn ssh $USER@$IP_AD

match_max 100000

expect "*?assword:*"

send -- "$PASS\r"

sleep 2

expect "*>*"

send -- "set cli terminal width 200\r"

sleep 2

expect "*>*"

send -- "set cli scripting-mode on\r"

sleep 2

expect "*>*"

send -- "set cli terminal type xterm\r"

sleep 2

expect "*>*"

send -- "debug software restart process web-backend\r"

expect "*was restarted*"

sleep 2

expect "*>*"

send -- "debug software restart process web-server\r"

expect "*was restarted*"

sleep 2

expect "*>*"

send -- "debug software restart process sslvpn-web-server\r"

expect "*was restarted*"

sleep 2

expect "*>*"

send -- "debug software restart process management-server\r"

expect eof



"expect eof" is only needed for the management-server restart at the end of the scrip as it not always returns "was restarted" and this will keep the connection open until the management server restart kills it or the script times out.


The TCL Expect script can be on a linux server and Ansible and Cortex XSOAR when there is an Incident and logs in the Cortex Data Lake with its RemoteAccessv2 integration can trigger it as this seems a great integration!

Rate this article:
Community Team Member

great work @nikoolayy1 !

L4 Transporter

Thanks @nikoolayy1

Community Manager
Community Manager

Love to see our members contribute content for the greater good of the community! Thanks @nikoolayy1 !

L6 Presenter

I am really happy that people find this helpful 🙂


  • 270 Subscriptions
Register or Sign-in
Article Dashboard
Version history
Last Updated:
‎04-18-2024 12:43 PM
Updated by: