Rule logging and trace

Firewall logging is the operator’s window into what the firewall is actually doing. Every matched rule can produce a log line. Every dropped packet can be logged. Every passed packet can be logged. The choice is whether to log, what to log, and how to avoid drowning the log in noise.

This lesson covers how to enable logging on rules without flooding the log, how to read the OPNsense firewall log, the trace log for packet-flow forensics, and the operational patterns that keep logging useful in production.

Logging on a rule

Every firewall rule in OPNsense has a “Log” checkbox. When checked, the rule generates a log entry every time it matches a packet. The log entry includes:

• Timestamp (with milliseconds).
• Action (pass, block, reject).
• Rule description (if set).
• Interface.
• Source IP and port.
• Destination IP and port.
• Protocol.
• Direction.
• TOS / TTL (optional).

The log is sent to the firewall’s local syslog and, if remote syslog is configured, to the remote destination. Locally, syslog-ng writes one file per day as /var/log/filter/filter_<YYYYMMDD>.log, with /var/log/filter/latest.log symlinked to the current one.

$ tail -f /var/log/filter/latest.log

<134>1 2026-08-14T03:14:15+00:00 fw.example.com filterlog 44481 - [meta sequenceId="3301"] 87,,,9c1e4a7b25d8f36012ba5e9d47c30f8a,igb0,match,pass,in,4,0x0,,64,19233,0,DF,6,tcp,60,192.0.2.50,203.0.113.10,51820,443,0,S,1000000000,,65535,,mss;sackOK;TS;nop;wscale
<134>1 2026-08-14T03:14:16+00:00 fw.example.com filterlog 44481 - [meta sequenceId="3302"] 100,,,5f8a2d6c91b704e3ad82c5f1907b6e4d,igb0,match,block,in,4,0x0,,64,19234,0,DF,6,tcp,60,192.0.2.50,10.0.0.50,51821,443,0,S,2000000000,,65535,,mss;sackOK;TS;nop;wscale

When to enable logging

Logging is not free. Each log line is a syscall, a write to a file (or network socket, for remote syslog), and a storage operation. A rule that matches thousands of packets per second will produce thousands of log lines per second. The log file fills up, the firewall’s disk fills up, and performance degrades.

The right places to enable logging:

The default block rule

The default block at the end of the ruleset (or the implicit block-all if no explicit block exists) should always be logged. This is the catch-all for unmatched traffic. Logging it tells the operator which traffic is hitting the firewall and being refused — invaluable for diagnosing “I cannot reach X” tickets.

Specific deny rules

When the operator adds a specific deny rule (e.g. block a specific source IP, block a specific destination), the rule should be logged. The log confirms the rule is firing and shows the source/destination of the dropped traffic.

The first pass rule for a service

When the operator adds a new pass rule for a service, the first pass rule should be logged temporarily to verify the service is working. Once verified, the logging can be disabled to reduce noise.

The right places to leave logging disabled:

• High-volume pass rules (e.g. the LAN-to-Internet default pass). Logging every packet would flood the log.
• Anti-spoofing and bogons rules. The match volume is typically low but the value of the information is also low (the rule is a baseline defence, not a specific signal).
• State-matched return traffic. State matches do not generate log lines by default — only the first packet of a flow is logged.

The OPNsense firewall log

The OPNsense GUI exposes the firewall log under Firewall → Log Files. The view shows:

• Filterable by interface, source, destination, port, protocol, action.
• Time-ranged (last hour, last day, custom).
• Live tail (auto-refresh).
• Exportable as CSV.

The log view is the operator’s first stop when diagnosing a firewall incident. The filter narrows down the traffic to the specific flow in question. The action column tells the operator which rules fired.

For high-volume log analysis, the operator typically exports the log to a remote syslog (under System → Settings → Logging → Remote) and queries the remote log store. Common destinations are Graylog, Loki, Elasticsearch, Splunk.

The trace log

OPNsense has a “Live view” under Firewall → Log Files → Live View that shows packets in real time as they traverse the firewall. The live view is a packet capture interface (pflog0 on FreeBSD) rendered in the GUI.

The trace log differs from the regular log in that it shows every packet that matches a logged rule, not just the first packet of each flow. The trace log is the right tool for diagnosing:

• A specific flow that is being dropped or passed unexpectedly.
• A flow that is taking the wrong path (e.g. asymmetric routing).
• A flow that is being matched by the wrong rule (e.g. the specific deny is shadowed by a broader permit above it).

The trace log is filtered by the same criteria as the regular log (interface, source, destination, port, protocol). The operator narrows the filter to the specific flow in question and watches the trace log while reproducing the issue.

$ tcpdump -n -e -ttt -r /var/log/pflog

reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file)
000000 rule 87/0(match): pass in on igb0: 192.0.2.50.51820 > 203.0.113.10.443: Flags [S], seq 1000000000, win 65535, length 0
000001 rule 100/0(match): block in on igb0: 192.0.2.50.51821 > 10.0.0.50.443: Flags [S], seq 2000000000, win 65535, length 0

Performance impact of logging

Logging has a real performance cost. The numbers:

• Local syslog: writing to a file on the firewall’s disk. Each line is a few hundred bytes. With a fast SSD, the throughput can be tens of thousands of lines per second before disk I/O becomes the bottleneck. With a slow disk or under heavy load, the throughput is lower.
• Remote syslog: writing to a remote syslog destination adds network latency and remote disk I/O. If the remote destination is slow or unreachable, the local syslog daemon buffers and eventually blocks.
• Memory buffering: the syslog daemon buffers log lines in memory. When the buffer fills up, the daemon either drops lines (lossy) or blocks the sender (which can back-pressure the firewall’s packet processing).

The production pattern is:

• Log the minimum useful set of rules (default block, specific denies, first-packet pass).
• Configure remote syslog to a destination with adequate capacity.
• Monitor the syslog buffer depth and remote destination availability.

Diagnostic patterns

Three patterns use logging to diagnose common incidents.

“Why is this flow blocked?”

1. Open Firewall → Log Files → (relevant interface).
2. Filter by the destination IP (and port if known).
3. Look for the block entry. The rule number identifies which rule blocked the flow.
4. If no block entry appears, the flow is not hitting the firewall at all — the issue is upstream (routing, ARP, switch).

“Why is this flow passing when it should be blocked?”

1. Open Firewall → Log Files → Live View.
2. Filter by the destination IP and port.
3. Reproduce the flow.
4. The trace log shows every packet and which rule matched. If the flow is passing, the trace log shows the pass rule that matched.
5. If the expected block rule did not match, the rule is shadowed by a broader permit above it. Fix the order or the specificity.

“Why is this flow taking a long time?”

1. Open Firewall → Log Files → Live View on the relevant interfaces.
2. Reproduce the flow.
3. Watch for repeated SYNs with the same sequence number — the host is retransmitting because the SYN is being dropped.
4. The trace log shows the SYN being dropped by a specific rule. The fix is to add or correct a permit rule.

Summary

• Enable logging on the default block, specific denies, and the first-packet pass for new services. Disable on high-volume pass rules.
• The OPNsense firewall log shows rule matches with full packet metadata. Filter by interface, source, destination, port, protocol.
• The trace log (pflog0) shows every packet that matches a logged rule in real time. Use it for live diagnostics.
• Logging has a real performance cost. Configure remote syslog for high-volume deployments.
• The right pattern: log the minimum useful set, monitor the syslog buffer, and use NetFlow for high-volume visibility.