Preserve OPNsense rule context when reading historical firewall logs

Bottom line: Preserve the rule configuration that applied at the incident time before explaining an old log label. Use a controlled flow to distinguish the firewall log from the separate packet evidence needed for the investigation.

Source fact: what the authority says

The OPNsense log-files guide says Live View updates for matched rules with logging enabled or an enabled global logging option. When a state is created, the flow is reported for its first packet, and the same flow produces no new lines while that state exists. The system translates log sequence information back to the stored rule definition, so historical labels can be inaccurate after firewall reconfiguration. The host and port filter fields match both source and destination.

What the source does not establish

These statements describe the documented log view and its interpretation limits. This article does not establish a complete packet history, a historical configuration archive or the cause of a particular denied application connection.

Applicability questions

• What time interval and original connection tuple are being investigated?
• Was rule or global logging enabled for the relevant observation?
• Which configuration revision applied when the line was recorded?
• Is the question about rule matching, packet delivery or the application result?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends retaining a dated configuration export with the relevant log excerpt before editing the firewall. Keep the observed label and the separately established historical rule identity as two fields. If the older configuration cannot be recovered, state that limitation rather than silently substituting the current rule description.

Choose one proposed test flow with an agreed client, server, protocol and time. Define the expected logging condition and write down whether the test uses a new connection or an existing one. Avoid changing unrelated rule order while trying to explain the original event.

Review the filter criteria with another operator. Specify whether the intended search concerns either endpoint or only a source or destination field. Keep the AND or OR selection with the exported result so a later reviewer can reproduce the population being examined.

Escalate an unexplained application failure with separate observations from the network and application owners. Do not add another allow rule simply because repeated application activity does not produce repeated log lines. Preserve the evidence needed to distinguish a logging expectation from an actual access decision.

Verification and evidence

Proposed verification: start an approved new test connection and preserve its log entry, then observe continued activity on that same connection. Correlate timestamps with a narrowly scoped authorized packet capture and the application result. Record what each method observed without presenting one as a substitute for the others.

For a disposable historical example, preserve the rule definition before an approved description change and compare the older log interpretation afterward. Keep both configurations and the unchanged log record. Do not rewrite an incident conclusion from a current label alone; document the uncertainty if contemporaneous context is unavailable.

Official references

• OPNsense — Log Files — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.