I need to secure Syslog sending from Palo devices to SolarWinds Kiwi Syslog server using SSL. We're currently sending Syslog to the Kiwi Server over UDP successfully without issue. However, when I changed the transport to SSL (6514) and set the certificate to use for Syslog, the firewall stopped sending logs to the Kiwi server.
I followed the steps outlined here (Configure Syslog Monitoring (paloaltonetworks.com)). I created two self-signed certificates on the firewall, I assigned one to be used for Syslog sending, and exported the second to the Kiwi server.
I did a tcpdump capture on the firewall, it appears it stopped sending syslog messages after the change.
I'll appreciate comments on what I need to do to resolve this issue.
I would start with the trivial thinks to check:
- Does the communication between FW and syslog server pass through any FW? Does it pass over the FW that generates the syslog?
- Are you using the dedicated mgmt interface of the firewall or dataplane with service route?
- (I don't have experience with Kiwi syslog, but) From your screenshot it looks like you have defined what server certificate will Kiwi use to authenticate itself to the FW. But where are you defining which CA Kiwi will use to verify the client certificate that FW will use to authenticate to the server?
- From the link you mentioned there is one key point:
The connection to a Syslog server over TLS is validated using the Online Certificate Status Protocol (OCSP) or using Certificate Revocation Lists (CRL) so long as each certificate in the trust chain specifies one or both of these extensions. However, you cannot bypass OCSP or CRL failures so you must ensure that the certificate chain is valid and that you can verify each certificate using OCSP or CRL.
From your screenshot it is not clear if you are using self-signed CA to internal PKI. In case of internal PKI, can you confirm that FW and Kiwi can reach the internal CRL?
- In any case I would expect your packet capture to catch at least some TCP SYNs from FW to the syslog. If you are using the dedicate mgmt interface try to capture any traffic (limiting the noise from your ssh session):
> tcpdump filter 'not port 22'
This should tell you if FW is not failing something else (DNS or CRL)
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!