Skip to content

Troubleshooting

Common Problems and Solutions

Troubleshooting Cortex XDR

  1. Enable Debug Logging - In Splunk, navigate to the Splunk Add-on for Palo Alto Networks. - Navigate to Configuration and click on the logging. Then change the log level to DEBUG and click on “Save” button.
  2. Use this Splunk search to troubleshoot error messages from Cortex XDR.
index="_internal" sourcetype="splunk_ta_paloalto_networks*"

Time and Timezone Problems

There are a few factors that determine the time and timezone of a log:

  1. The Splunk server’s time and date
  2. The Splunk server timezone, or the Splunk container timezone when using Docker
  3. The date/time and timezone settings on Firewall, Panorama, or Traps ESM
  4. The per-log timezone setting in props.conf

By default, the Add-on do not interpret timezones or have any preconfigured timezone settings.

Firewall/Panorama and Traps always output logs without a timezone, so the timezone setting is honored, but not included with the log. For example, if your Firewall is set to 8:00:00 EST, then the time in the syslog will be 8:00:00 (without the EST timezone).

Splunk always interprets Palo Alto Networks logs as the timezone of the Splunk server (or container).

Therefor, if a Splunk server and Firewall have the same timezone, then the timestamp will be interpreted correctly by Splunk. If they have different timezones, then the interpreted time will be offset by the difference in the timezones. You can overcome this by creating a local/props.conf file that explicitly sets the timezone for the logs. For example, if Splunk is set to UTC and the Firewall is set to EST, then configure a local props.conf file to interpret the Firewall logs as EST, as they will incorrectly be interpreted as UTC by default.

An example timezone setting in props.conf might look like this:

[host::newyork-firewall-*]
TZ = US/Eastern

This example would cause logs from newyork-firewall-1, newyork-firewall-2, etc. to be interpreted as US/Eastern timezone.

Logs have only sourcetype of pan:log

You set the sourcetype to pan:log in your inputs.conf, however, Splunk parses the logs and changes the sourcetype to a more specific one, including pan:traffic, pan:threat, pan:system, pan:config, and others.

If your logs are not getting converted to these other sourcetypes and are instead remaining with the pan:log sourcetype, then there is a parsing issue with the logs. This can happen for several reason, so please check each of these reason until the problem is resolved. Note that sourcetype changes happen at index-time so only newly received logs will get parsed to a sourcetype.

  1. Use the correct log format. For Firewall or Panorama logs, use the default syslog format. For Traps logs use CEF format.
  2. For UDP logs, try adding no_appending_timestamp = true to your inputs.conf.
  3. Ensure the Palo Alto Networks Add-on is installed on all Indexers and Heavy Forwarders, and configure the inputs.conf on the node receiving the logs.