FortiGate TCP Syslog Logs completely absent from the Wazuh pipeline

[Ahmed Awwad]

Dear folks,

Here is the full chain 
FortiGate Syslog → HAProxy → Wazuh Server cluster  → Wazuh Indexer
Environment : 

Wazuh Manager: 4.x (master + workers)
Wazuh Indexer: 3-node cluster
Load Balancer HAProxy (TCP passthrough)
Firewall FortiGate sending syslog/514 TCP
Filebeat 7.10.2

FortiGate logs are completely absent from the Wazuh pipeline. No entries in:
/var/ossec/logs/archives/archives.json
/var/ossec/logs/archives/archives.log
Wazuh Dashboard (Security Events, FortiGate dashboards)
wazuh-archives-* indices
Stages Check:

• Packets reach HAProxy : tcpdump -A port 514 on LB
  result: ✅ FortiGate payload visible
• Packets reach Wazuh Manager : tcpdump -A port 514 on Manager
  result: ✅ Payload visible, source = HAProxy IP
  
• <allowed-ips> configured at  <remote> of ossec.conf with LB IP
  
• All Logs allowed at  ossec.conf and enabled archive at Filebeat.
• No logs related at alerts.json / alerts.log /archives.json / archives.log   all are empty for FortiGate.
• Sample log had been tested and decoder is matched 
  "**Phase 2: Completed decoding.
   name: 'fortigate-firewall-v5'"
• I had testing with logger from wazuh Manager node via "logger -t TESTTRACE "WAZUH_TRACE_TEST_12345 source_ip=192.168.1.99 user=traceuser action=login""
  and curl the indexer for the log and here is the output
   curl -k -u admin:'Password' -XGET "https://<Indexer01-IP:9200/wazuh-archives-*/_search?pretty" -H 'Content-Type: application/json' -d '
  {
    "query": {
      "match": {
        "full_log": "WAZUH_TRACE_TEST_12345"
      }
    }
  }'
  {
    "took" : 6,
    "timed_out" : false,
    "_shards" : {
      "total" : 6,
      "successful" : 6,
      "skipped" : 0,
      "failed" : 0
    },
    "hits" : {
      "total" : {
        "value" : 2,
        "relation" : "eq"
      },
      "max_score" : 9.714336,
      "hits" : [
        {
          "_index" : "wazuh-archives-4.x-2026.07.21",
          "_id" : "wq5VhJ8BBqTv_n_IF8i8",
          "_score" : 9.714336,
          "_source" : {
            "predecoder" : {
              "hostname" : "wazuh-master",
              "program_name" : "TESTTRACE",
              "timestamp" : "Jul 21 10:59:50"
            },
            "cluster" : {
              "node" : "wazuh-master",
              "name" : "wazuh_cluster"
            },
            "agent" : {
              "name" : "wazuh-master",
              "id" : "000"
            },
            "manager" : {
              "name" : "wazuh-master"
            },
            "decoder" : { },
            "full_log" : "Jul 21 10:59:50 wazuh-master TESTTRACE[1401074]: WAZUH_TRACE_TEST_12345 source_ip=192.168.1.99 user=traceuser action=login",
            "input" : {
              "type" : "log"
            },
            "@timestamp" : "2026-07-21T10:59:51.633Z",
            "location" : "journald",
            "id" : "1784631591.26529",
            "timestamp" : "2026-07-21T10:59:51.633+0000"
          }
        },
        {
          "_index" : "wazuh-archives-4.x-2026.07.21",
          "_id" : "w65VhJ8BBqTv_n_IF8i8",
          "_score" : 9.714336,
          "_source" : {
            "predecoder" : {
              "hostname" : "wazuh-master",
              "program_name" : "TESTTRACE",
              "timestamp" : "Jul 21 10:59:52"
            },
            "cluster" : {
              "node" : "wazuh-master",
              "name" : "wazuh_cluster"
            },
            "agent" : {
              "name" : "wazuh-master",
              "id" : "000"
            },
            "manager" : {
              "name" : "wazuh-master"
            },
            "decoder" : { },
            "full_log" : "Jul 21 10:59:52 wazuh-master TESTTRACE[1401087]: WAZUH_TRACE_TEST_12345 source_ip=192.168.1.99 user=traceuser action=login",
            "input" : {
              "type" : "log"
            },
            "@timestamp" : "2026-07-21T10:59:53.634Z",
            "location" : "journald",
            "id" : "1784631593.26529",
            "timestamp" : "2026-07-21T10:59:53.634+0000"
          }
        }
      ]
    }
  }
  But i can't find this testing log at the GUI (Discovery >wazuh.archives-.* Index)

