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.
It is important to note that logs are sent over UDP, not TCP. Sometimes on the FortiGate, the syslog settings are configured to send the traffic over TCP. Make sure the configuration on the FortiGate is correct and make the appropriate changes as suggested below.
config log syslogd setting
set status enable
set mode udp
end
Run all these commands in a 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.
To confirm the route on the routing table and to troubleshoot the traffic, the following commands can be useful:
get router info routing-table details x.x.x.x <- Where x.x.x.x is syslog IP address.
diagnose debug reset
diagnose debug enable
diagnose debug console timestamp enable
diagnose debug flow filter addr x.x.x.x <----- Where x.x.x.x is the syslog server IP address.
diagnose debug flow filter port 514
diagnose debug flow show function-name enable
diagnose debug flow trace start 1000
To stop the debug:
diagnose debug disable
diagnose debug reset
Related article:
Technical Tip: Logs generated while using the 'diagnose log test' command
