GUIDE — 2026-09-13

FortiGate syslog to a server: complete setup

The smaller FortiGate models have no log disk. A 40F or 60F logs to memory, which means a few thousand lines and nothing at all after a reboot. Even on units with a disk, the retention is short once traffic logging is on. Sending syslog to a machine you control fixes both.

Which machine receives the logs? SyslogWatch is the same application on macOS, Windows 10/11, Windows Server 2016 or newer, and 64-bit Linux, and it listens on the same port everywhere. Most people run it on a server; on a Linux server without a desktop it runs in headless mode, with the screen in your browser. Where a command below differs by platform, all three are given.

What this covers

FortiOS 7.0 through 7.6, on any model. The CLI is the same across them; the GUI moved once and both paths are given.

Before you start — the receiver's address

The device needs somewhere to send to, and that address must not change:

• macOS — ifconfig en0 | grep inet
• Windows — ipconfig | findstr IPv4
• Linux — ip -4 addr show

Give that machine a static address or a DHCP reservation. If it moves, the device keeps sending to the old address and never tells you. Silence looks the same as "nothing happened".

Step 1 — Configure the syslog server (CLI)

This is the shorter road and it is the same on every model:

config log syslogd setting
    set status enable
    set server "192.0.2.10"
    set port 1514
    set mode udp
    set facility local7
    set format default
end

A few of these are worth understanding rather than pasting:

• set port 1514 — the default is 514. SyslogWatch listens on 1514 so it can start without administrator rights.
• set format default — key=value pairs, which is what FortiGate documents and what parsers expect. cef and rfc5424 exist; pick one and do not change it later, because anything you built on the old shape stops matching.
• set facility local7 — any facility works. Use a distinct one if the same receiver also takes logs from other kinds of device; then you can tell them apart without matching on hostnames.

Step 2 — Decide what gets sent

Without a filter, a busy FortiGate will send every traffic session to the receiver. That is a lot, and most of it is not interesting:

config log syslogd filter
    set severity information
    set forward-traffic enable
    set local-traffic disable
    set sniffer-traffic disable
end

Start with forward-traffic on and the rest off. If the volume is still too high, raise the severity to warning and turn forward-traffic off — you then get events (admin logins, VPN, IPS, antivirus) without a line per session.

If VDOMs are enabled this configuration is per-VDOM, and setting it in one VDOM does nothing for the others. Enter each one — config vdom then edit <name> — and repeat. This is the single most common reason "it works for some traffic and not others".

Step 3 — Pin the source address

If the FortiGate has several interfaces that could reach the receiver, pin which one it uses so the device always appears under one address:

config log syslogd setting
    set source-ip "192.0.2.1"
end

The GUI path

If you would rather not use the CLI: Log & Report → Log Settings, then Send Logs to Syslog. Enter the address, and open Advanced to set the port — the field is hidden until you do, which is why people end up sending to 514 without meaning to. On FortiOS 7.4 and later the same screen is under System → Log Settings on some builds.

Open the port on the receiver

Most systems drop incoming UDP by default. SyslogWatch listens on 1514 rather than the privileged port 514, so it starts without administrator rights — but the firewall still has to let the traffic in.

• macOS — the firewall asks on first launch. Click Allow.
• Windows — New-NetFirewallRule -DisplayName "SyslogWatch 1514" -Direction Inbound -LocalPort 1514 -Protocol UDP -Action Allow
• Linux — sudo ufw allow 1514/udp, or on Fedora and RHEL sudo firewall-cmd --add-port=1514/udp --permanent && sudo firewall-cmd --reload

Step 4 — Check it

FortiGate can send a test line itself:

diagnose log test

That generates one message of each type. Several lines should appear in SyslogWatch within a second or two.

If they do not, watch the FortiGate's own interface to see whether the packets are leaving:

diagnose sniffer packet any 'udp port 1514' 4

Packets leaving but nothing arriving means the path or the receiver's firewall. Nothing leaving means the configuration — most often a VDOM you did not configure, or status left disabled.

If nothing arrives

Work out which side is at fault before changing anything on the device. Send a syslog line to the receiver from the receiver itself:

logger -n 127.0.0.1 -P 1514 -d -p local0.err "test from the receiver"

If that line appears in SyslogWatch, the application and the port are fine and the problem is on the device or in the path — a firewall rule, a wrong address, or a VLAN that cannot reach the receiver. If it does not appear, the problem is on the receiving machine.

To see whether packets are arriving at all:

• macOS / Linux — sudo tcpdump -n -i any udp port 1514
• Windows — netstat -an | findstr 1514 shows the listener; use Wireshark to see traffic

What is worth alerting on

• Administrator login failures, and any login from an address you do not recognise.
• Configuration changes — FortiGate logs who changed what, which is half of most incident timelines.
• IPSec or SSL-VPN tunnels going down and coming back repeatedly.
• High availability failover. If your cluster failed over at 03:00 and nobody knew, you have a single unit and do not know it.
• Antivirus and IPS detections, if you run those profiles.

One thing that catches people

Traffic logging is expensive on the FortiGate, not just on the receiver. On a small unit with a lot of sessions, logging every forwarded session costs CPU. If throughput drops after you turn syslog on, that is the cause — filter harder rather than turning it off entirely, because event logs are cheap and are the ones you want at 3am.

Getting SyslogWatch

Download SyslogWatch — free tier, no sign-up, no account, no card. macOS, Windows and Linux. Everything it receives is written to disk on that machine; nothing is sent anywhere else.