Configure and test NetFlow on Sophos Firewall

With NetFlow, Sophos Firewall sends connection metadata to an external flow collector. This makes it possible to analyse communication relationships, traffic volume, and suspicious connections over time. The most important prerequisite is easy to overlook: only traffic from firewall rules with Log firewall traffic enabled is exported.

The short version is:

1. Prepare a NetFlow v5 listener on the collector, for example on UDP 2055.
2. Add the collector under System > Administration > Netflow.
3. Enable Log firewall traffic on the affected firewall rule.
4. Generate a clearly documented test flow.
5. Check the transport with Packet Capture and the content in the collector separately.

NetFlow is therefore quick to configure. For reliable results, however, it must be clear which data version 5 contains, which rule processes the test flow, and which path the firewall uses to reach the collector.

When NetFlow Is the Right Tool

NetFlow is suitable when a collector needs to store flow records for connections processed by logged rules and analyse them over time. Typical questions include: Which source and destination addresses communicate with each other, which ports are used, and how many packets or bytes belong to the flow?

Other tools answer different questions:

• sFlow Monitoring samples traffic and interface counters from selected hardware interfaces. It is particularly suitable for traffic patterns and capacity monitoring.
• Syslog to a SIEM transports firewall, VPN, IPS, and other log events with product-specific fields.
• SNMP Hardware Monitoring monitors hardware, interfaces, temperature, fans, or power supplies.
• Central Firewall Reporting provides Sophos reports, search, and retention in Sophos Central.
• Packet Capture remains more precise for an individual packet path, NAT, or connection error.

NetFlow does not replace these tools. The collector often identifies a suspicious flow, while Log Viewer or Packet Capture then explains which rule, NAT decision, or security feature was involved.

What NetFlow v5 Shows – and What It Does Not

SFOS 22 exports NetFlow Version 5. A v5 record can include the following values:

• IPv4 source and destination address;
• source and destination port as well as IP protocol;
• packet and byte counters;
• flow start and end time;
• input and output interface as ifIndex;
• TCP flags, ToS, AS, and prefix information.

NetFlow v5 does not, however, contain native fields for user name, Firewall Rule ID, URL, application, or packet content. A collector can correlate IP addresses with additional data sources, but this information does not come directly from the v5 record.

The collector address can be entered in SFOS as an IPv4 address, IPv6 address, or FQDN. This does not change the export format: the firewall still sends NetFlow v5. Whether the required IPv6 user traffic is represented meaningfully in the deployed setup must therefore be checked separately; an IPv6 collector address does not confirm support for IPv6 flows.

Prepare the Collector and Network Path

Before configuring the firewall, the collector requires an active NetFlow v5 listener. Sophos uses UDP 2055 by default; other ports between 1 and 65535 are possible if the firewall and collector are configured identically. Up to five NetFlow servers can be configured.

The example uses:

• Collector name: flow-collector-primary
• Collector address: 192.0.2.50
• Transport: UDP
• Collector port: 2055
• Test rule: LAN_Test_to_WAN_HTTPS

192.0.2.50 is a reserved documentation address and cannot be used as a real collector. In this example, it only shows which field is meant. Enter the real IP address or FQDN of the collector where the v5 listener is running and that the firewall can reach over the intended network path. Clarify these points first:

• The collector supports NetFlow v5 and is actually listening on UDP 2055.
• The firewall has a route to the collector; if an FQDN is used, DNS must also work.
• Intermediate devices and the collector’s host firewall allow the UDP port.
• The collector assigns the source address actually used to the correct firewall.
• The purpose, access rights, and retention period for the flow data are defined.

The NetFlow export is system-generated traffic from the firewall. A client firewall rule does not control this export. The relevant factors are the system traffic path, routing, DNS when using an FQDN, and filters between the firewall and collector.

⚠️ The NetFlow configuration does not provide TLS or authentication options. Flow data can reveal internal addresses, communication partners, ports, times, and volumes. The collector should therefore be reachable through a trusted management network or a protected VPN path.

Configure the NetFlow Collector

1. Open System > Administration > Netflow in WebAdmin.
2. Click Add.
3. Enter flow-collector-primary under Netflow Server name.
4. Enter 192.0.2.50 under Netflow server IP/domain.
5. Enter 2055 under Netflow server port.
6. Save with Save.