Cluster status attached to the thread
kindly how i can address the root cause of the issue as i don't see any raised errors at any of /var/ossec/logs/ossec.log or /var/log/filebeat/filebeat
or may a certain mis configuration or option not enabled on the dashboard?

[Olamilekan Abdullateef Ajani]

Hello,

Two issues i have highlighted from what you have shared, the fortiGate logs are not being captured by Wazuh and the test log is indexed but not visible in the GUI.

Since nothing appears in archives.log or archives.json based on what you have shared, this is not a decoder or rule problem yet. The log has not reached Analysisd. tcpdump only proves the packets reached the network interface, it does not prove wazuh-remoted accepted them.

Please check the Wazuh node that HAProxy is forwarding to:
ss -tlnp | grep ':514'
cat /var/ossec/logs/ossec.log | grep -Ei "remoted|syslog|514|allowed|denied"

Also confirm the <remote> block exists on every worker that can receive traffic from HAProxy:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips>HA-PROXY-IP</allowed-ips>
</remote>

You need to explicitly define the protocol as TCP so it does not parse TCP over UDP.

Now do a test through the HAProxy IP or even on the Wazuh manager nodes with a sample syslog message:

printf '<134>Jul 21 12:00:00 fgt-test msg="PROD_DIRECT_MASTER"\n' | nc -v -q1 <MASTER_IP> 514
printf '<134>Jul 21 12:00:00 fgt-test msg="PROD_DIRECT_W1"\n' | nc -v -q1 <WORKER1_IP> 514

grep PROD_DIRECT /var/ossec/logs/archives/archives.json

First check ss -tlnp | grep ':514' on every node, make sure the remote block is also active and configured as described above.

Do same on HA proxy too: printf '<134>Jul 21 12:00:00 fgt-test msg="PROD_VIA_LB"\n' | nc -v -q1 <HAPROXY_VIP> 514

If this test appears in archives, Wazuh and HAProxy are okay, you then need to check the FortiGate TCP syslog format/framing. If it does not appear, then we need to look at Wazuh <remote> config, HAProxy backend, allowed IP, or listener.

Sample from my side:
root@waz:/# ss -tlnp | grep ':514'
LISTEN 0      128               0.0.0.0:514        0.0.0.0:*    users:(("wazuh-remoted",pid=159617,fd=4))
root@waz:/# printf '<134>Jul 21 12:00:00 fgt-test date=2026-07-21 msg="WAZUH_NC_TEST_999"\n' | nc -q1 192.168.140.131 514
root@waz:/# printf '<134>Jul 21 12:00:00 fgt-test date=2026-07-21 msg="WAZUH_NC_TEST_999"\n' | nc -v -q1 192.168.140.131 514
Connection to 192.168.140.131 514 port [tcp/shell] succeeded!
root@waz:/# grep WAZUH_NC_TEST_999 /var/ossec/logs/archives/archives.json
{"timestamp":"2026-07-21T15:10:36.976+0000","agent":{"id":"000","name":"waz"},"manager":{"name":"waz"},"id":"1784646636.468921","full_log":"Jul 21 12:00:00 fgt-test date=2026-07-21 msg=\"WAZUH_NC_TEST_999\"","predecoder":{"timestamp":"Jul 21 12:00:00","hostname":"fgt-test"},"decoder":{},"location":"192.168.140.131"}
{"timestamp":"2026-07-21T15:10:49.447+0000","agent":{"id":"000","name":"waz"},"manager":{"name":"waz"},"id":"1784646649.468921","full_log":"Jul 21 12:00:00 fgt-test date=2026-07-21 msg=\"WAZUH_NC_TEST_999\"","predecoder":{"timestamp":"Jul 21 12:00:00","hostname":"fgt-test"},"decoder":{},"location":"192.168.140.131"}
root@waz:/#


Please let me know what you find. 

[Ahmed Awwad]

for  Check 514 Port on wazuh 3 Nodes 

