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.
\nThe 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.
\nThese 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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nKeep 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.
\nReview 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.
\nDo 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.
\nProposed 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.
\nIf 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.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThese 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.\nApplicability questions\n\nIs the question about routed traffic, firewall-originated traffic, a local proxy, or a defined combination?\nWhich exporter interfaces and ingress filter are enabled?\nWhat collector query, direction and time interval produced the reported total?\nWhat independent observation will help explain the selected test flow?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nKeep 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.\nReview 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.\nDo 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.\nVerification and evidence\nProposed 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.\nIf 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.\nOfficial references\n\nOPNsense — Netflow Export & Analyses — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [OPNsense Netflow guide](https://docs.opnsense.org/manual/netflow.html) 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.\n\n## What the source does not establish\n\nThese 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.\n\n## Applicability questions\n\n- Is the question about routed traffic, firewall-originated traffic, a local proxy, or a defined combination?\n\n- Which exporter interfaces and ingress filter are enabled?\n\n- What collector query, direction and time interval produced the reported total?\n\n- What independent observation will help explain the selected test flow?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nKeep 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.\n\nReview 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.\n\nDo 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.\n\n## Verification and evidence\n\nProposed 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.\n\nIf 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.\n\n## Official references\n\n- [OPNsense — Netflow Export & Analyses](https://docs.opnsense.org/manual/netflow.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/explain-opnsense-netflow-double-counts-before-comparing-traffic-totals/", "url": "https://update.dsesecurity.com/updates/explain-opnsense-netflow-double-counts-before-comparing-traffic-totals/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/explain-opnsense-netflow-double-counts-before-comparing-traffic-totals/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Explain OPNsense Netflow double counts before comparing traffic totals", "item": "https://update.dsesecurity.com/updates/explain-opnsense-netflow-double-counts-before-comparing-traffic-totals/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/explain-opnsense-netflow-double-counts-before-comparing-traffic-totals/#article", "identifier": "https://update.dsesecurity.com/updates/explain-opnsense-netflow-double-counts-before-comparing-traffic-totals/", "url": "https://update.dsesecurity.com/updates/explain-opnsense-netflow-double-counts-before-comparing-traffic-totals/", "headline": "Explain OPNsense Netflow double counts before comparing traffic totals", "description": "OPNsense documents NAT-related double flow counts when ingress and egress are enabled; filtering ingress also affects visibility of an on-box proxy.", "abstract": "OPNsense documents NAT-related double flow counts when ingress and egress are enabled; filtering ingress also affects visibility of an on-box proxy.", "articleBody": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThese 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.\nApplicability questions\n\nIs the question about routed traffic, firewall-originated traffic, a local proxy, or a defined combination?\nWhich exporter interfaces and ingress filter are enabled?\nWhat collector query, direction and time interval produced the reported total?\nWhat independent observation will help explain the selected test flow?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nKeep 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.\nReview 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.\nDo 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.\nVerification and evidence\nProposed 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.\nIf 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.\nOfficial references\n\nOPNsense — Netflow Export & Analyses — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T00:10:08+00:00", "dateModified": "2026-10-29T00:10:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/explain-opnsense-netflow-double-counts-before-comparing-traffic-totals/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/explain-opnsense-netflow-double-counts-before-comparing-traffic-totals/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Explain OPNsense Netflow double counts before comparing traffic totals" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 588, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — Netflow Export & Analyses", "url": "https://docs.opnsense.org/manual/netflow.html" } } ] } }