The form has no documented connection test. A saved entry therefore confirms only the configuration, not the transport or decoding in the collector.

Enable Rule Logging as the Data Source

NetFlow exports only connections from firewall rules where Log firewall traffic is enabled. Check this setting on the relevant rule under Rules and policies > Firewall rules.

Use a clearly scoped rule for the first test. In this example, LAN_Test_to_WAN_HTTPS processes an HTTPS test from a known client to an approved destination. The example name itself is not important; what matters is that the administrator can clearly identify in Log Viewer which rule actually processes the flow.

Create Sophos Firewall rules correctly explains how to structure and log a rule properly. If there is uncertainty about the match, Test a rule with Log Viewer, Policy Tester, and Packet Capture can help.

Test the Export in a Controlled Manner

The test separates three questions: Did the correct rule match, does a UDP packet leave the firewall, and can the collector read the content as NetFlow v5?

1. On the collector, verify that the v5 listener is running on UDP 2055.
2. Note the time, test client, destination address, destination port, and expected firewall rule.
3. Generate exactly one new connection from the test client, for example an allowed HTTPS request.
4. In Log Viewer, verify that LAN_Test_to_WAN_HTTPS or the expected Rule ID matched.
5. Under Diagnostics > Packet capture, search for the export with dst host 192.0.2.50 and dst port 2055.
6. On the collector, verify that a v5 record with the expected source and destination values appears.

For an additional read-only check, run a short capture in the Device Console:

tcpdump 'host 192.0.2.50 and port 2055'

Replace 192.0.2.50 and 2055 with the actual collector and port. Stop the capture with Ctrl+C. Visible UDP packets confirm transport as far as the observed interface, but do not yet prove that the collector decodes the records as version 5.

A successful test is complete only when the rule match, UDP transport, and v5 decoding all correspond. This also makes it clear at which point an error occurs.

Isolate Missing or Incomplete Flows

No UDP Packets to the Collector Address

Check the collector address and port under System > Administration > Netflow. Then check DNS when using an FQDN, the route, the outgoing interface, and filters on intermediate devices. The collector’s host firewall must also accept UDP 2055.

If other rules or routing paths are changed at the same time, the result is difficult to attribute. Start with a known logged rule and a single test flow.

UDP Packets Arrive, but the Collector Shows Nothing

The listener must explicitly process NetFlow v5. An input configured only for NetFlow v9, IPFIX, or sFlow can receive the UDP packets but still display no usable flows. Check the collector logs, parser, and expected source address.

In this case, Packet Capture proves only the transport. Successful decoding must be visible in the collector itself.

Only Some Connections Are Visible

First check which firewall rule actually processes the missing traffic and whether Log firewall traffic is enabled there. A different rule may match earlier than expected. UDP packet loss can also cause gaps.

NetFlow v5 has technical limitations. Missing user names, Rule IDs, URLs, or application names are not an export error. IPv6 user traffic should also not be expected solely because the collector address supports IPv6.

The Source Address Is Unexpected

The NetFlow form has no dedicated source IP selector. The address seen by the collector therefore depends on the firewall’s system traffic path. Check the route, outgoing interface, and any existing SD-WAN or source NAT configuration for system traffic before assigning a fixed address in the collector.

HA Failover or Firmware Change

For NetFlow, seamless or duplicate-free HA export is not publicly guaranteed. Therefore, during normal operation and after a controlled failover, verify that records continue to arrive, which source address is visible, and whether the collector still assigns them to the correct firewall.

Repeat the same documented test after firmware, routing, DNS, collector, or rule changes. A short reference flow is more reliable than assuming that a saved NetFlow entry still works.

Operations and Data Protection

Like firewall logs, NetFlow data requires an owner and a defined retention period. Operations should cover at least the following points:

• Monitor collector reception for each firewall and alert on outages;
• document source addresses, interface assignments, and time synchronisation;
• restrict access to internal communication metadata;
• define retention and deletion in the collector;
• retest after routing, HA, firmware, or rule-logging changes;
• verify suspicious flows with Log Viewer or Packet Capture.

NetFlow reveals relationships over time, but it does not prove the cause of a blocked or slow connection. For a specific session, the Rule ID, NAT ID, packet path, and involved security features remain decisive.

FAQ