SonicWall firewalls generate a great deal of log data and keep almost none of it. The appliance holds a small rolling buffer in memory, so by the time anyone asks what happened three days ago, the answer is usually gone. A syslog server is how you keep it: the firewall streams every event over UDP to a machine you control, and that machine writes it to disk.
What follows covers the realistic options, from a free tool that writes plain text files through to full SIEM platforms, plus the SonicWall-side configuration that catches most people out.
Decide what you actually need first
There are three genuinely different jobs here, and picking a tool for the wrong one is the usual mistake.
- Retention. You need the logs kept somewhere for compliance or for the occasional investigation. Plain text files are fine. This is the cheapest problem to solve.
- Search and reporting. You need to answer “which internal host talked to that IP last Tuesday” in under a minute. You need indexing, which means a real log platform.
- Alerting and correlation. You need to be told when something matters, without reading anything. That is a SIEM, and it is a considerably larger commitment in both money and time.
Most small networks need the first, think they need the third, and are best served by starting with the second.
Free and low-cost options
Fastvue Syslog
The simplest thing that works on Windows. It listens on UDP 514, writes incoming messages to text files, and compresses and archives them after a configurable period (30 days by default). It can also forward the stream on to another collector, which makes it useful as a lightweight relay even if you later add something bigger. No indexing, no search beyond what your text editor can do — but it is free, it installs in minutes, and it solves the retention problem completely.
Rsyslog or syslog-ng
The Linux standard, and almost certainly already installed on any Linux box you own. Both will accept the SonicWall stream, write it to a file per source host, rotate it and compress it, for the cost of a short configuration file. If you already run a Linux server, this is the lowest-effort option of all — and the output is ordinary text, so you can point anything at it later.
Graylog Open
The obvious step up when text files stop being enough. Graylog is genuinely free and open source, it indexes everything so search is fast, and it handles the SonicWall message format without much coaxing. The cost is operational: it runs on top of OpenSearch and MongoDB, so you are maintaining three services rather than one, and it wants real memory. For a small IT team that is comfortable with Linux, it is the best value on this page.
Splunk Free
Splunk’s free tier indexes up to 500 MB per day, which is more than most single-firewall sites produce, and the search language is the best in this class by a wide margin. The catches are real, though: the free tier has no alerting, no authentication and no scheduled reports, so it is a search tool rather than a monitoring one. Exceed 500 MB a day too often and indexing stops until you license it.
Elastic Stack
Elasticsearch with Filebeat or Logstash collecting the syslog stream, and Kibana on top for dashboards. Powerful, free at the basic tier, and there are existing SonicWall parsing configurations to start from. Like Graylog, the real cost is running it — Elasticsearch is a demanding service to keep healthy and it will absorb as much disk and memory as you give it.
Grafana Loki
The newer, lighter alternative to indexing everything. Loki indexes only labels and stores the log bodies compressed, which makes it dramatically cheaper to run than Elasticsearch at the cost of slower full-text searching. If you already run Grafana for metrics, adding Loki keeps your logs and your graphs in one interface, which is worth a lot in practice.
Commercial tools with a free tier
ManageEngine EventLog Analyzer
Ships with out-of-the-box SonicWall support, which is the selling point — the parsing, the dashboards and the reports exist before you do anything. The free edition covers up to five log sources, so a single firewall plus a few servers fits comfortably. It is the fastest route from nothing to useful SonicWall reports, and the free tier is a genuine product rather than a time-limited trial.
Kiwi Syslog Server
The long-standing Windows syslog collector. The free edition handles a small number of devices and does the basics well: receive, filter, write to file or database, and trigger simple actions on matching messages. Straightforward, well documented, and unambitious in a way that is often exactly right.
PRTG Network Monitor
Worth mentioning only if you already run PRTG for monitoring. Its syslog receiver sensor collects and filters messages alongside your existing device monitoring, which avoids running a second platform. It is not a serious log-analysis tool, but for alerting on specific firewall messages next to your uptime graphs, it is convenient.
Wazuh
Free, open source, and a genuine SIEM rather than a log collector — rule-based alerting, file integrity monitoring and compliance reporting included. It will take SonicWall syslog and apply detection rules to it. Set aside real time for tuning: an untuned SIEM produces alerts nobody reads, which is worse than no SIEM.
SonicWall’s own Analytics
The vendor’s platform, which understands the message format completely because it wrote it, and offers reporting built around SonicWall’s own feature set. Licensed per appliance and considerably more expensive than the free options. The argument for it is that it needs no parsing work and it will not break when a firmware update changes a log format — which is a more common annoyance than it sounds.
Configuring the SonicWall side
Under Device → Log → Syslog (the path varies a little by firmware generation), add your collector’s IP address. Points that catch people out:
- Port 514 UDP is the default, and UDP syslog is unauthenticated and unacknowledged — a dropped packet is a lost log line. Keep the collector on the same LAN segment where you can, and use TCP or TLS if your firmware and collector both support it.
- Choose the right format. SonicWall offers a default syslog format and an Enhanced Syslog format with named key-value fields. Enhanced is much easier for a parser to read reliably; the default is more compact. Pick one and keep it, because changing it later breaks every parsing rule you have written.
- Set the log level deliberately. Logging every allowed connection on a busy firewall produces enormous volume — this is what pushes people over Splunk’s 500 MB free tier within days. Start with the categories you actually need: denied traffic, VPN events, authentication, system events, and security service alerts.
- Fix the time. Set NTP on the firewall and decide whether it sends local time or UTC, then make sure your collector agrees. Correlating logs across devices with mismatched clocks is the most frustrating way to spend an afternoon.
- Check the firewall rule. The SonicWall needs to be permitted to send outbound UDP 514 to the collector, and the collector’s own host firewall needs to accept it. Windows Firewall silently dropping inbound 514 is the single most common reason a new syslog server looks broken.
Sizing the disk
Log volume varies enormously with what you enable. A small office firewall logging denied traffic and system events might produce 50–200 MB a day; the same appliance logging every connection can produce several gigabytes. Measure for a week before committing to a retention policy, and set up rotation and compression from the start — a full disk stops the collector, and a stopped collector loses everything sent while it was down, because UDP syslog has no retry.
A reasonable default
For a single SonicWall at a small site: run rsyslog on a Linux VM or Fastvue Syslog on Windows, write to disk with 90-day rotation, and stop there. If you find yourself grepping those files more than once a week, add Graylog and point the same stream at it. Go to a full SIEM only when somebody is genuinely going to read the alerts — the tool is not the hard part, the attention is.