FortiGate syslog arrives but the configured log source receives nothing
A FortiGate 100F sends syslog to a QRadar 7.5 Event Collector on UDP/514. The log source is configured as FortiGate, identifier fortigate-01.corp.local, enabled, with Coalescing Events selected. No events appear in Log Activity for the last 2 hours. tcpdump on the collector shows packets from 10.10.10.1 with payload containing devname=fortigate-01 and type=traffic. Log Source Management shows an auto-discovered SIM Generic source for 10.10.10.1 that is receiving events, but the FortiGate source shows zero. The FortiGate admin cannot change the source IP and will not add a hostname to the syslog header. Compliance needs traffic logs searchable within 15 minutes. The collector is at 9,800 of 10,000 EPS, so no extra EPS budget is available.
1. What is the root cause, and what exact log-source changes do you make?
Read the worked answer
Reasoning: QRadar matches the incoming packet source IP to the log source identifier. The FortiGate source identifier is a hostname, but packets arrive from 10.10.10.1, so QRadar auto-created a SIM Generic source for that IP. The configured FortiGate source receives nothing. Coalescing is not the root cause. Decision: edit the FortiGate log source identifier to 10.10.10.1, or create a new FortiGate source with that identifier and disable the generic source. Ensure type FortiGate, protocol UDP/514, enabled, and deploy. Do not leave both enabled for the same identifier. If the DSM can use devname as an identifier, that is an alternative, but only if QRadar is configured to use it; the packet IP is the reliable match here.
2. How do you handle the existing auto-discovered source and avoid duplicate event history?
Read the worked answer
Use the existing auto-discovered source as the migration path: change its type to FortiGate, set the identifier to 10.10.10.1, rename it, and test. This avoids two enabled sources for the same IP. Historical events already indexed as SIM Generic stay generic; that is acceptable if searches include both types during the transition, or you can document the cutover time. Disable, do not delete, the old FortiGate hostname source until you confirm no traffic. Validate with Log Activity and a 15-minute search.
3. Events now arrive, but some are unparsed. What do you check?
Read the worked answer
Check the raw payload in Log Activity, then verify the FortiGate DSM version and log source type. If the payload is date=... devname=... type=traffic, the DSM should parse it; if not, use DSM Editor Test and compare expected fields. Check that Coalescing Events is not combining identical traffic logs; disable it temporarily to test. Check EPS drop counters and qradar.log for parsing errors. If the DSM expects a different syslog format, create a log source extension or adjust the FortiGate syslog setting; do not create a custom property for every field as a first fix.