Description
This article describes how to handle cases where syslog has been masking some specific types of logs forwarded from FortiGate.
Diagnosis to verify whether the problem is not related to FortiGate configuration is recommended.
Scope
FortiGate.
Solution
Perform packet capture of various generated logs.
Start a sniffer on port 514 and generate various logs:
After, run a capture and issue commands to generate a log sample (output may vary depending on the FortiOS version):
# diagnose log test
generating a system event message with level - warning
generating an infected virus message with level - warning
generating a blocked virus message with level - warning
generating a URL block message with level - warning
generating a DLP message with level - warning
generating an IPS log message
generating an anomaly log message
generating an application control IM message with level - information
generating an IPv6 application control IM message with level - information
generating deep application control logs with level - information
generating an antispam message with level - notification
generating an allowed traffic message with level - notice
generating a multicast traffic message with level - notice
generating a ipv6 traffic message with level - notice
generating a wanopt traffic log message with level - notification
generating a HA event message with level - warning
generating a VOIP event message with level - information
generating authentication event messages
generating a Forticlient message with level - information
generating a URL block message with level - warning
generating a DNS message with level - warning
generating an ssh-command pass log with level - notification
generating an ssh-channel block with level – warning
Verification:
Open the collected capture and check the packet contents to see if they match logs that have been generated.
Note:
Logs are sent to Syslog servers via UDP port 514. Run the following sniffer command on FortiGate CLI to capture the traffic: If the syslog server is configured on the remote side and the traffic is passing over the tunnel.
diagnose sniffer packet any 'udp port 514' 4 0 l
diagnose sniffer packet any 'udp port 514' 6 0 a
diagnose sniffer packet any 'host x.x.x.x and port 514' 4 0 l <- Where x.x.x.x is Syslog Server IP.
diagnose sniffer packet any 'host x.x.x.x and port 514' 6 0 a <- Where x.x.x.x is Syslog Server IP.
Run all these commands in separate CLI console.
If the syslog server is configured on the remote side and the traffic is passing over any IPSEC tunnel, than the route should be configured correctly and the syslog traffic should be routed through the tunnel interface.
In order to confirm the route on the routing table and to troubleshoot the traffic, the below commands can be useful:
get router info routing-table details x.x.x.x <- Where x.x.x.x is syslog IP address.
diag debug reset
diag debug enable
diag debug console timestamp enable
diag debug flow filter addr x.x.x.x <- Where x.x.x.x is the syslog server IP address.
diag debug flow filter port 514
diag debug flow show function-name enable
diag debug flow trace start 1000
To stop the debug:
diagnose debug disable
diagnose debug reset
