No logs arriving: step-by-step checklist

safe intermediate #troubleshoot#tcpdump#firewall#no logs#port 514

When to use this: The device says syslog is configured, but nothing appears on the server.

Before you start

Steps

  1. 1. Is the server listening?

    terminal
    sudo ss -lunp | grep ':514'
    sudo ss -ltnp | grep ':514'

    You should see rsyslogd (or your collector) on the port. If not, fix the service first: sudo rsyslogd -N1 and journalctl -u rsyslog -n 50.

  2. 2. Does traffic reach the server?

    terminal
    sudo tcpdump -ni any port 514

    Leave it running while the device generates logs. Packets from the device mean the network path is fine and the problem is in the server's rules. No packets means the problem is firewall, routing or the device.

  3. 3. Is the server firewall blocking?

    terminal
    sudo ufw status
    sudo iptables -L -n | head -30

    Allow the sender's IP on the right protocol (see the ports scenario).

  4. 4. Is the device actually sending?

    terminal
    diagnose sniffer packet any 'host 192.168.1.10 and port 514' 4 0 l

    On a FortiGate. Replace the IP with the server. No packets: check show log syslogd setting, source IP and routing, and that logging is enabled on policies.

  5. 5. Is it being written to disk?

    terminal
    ls -la /var/log/remote/
    journalctl -u rsyslog -n 50

    Packets arrive but no file appears: the rsyslog rule does not match the sender, a permission error prevents file creation, or the disk is full (df -h).

  6. 6. Test end to end from a known sender

    terminal
    logger -n 192.168.1.10 -P 514 -d "test"

    If this works but the device does not, the server is fine and the device's configuration or path is wrong.

How to verify it worked

  • New lines from the device appear in the sender's folder.

Common errors and fixes

Packets arrive from an unexpected IP NAT or another outgoing interface. Adjust the device's source IP or your allow-list and folder logic.
TCP sender connects but nothing is stored Framing mismatch is rare but possible. Compare with a test using logger -T (TCP) from Linux.
Worked before, stopped suddenly Check df -h (disk full), a changed IP on either side, an expired firewall rule, or a service that crashed after an update.

Q&A

What is the quickest proof that data reaches the server?

sudo tcpdump -ni any port 514 on the server. If you see packets from the device, the network works.

Packets reach the server but no file is created. Why?

The rsyslog rule, file permissions or disk space. Check journalctl -u rsyslog and df -h.

Which tool shows what ports are listening?

ss -lunp for UDP and ss -ltnp for TCP on Linux, netstat -ano on Windows.

Practice these as flashcards →

Terms in this scenario

Related scenarios

My notes

Saved in this browser only.