Troubleshooting Tip: Sending FortiClient Logs to On-Prem FortiAnalyzer

Useful facts:

• FortiClient sends logs directly to FortiAnalyzer:
• TCP 514 for Windows, macOS and Linux endpoints.
• TCP 8443 for Chromebooks (ChromeOS)
• Log delivery depends on network connectivity from the endpoint to FortiAnalyzer, not from EMS. Firewall rules, routing, and NAT between the endpoint and FortiAnalyzer directly affect log delivery.

• EMS does not proxy or relay logs. Its role is limited to:
• Pushing the FortiAnalyzer IP/FQDN
• Delivering logging configuration and profiles to FortiClient
• Once deployed, FortiClient communicates directly with FortiAnalyzer.
• There is no functional difference between using on-premises EMS or EMS Cloud in this context. As long as FortiClient successfully receives the FortiAnalyzer configuration, it will be able to send logs to FortiAnalyzer as expected.

• Log Retention:
• If FortiClient is temporarily unable to connect to FortiAnalyzer, events are stored locally on the endpoint.
• Once connectivity to FortiAnalyzer is restored, FortiClient will automatically resume sending logs.

• Syslog Server (non-FortiAnalyzer):
• When using a third-party syslog server instead of FortiAnalyzer, FortiClient supports UDP port 514 only.
• TCP and TLS are not supported for third-party syslog servers.
• Log retention is not supported in this mode. If connectivity to the syslog server is unavailable, logs are not buffered or stored locally.
• Need to configure the syslog as a remote server type in XML:<log_protocol>syslog</log_protocol>

Common causes of not receiving logs from clients:

• Third-party applications installed on the endpoint that may interfere with log transmission.

• FortiClient misconfiguration on the endpoint.

• Network connectivity issues between the endpoint and the logging server.

• Known product issues affecting log forwarding.

The following topology will be used to validate the configuration and conduct network connectivity testing and debugging on FortiAnalyzer.

Troubleshooting steps:

1. Ensure FortiClient has the correct configuration:
   1. Verify which policy being used by the endpoint and what the Status is (on-fabric or off-fabric)
   2. Locate the policy and find out which System Settings profile is assigned to the PC
   3. Edit the corresponding profile ensure the correct FortiAnalyzer IP/FQDN is assigned for the option 'Upload Logs to FortiAnalyzer/FortiManager'.
   4. For the troubleshooting purpose, isolate a test PC by creating a new test group under Workgroup or Domain in EMS -> Move the test PC under this new group -> Create a new policy and assign the newly created group -> Create a default enabled web filter profile -> Clone the current in-production System Settings profile -> Assign both profiles to the new policy -> Make the following changes under the cloned (test) System Settings profile: 
      1. Set the Log Level to Debug and enable the 'DBLog' checkbox.
      2. Enable only the options SSL Enabled, Upload UTM Logs and Upload Security Event, and turn off the rest.
      3. Set Upload Schedule to one minute and Log Generation Timeout to 60 seconds to trigger faster log generation on the client side.

2. Check the connectivity on the endpoint side.
   1. Run the command tnc -P 514 <FortiAnalyzer IP or FQDN> in the elevated PowerShell to ensure FortiClient can reach FortiAnalyzer over port 514 TCP successfully. If using an FQDN for FortiAnalyzer address, ensure the FQDN can be resolved by the endpoint's DNS.

tnc -P 514 faz.mydomain.com

2. Wireshark capture: Open Wireshark -> select the outgoing interface to the internet (e.g W-Fi) -> type host [FortiAnalyzer public IP] and port 514 -> double-click on the interface -> generate some logs by browsing a few unallowed websites such as guns.com, gambling.com, 777.com, wine-searcher.com, modelmayhem.com, match.com, or hitimes.com -> ensure the outgoing traffic has been seen in Wireshark -> wait for a minute -> Ensure that TCP packets over port 514 can be observed being exchanged between the client and the FortiAnalyzer.

3. Navigate under the C:\Program Files\Fortinet\FortiClient\logs\ folder and verify if any file named securityevent*.log created. If this file is seen, it means FortiClient can’t reach FortiAnalyzer and is doing log retention to store logs locally until FortiAnalyzer becomes reachable again. Open this file and see the content of stored logs.
   

3. Check the client-side logs and their meaning. Navigate under the C:\Program Files\Fortinet\FortiClient\logs\ogs\trace\ folder and find the file fcdblog_1.log.
   
   

Successful logs show as follows:

[2026-01-02 21:52:25.0383937 UTC-07:00] [3312:3724] [fcdblog  244   debug] adding upload request to list, file_type=16, filepath=C:\Program Files\Fortinet\FortiClient\logs\securityevent1767419539.log

[2026-01-02 21:52:25.0387171 UTC-07:00] [3312:12976] [fcdblog  833   debug] uploading files to FAZ, m_upldRequests.size=1

[2026-01-02 21:52:25.0387991 UTC-07:00] [3312:12976] [fcdblog  564   debug] uploading log file to FAZ, file_type = 16, number of files: 1

[2026-01-02 21:52:25.0388725 UTC-07:00] [3312:12976] [fcdblog  94    info] oftp connect, ip=0x0xd8005610, port=514

[2026-01-02 21:52:25.0409001 UTC-07:00] [3312:12976] [fcdblog  126   debug] ssl set host name=203.0.113.10 ret=1