root@wazuh-master:~# ss -tlnp | grep ':514'
LISTEN 0      128    < wazuh-master  -IP>:514        0.0.0.0:*    users:(("wazuh-remoted",pid=1404432,fd=4))
root@wazuh-server-01:~# ss -tlnp | grep ':514'
LISTEN 0      128     < wazuh-server-01  -IP>  :514        0.0.0.0:*    users:(("wazuh-remoted",pid=875537,fd=4))

root@wazuh-server-02:~# ss -tlnp | grep ':514'
LISTEN 0      128    < wazuh-server-02 -IP >:514        0.0.0.0:*    users:(("wazuh-remoted",pid=1075966,fd=4))

root@wazuh-loadbalancer:~#  printf '<134>Jul 21 12:00:00 fgt-test msg="PROD_VIA_LB"\n' | nc -v -q1  <HAPROXY_VIP>  514
Connection to 10.101.101.176 514 port [tcp/shell] succeeded!

printf '<134>Jul 21 12:00:00 fgt-test msg="PROD_VIA_LB"\n' | nc -v -q1 <HAPROXY_VIP> 514

Successfully appeared on master node as following :

root@wazuh-master:~# tail -f /var/ossec/logs/archives/archives.log
udp 127.0.0.54:53 0.0.0.0:* 436920/systemd-reso
tcp  < wazuh-master  -IP>  :514 0.0.0.0:* 1404432/wazuh-remot
tcp 0.0.0.0:1514 0.0.0.0:* 1404431/wazuh-remot
tcp 0.0.0.0:1515 0.0.0.0:* 1404336/wazuh-authd
tcp 0.0.0.0:1516 0.0.0.0:* 1405692/python3
tcp 127.0.0.1:6010 0.0.0.0:* 1429207/sshd
tcp6 ::1:6010 :::* 1429207/sshd
tcp 0.0.0.0:55000 0.0.0.0:* 1404287/python3
tcp6 :::55000 :::* 1404287/python3
2026 Jul 22 10:22:19 fgt-test-> <HAPROXY_VIP>  Jul 21 12:00:00 fgt-test msg="PROD_VIA_LB"

root@wazuh-master:~#  grep PROD_VIA_LB /var/ossec/logs/archives/archives.json
{"timestamp":"2026-07-22T10:22:19.531+0000","agent":{"id":"000","name":"wazuh-master"},"manager":{"name":"wazuh-master"},"id":"1784715739.8555","cluster":{"name":"wazuh_cluster","node":"wazuh-master"},"full_log":"Jul 21 12:00:00 fgt-test msg=\"PROD_VIA_LB\"","predecoder":{"timestamp":"Jul 21 12:00:00","hostname":"fgt-test"},"decoder":{},"location":" <HAPROXY_VIP>"}

[Olamilekan Abdullateef Ajani]

Hello,

Thanks for the update. Since the nc message sent through the HAProxy VIP appeared in archives.log and archives.json, it confirms that side is working:

HAProxy VIP > Wazuh TCP 514 > wazuh-remoted > analysisd > archives

It also confirms that the Wazuh <remote> block, TCP listener, allowed-ips, and archive writing are working for a normal newline-based syslog message.

The next thing to check is the actual format/framing of the FortiGate TCP syslog traffic.

Please capture real FortiGate traffic on the Wazuh node that is receiving the connection:

ss -tnp | grep ':514'

Then run:

tcpdump -i any -s0 -XX -nn 'tcp port 514 and host <HAPROXY_IP>' -c 30

What we need to confirm is whether the FortiGate message is being sent as a normal newline-terminated syslog message, like:

<189>date=2026-07-22 ...

or whether it is using TCP octet-counted framing, like:

123 <189>date=2026-07-22 ...

If the real FortiGate traffic has a length prefix before the syslog priority, Wazuh may not split/process it correctly, even though tcpdump shows the payload arriving.

Also check the FortiGate syslog settings too:

show full-configuration log syslogd setting
show full-configuration log syslogd filter
diagnose log test

Things to confirm:

Syslog is enabled.
The severity/filter is not excluding the events.
The format being used by FortiGate.
Whether it is sending TCP, UDP, or TLS.
Whether new logs are actually being generated during the test.

Since the manual nc test works through HAProxy, my main suspicion is either the FortiGate TCP syslog framing/format or FortiGate filtering, not Wazuh side atall.

Please let me know what you find.