Graylog not receiving logs from Windows via GELF TCP/UDP – inputs running, but no data received

Hi ,

I’m trying to send logs from a Windows Server 2022 (using NXLog CE) to a Graylog server (Debian 11, Graylog v6.0) using both GELF TCP and GELF UDP.

Setup:

  • Graylog is up and running
  • Inputs are active (GELF TCP and GELF UDP) on various ports (tested with 12201, 5555, 79, and 80)
  • NXLog is installed on the Windows host and the service starts correctly
  • Event logs are generated using eventcreate on Windows
  • NXLog config is based on official examples. Example output block:
<Output out>
    Module om_tcp
    Host    10.X.X.X
    5555
    OutputType GELF
</Output>
  • Also tested with PowerShell GELF message scripts (TCP and UDP) – no messages appear in Graylog

What I’ve confirmed so far:

  • :white_check_mark: Ping from Windows to Graylog server works
  • :cross_mark: Test-NetConnection -Port to Graylog ports (e.g. 12201, 5555) fails
  • :cross_mark: PowerShell UDP message test: no results in Graylog
  • :white_check_mark: GELF Inputs are green and marked as RUNNING in Graylog UI
  • :white_check_mark: When sending test messages locally on the Graylog server using `, messages do appear in Graylog
  • :white_check_mark: ss -tulpen confirms Graylog is listening on the correct ports
  • :cross_mark: Graylog server.log shows nothing when sending from Windows
  • iptables -L shows default policy ACCEPT, but chains include ufw-* rules

Additional info:

  • No local firewalls are enabled on either side
  • I’m not managing the underlying network infrastructure
  • I suspect there’s a switch/router/firewall in between silently dropping TCP/UDP traffic to these ports
  • I don’t see any logs of blocked packets in /var/log/syslog (even using grep UFW or DROP)
  • I haven’t added custom iptables logging rules yet, but can if needed

My question:

Is there any other way I can confirm whether the Graylog server is silently dropping/ignoring incoming TCP/UDP traffic – even though the input is active and listening?

Or is there any tool, trick, or log I can enable that will catch blocked or lost traffic, especially when the input logs remain silent?


Any ideas, tools, or directions would be greatly appreciated – I feel like I’ve tested almost everything.

So to rule out the input being the issue replace it with a RAW TCP/UDP input for now, which will except basically any garbage you throw at it.

But honestly it sounds like a classic networking issue. if you run Test-NetConnection from the windows side and tcpdump on the graylog server, and you see no traffic arrive, then nothing in Windows or Graylog is going to help you, its a network issue…

Considering our working configfile:

“5555” should be “port 5555”
“outputType Gelf” should be “OutputType Gelf_TCP”

First of all, apologies for the late message I just wanted to let you know that I’ve resolved the issue.

Regarding Arie’s response: you were absolutely right. The part I had copied into my post was actually incorrect and didn’t reflect my real configuration — that was a mistake during copying. So the issue mentioned there wasn’t the actual problem in my case.

To keep it short: the root cause turned out to be Debian’s firewall. I had assumed that checking IPTables would show all relevant rules, but that wasn’t the case — the port needed to be explicitly opened.

Big thanks to Joel and Arie for your help!