[2026-01-02 21:52:25.0538518 UTC-07:00] [3312:12976] [fcdblog  165    info] ssl_connect wantread/write

[2026-01-02 21:52:27.0652836 UTC-07:00] [3312:3704] [fcdblog  609   debug] EDR Pipe connect failed: 2

[2026-01-02 21:52:27.0674252 UTC-07:00] [3312:12976] [fcdblog  209    info] oftp connect returned 0

[2026-01-02 21:52:27.0911244 UTC-07:00] [3312:12976] [fcdblog  1101    info] found want read/write 2

[2026-01-02 21:52:27.2273594 UTC-07:00] [3312:12976] [fcdblog  825   debug] uploading log file to FAZ, returning 0, dwUploaded=1

[2026-01-02 21:52:27.2273673 UTC-07:00] [3312:12976] [fcdblog  902   debug] returning 0

Unsuccessful log when FortiAnalyzer IP/FQDN is not reachable or not valid:

[2025-01-30 12:25:03.9512273 UTC-03:00] [9992:13740] [fcdblog  181   error] select timeout

[2025-01-30 12:25:03.9520928 UTC-03:00] [9992:13740] [fcdblog  209    info] oftp connect returned -14

[2025-01-30 12:25:03.9525722 UTC-03:00] [9992:13740] [fcdblog  574   error] failed to connect to FAZ server! oftp_forticlient_connect() returned -115, err=0, oftp_err=10

[2025-01-30 12:25:03.9528623 UTC-03:00] [9992:13740] [fcdblog  822   debug] uploading log file to FAZ, returning 3, dwUploaded=0

[2025-01-30 12:25:03.9528780 UTC-03:00] [9992:13740] [fcdblog  893   debug] returning 3

Unsuccessful log when a third-party security application intervenes in the traffic:

[2025-11-18 12:02:26.3706615 UTC-04:00] [12704:20852] [fcdblog debug 561] uploading log file to FAZ, file_type = 16, number of files: 1

[2025-11-18 12:02:26.3708371 UTC-04:00] [12704:20852] [fcdblog info 94] oftp connect, ip=0x0xd8005610, port=514

[2025-11-18 12:02:26.3728371 UTC-04:00] [12704:20852] [fcdblog debug 126] ssl set host name=203.0.113.10 ret=1

[2025-11-18 12:02:26.4690821 UTC-04:00] [12704:20852] [fcdblog info 165] ssl_connect wantread/write

[2025-11-18 12:02:28.4923423 UTC-04:00] [12704:20852] [fcdblog info 209] oftp connect returned 0

[2025-11-18 12:02:28.5956163 UTC-04:00] [12704:20852] [fcdblog info 1101] found want read/write 2

[2025-11-18 12:02:28.6976424 UTC-04:00] [12704:20852] [fcdblog error 633] oftp_recv_ack() failed, ret = -15, err = 0, ack=15

[2025-11-18 12:02:28.6990338 UTC-04:00] [12704:20852] [fcdblog debug 822] uploading log file to FAZ, returning 0, dwUploaded=0

[2025-11-18 12:02:28.6990446 UTC-04:00] [12704:20852] [fcdblog debug 893] returning 0

The [fcdblog error 633] oftp_recv_ack() failed error above typically indicates that a local component on the machine is interfering with FortiClient's traffic - even though it can be seen that some packets are still being delivered to FortiAnalyzer. In most situations, this type of behavior is caused by a third-party security application intercepting, modifying, or filtering the traffic.

To rule out interference from third-party programs, temporarily uninstall all third-party security applications and ensure all associated services are stopped (confirm it under msconfig -> Services). It is also recommended to temporarily disable Windows Defender and Windows Firewall during the troubleshooting. Once the culprit app detected, must whitelist the FortiClient FCDBLog.exe process along with all other FortiClient processes in those apps to allow sending logs.

4. FortiAnalyzer side troubleshooting:
   1. Ensure the EMS serial number is added under FortiAnalyzer -> Device Manager. The EMS SN can be added manually, and there is no need to establish a Fabric Connector between EMS and FortiAnalyzer. The red circle indicator is expected behavior when the EMS server itself is not sending any logs to FortiAnalyzer.
      

4. 2. To verify the connectivity, if the firewall is not using NAT between the internet and FortiAnalyzer, run the below command to verify if the traffic from the endpoint with public IP 207.102.134.36 reaches FortiAnalyzer over port 514:

diagnose sniffer packet any "host 207.102.134.36 and port 514" 4 0 l

4. 3. To observe web filter logs, first run the commands below in the FortiAnalyzer console:

diagnose debug reset diagnose debug disable diagnose debug application oftpd 8 207.102.134.36 diagnose test application fortilogd 5 FCTEMS8825003905 diagnose debug enable

207.102.134.36 is the PC's public IP.
FCTEMS8825003905 is the FortiClient EMS serial number.

Then, generate some logs by browsing a few unallowed websites such as guns.com or gambling.com:


Wait for a few moments. The blocked URLs should show up in the FortiAnalyzer console output:


Navigate to FortiAnalyzer -> Log View -> Logs -> Select FortiClient -> Select Traffic or Security Events -> observe web filter events that happened on the endpoint:

Some other useful commands to verify FortiClient logs received by FortiAnalyzer:

diagnose test application oftpd 43 show diagnose test application oftpd 3 diagnose test application oftpd 4