Known Issues in Log Forwarding App

This document details the known issues in the current release of the Palo Alto Networks Log Forwarding app.
The current release of Log Forwarding app has the following known issues:
With the cloud delivery model, the list of addressed issues is not cumulative. Known issues that have been addressed in the last software update are marked below, and these issues will be removed from this list when we publish the documentation for the next software update.
Older versions of Rsyslog cannot authenticate successfully to the Log Forwarding app because the SSL certificate chain of trust cannot be verified. For example, this is a known issue with Rsyslog version 8.24.
Workaround: Upgrade to Rsyslog version 8.37 or later to fix the certificate chain issue.
When you configure granular log filtering on firewall logs, the log filter clienttype eq GlobalProtect or clienttype eq Authentication Portal do not work as expected. The query forwards logs of other types that are not included in the filter.
When you configure granular log filtering for Traps logs, the match criteria trapsSeverity eq info does not work.
When using custom filters for log forwarding, verify that you receive logs as expected. If your filter is syntactically correct the LF app will save your filter configuration, but it may not match on logs and will result in no logs being forwarded.
When you configure multiple Syslog receiver and one gets disconnected, you may receive duplicate logs on the receivers that are connected while the LF app attempts to re-establish the connection. Per design all logs are buffered until the connection is restored and will be forwarded when all Syslog receivers are reconnected.
Workaround: Enable the Continue forwarding logs via email if Syslog forwarding is unavailable to avoid halting Syslog forwarding when any connection is down. Enabling email forwarding allows you to receive emails or Syslog notifications in the event a Syslog server gets disconnected and alleviates the issue with duplicate logs on some servers and no logs on other Syslog servers.
Stopping the Syslog receiver does not stop the Log Forwarding app from forwarding logs to it. In this case, you may lose logs.
Workaround: Stop the Log Forwarding app before you stop your Syslog receiver.
If you are using the Log Forwarding app to forward logs to a syslog-ng Syslog receiver, for best results configure the syslog-ng.conf file to use the network() driver instead of the syslog() driver.
If you increase the size of log storage capacity for the Cortex Data Lake instance associated with the Log Forwarding app, the app will start dropping some logs.
Workaround: Stop and Restart the Log Forwarding app.
Currently, the PRI value (PRIVAL) in the syslog header does not reflect the correct severity.
The PAN-OS system subtype field in the forwarded logs sometimes shows the wrong subtype.
For Cortex Data Lake known issues, refer to the Cortex Data Lake Release Notes.

Related Documentation