Explain OPNsense Netflow double counts before comparing traffic totals

OPNsense documents NAT-related double flow counts when ingress and egress are enabled; filtering ingress also affects visibility of an on-box proxy.

Resilient network core with engineered blue and gold data paths.
DSE visual intelligenceNetworks & infrastructureGuide · 3 min read
Executive summary

What you need to know

OPNsense documents NAT-related double flow counts when ingress and egress are enabled; filtering ingress also affects visibility of an on-box proxy.

Potentially affected

OPNsense Netflow exporter and Insight analysis with NAT or a proxy on the firewall; confirm interfaces, filters and collector interpretation.

DSE recommendation

DSE recommends choosing ingress visibility from the monitoring question and labeling totals with the observation configuration.

Bottom line: Decide what the flow total is intended to represent before comparing it with a circuit counter or another dashboard. Include the local-proxy requirement in that decision rather than removing ingress records solely to make a number look smaller.

Source fact: what the authority says

The OPNsense Netflow guide distinguishes traffic to or from the firewall from traffic passing through it as ingress and egress in its explanation. It warns that enabling both produces double flow counts because LAN-to-WAN traffic also creates an ingress flow during NAT. The guide says ingress flows are needed to see traffic from a proxy on the same device; other non-proxy traffic is then counted twice by the described NAT effect. The exporter supports multiple interfaces, ingress filtering and multiple destinations, including local capture for Insight.

What the source does not establish

These are the OPNsense guide’s observation categories and counting caveat. They do not prove a particular collector’s aggregation or justify interpreting every flow as a unique application transaction. DSE keeps exporter configuration, address translation and the analyst’s query together when assessing a total.

Applicability questions

  • Is the question about routed traffic, firewall-originated traffic, a local proxy, or a defined combination?
  • Which exporter interfaces and ingress filter are enabled?
  • What collector query, direction and time interval produced the reported total?
  • What independent observation will help explain the selected test flow?

DSE recommendation: controlled next steps

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

DSE recommends writing the measurement question in one sentence before changing the exporter. For a proposed example, distinguish a client connection routed directly through NAT from an approved connection using the on-box proxy. Give each a separate identifier and expected observation purpose. Ask the analyst which of those activities must remain visible in the resulting report.

Keep a configuration record with every comparison: interfaces, ingress setting, destinations, selected time interval and query. Do not silently change the filter between two reports presented as a trend. If a different observation configuration is needed, label that point explicitly and obtain a new baseline for the revised question.

Review the displayed total with the network and monitoring owners before treating a discrepancy as missing or excess user traffic. Trace the approved example through the exporter and collector. Explain whether the report is intended to show observations or a separately reconciled traffic measure. Keep any reconciliation method explicit rather than applying an unexplained factor to every result.

Do not divide a total by two as an undocumented correction. Tie the explanation to the actual filtered population and local-proxy requirement. Keep any independently measured traffic total labeled with its own method so the two views are not presented as interchangeable counters.

Verification and evidence

Proposed verification: use an approved small direct-NAT test and, where applicable, a separate proxy test. Record endpoints, times and the actual path, then locate the corresponding flow records under the reviewed configuration. Compare like intervals and preserve the underlying records used for the explanation.

If the plan permits a filter comparison, repeat the same bounded inputs before and after that one change. Have the analyst identify which observations remain and which no longer appear, including the required proxy case. Restore or accept the selected configuration explicitly. Retain the decision about visibility with the report so a later operator can interpret its totals.

Official references

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

Primary reference

Review the official source

OPNsense — Netflow Export & Analyses · Verified October 28, 2026

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE