Troubleshooting Tip: FortiDLP packets is rejected by FortiAnalyzer

Description

This article describes common issues when the FortiDLP webhook is configured to send logs to FortiAnalyzer; however, FortiAnalyzer resets the connection.

Scope

FortiManager with FortiAnalyzer feature enabled, FortiAnalyzer.

Solution

In some particular scenarios, after configuring the FortiDLP webhook according to the Configuring the webhook guide, the connection cannot be established, the FortiDLP device does not appear on the FortiAnalyzer side under Device Manager, and subsequently, logs are not sent/received. Upon checking the packet sniffer, the following can be observed, where:

• In line 1 of the output, FortiDLP connects.

• In line 2 of the output, the data center forwards it to FortiAnalyzer.

• In line 3 of the output, the FortiAnalyzer rejects it.

• In line 4 of the output, the data center returns the RST.
  
  

diagnose sniffer packet any 'host FortiDLP_IP ' 3 

VLAN-10XX in 3X.7X.XXX.XXX -> 172.2X.XXX.XXX:443 syn
VLAN-7XX out 3X.7X.XXX.XXX -> 172.2X.XXX.XXX:443 syn
VLAN-7XX in 172.2X.XXX.XXX -> 3X.7X.XXX.XXX:443 rst
VLAN-10XX out 172.2X.XXX.XXX -> 3X.7X.XXX.XXX:443 rst

As visible from the packet sniffer, FortiDLP was configured to send webhook calls via port 443, which is not correct, and on the FortiDLP side, port 8443 must be used.

The correct URL should be as follows:

https://172.2X.XXX.XXX:8443/fazfec

Knowing the above means that FortiAnalyzer must actively listen on port 8443, and it should be allowed:

diagnose system print netstat
tcp        0      0 :::8443                 :::*                    LISTEN      351/httpd

However, it is not allowed by the internal FortiAnalyzer firewall policy yet:

diagnose system print iptables
-A INPUT -d 0.0.0.0/32 -i port1 -p tcp -m tcp --dport 8443 -j REJECT --reject-with tcp-reset

To allow it, the 'https-logging' should be added to the port configuration:

config system interface 
    edit port1
        set allowaccess https-logging https ssh ping fgfm
end

Now it can be observed that there is no reject/reset issue:

diagnose system print iptables
-A INPUT -d 172.2X.XXX.XXX/32 -i port1 -p tcp -m tcp --dport 8443 -j ACCEPT

diagnose sniffer packet any 'port 8443' 3 0 a
interfaces=[any]
filters=[port 8443]
2026-07-06 07:40:33.434961 3X.7X.XXX.XXX.1712 -> 172.2X.XXX.XXX.8443: syn 4105618757
2026-07-06 07:40:33.435025 172.2X.XXX.XXX.8443 -> 34.7X.XXX.XXX.1712: syn 981929396 ack 4105618758
2026-07-06 07:40:33.456734 3X.7X.XXX.XXX.1712 -> 172.2X.XXX.XXX.8443: ack 981929397