Configure sFlow Monitoring on Sophos Firewall

With sFlow Monitoring, a Sophos Firewall can send traffic samples to an external collector. This allows you to better see volume spikes, noticeable flows, unusual destinations, or load distribution across interfaces than with individual live logs alone. Sophos added sFlow as a monitoring feature with Sophos Firewall v22.

The feature is particularly interesting for troubleshooting, capacity planning, and security monitoring. However, sFlow does not replace the Log Viewer, Packet Capture, or proper log retention via Central Firewall Reporting or Syslog. sFlow answers different questions: not “which rule exactly applied?”, but “which traffic flows run over this interface and how are they distributed?” For hardware status, temperature, fans, power supplies, and PoE, SNMP Hardware Monitoring is more suitable.

When sFlow is Useful

sFlow is useful when an external collector or monitoring system is available and traffic patterns over time need to be visible.

Typical use cases:

• Detect unexpected bandwidth spikes on WAN, LAN, or core interfaces.
• Better classify traffic between VLANs or locations.
• Support capacity planning for firewall, uplink, or core switching.
• Identify suspicious flows as a starting point for further analysis.
• Compare monitoring data with firewall logs, Central Reporting, or SIEM data.

If only a single connection needs to be checked, sFlow is often not the right tool. For targeted performance tests, iPerf is more suitable. For specific connection problems, Log Viewer, Policy Test, and Packet Capture are usually faster.

Prerequisites

For sFlow, you need:

• Sophos Firewall with SFOS 22.0 or newer.
• Administrative access to the Device Console.
• An accessible sFlow collector, such as an NMS, SIEM, or flow analysis tool.
• A secure network between the firewall and the collector.
• A clear decision on which hardware interfaces should be monitored.

Configuration is not done in the normal WebAdmin interface but via the Device Console with system sflow. The Advanced Shell is not the right place for this. The distinction between Device Console and Advanced Shell is explained in the article Sophos Firewall Troubleshooting: Services and Logs.

Important Limits Before Activation

sFlow seems harmless but can have impacts on operation and security.

sFlow is Not Encrypted

The sFlow traffic from the firewall to the collector is not encrypted. Therefore, the collector should be reachable via a trusted management network, an internal monitoring network, or another protected path.

⚠️ sFlow should not be sent unprotected over insecure networks. Flow data can reveal internal IP addresses, communication relationships, and target systems.

FastPath is Disabled on the Monitored Interface

When sFlow is active on an interface, Fast Path is disabled on that interface. This is particularly important for heavily loaded WAN, LAN, or core interfaces.

Before activation, you should check:

• How heavily is the interface loaded?
• Is productive high-throughput traffic running over it?
• Is there a maintenance window for the first test?
• Can performance be compared before and after activation?

For a basic understanding of firewall performance, the article Understanding Sophos Firewall Performance Metrics is suitable.

HA Cluster: sFlow Runs Only on the Primary

In an HA cluster, the sFlow agent runs on the Primary. This must be considered in evaluations and failover tests. After a role change, it should be checked whether the collector continues to receive data and whether the agent IP remains as expected.

For planning HA operation and monitoring, Setting Up Sophos Firewall High Availability is suitable.

Plan Interface and Collector

sFlow is configured on hardware interfaces. Dependent interfaces such as aliases and VLANs of the selected hardware interface can also become visible in the samples. Therefore, the interface selection should always match the actual traffic path, not just the name of the VLAN or the desired evaluation in the collector.

This is practical but can lead to misinterpretations:

• If Port1 is monitored, associated VLAN or alias interfaces can also become visible in the sampling.
• If only a specific VLAN is of interest, it must be cleanly filtered in the collector.
• If multiple core or WAN ports exist, not all interfaces should be activated immediately.
• In LAG, bridge, or VLAN designs, it should be clear beforehand where the relevant traffic really flows.

A clear basis for this is an understandable interface and zone planning. The article Configuring Sophos Firewall Zones and Interfaces helps in classifying physical interfaces, VLANs, bridges, LAGs, and RED.

Plan Pilot, Data Protection, and Return Path

Before the first activation, sFlow should be treated like a productive monitoring change. The function generates additional data, changes FastPath on the monitored interface, and sends flow information to another system. Therefore, it is not enough to just enter the collector IP and sampling rate.

Before the pilot, these points should be clear:

• What specific problem should sFlow solve: capacity planning, bandwidth spikes, security monitoring, or troubleshooting?
• Who operates the collector and who is allowed to see the flow data?
• How long will flow data be stored?
• Through which network path do the sFlow packets reach the collector?
• Which interface will be tested first?
• What measurements are considered baseline before activation?
• When will sFlow be deactivated or moved to another interface?

Flow data can reveal internal IP addresses, communication relationships, target systems, ports, and traffic volumes. These data are less detailed than a full packet capture but still operationally and security-relevant. If the collector is connected to a SIEM or a central monitoring platform, responsibility should be as clearly defined as with Sending Sophos Firewall Syslog to SIEM.

For the first test, a limited pilot is advisable:

1. Document the initial state: interface load, CPU load, affected services, existing monitoring data.
2. Select a single, not maximally loaded interface.
3. Set the sampling rate conservatively.
4. Check collector reception and data volume.
5. Observe performance, latency, and throughput after activation.
6. Test the return path: system sflow off or remove the monitoring interface.

The return path should be clear before activation. If performance on a productive interface worsens, you should not change the sampling rate, collector, routing, and firewall rules simultaneously. First, deactivate sFlow or remove the affected interface from monitoring with system sflow monitor delete interface-name ..., then measure again.

Add sFlow Collector

First, the collector is defined. The standard port for sFlow is often 6343; in productive environments, the port must match the deployed collector.

Example:

system sflow collector add ip-address 192.0.2.10 port 6343

Sophos supports up to five collectors. Each collector is added separately.

You can then check the current status:

system sflow show

To remove a collector:

system sflow collector delete ip-address 192.0.2.10 port 6343

Configure Interface and Sampling Rate

Next, it is determined which interface is monitored and with what sampling rate packets are selected.

Example:

system sflow monitor add interface-name Port1 sampling-rate 1000

The sampling rate determines how often packets are selected as samples. A lower number generates more samples and thus more details, but also more load and more data at the collector. A higher number reduces the data volume but can make short or smaller flows less visible.

The relevant limits are:

For the start, a conservative value is advisable, for example, 1000 or higher. Then you should check in the collector whether the data volume, detail level, and performance match the target.

A monitoring interface can be removed again:

system sflow monitor delete interface-name Port1

Set Polling Interval

In addition to packet sampling, sFlow can also query statistics and interface counters at an interval. Sophos allows a polling interval between 30 and 300 seconds. With 0, polling is disabled.

Example:

system sflow polling-interval 80

Disable polling:

system sflow polling-interval 0

For most environments, a medium interval is advisable. Too short intervals generate more data and are not automatically more helpful.

Activate sFlow

When collector, interface, and polling are planned, sFlow is activated:

system sflow on

Check the status:

system sflow show

Deactivate sFlow:

system sflow off

After activation, you should not only check the firewall but also the collector. Data from the firewall agent IP must arrive there and be resolved meaningfully.

Validation After Activation

After switching on, you should check these points:

1. system sflow show correctly displays collector, interface, sampling rate, and status.
2. The collector receives sFlow data from the expected firewall IP.
3. The time on the firewall and collector matches.
4. Interface names and flow direction are traceable in the collector.
5. The load on the firewall and collector remains uncritical.
6. The data volume matches the planned retention and processing.
7. The defined return path has been tested once or at least documented as a specific command.
8. In HA clusters, after a failover, check whether data continues to arrive.

If firewall rules, NAT, VPN, or TLS Inspection are analysed in parallel, sFlow should not be considered in isolation. For specific connection decisions, Log Viewer and Packet Capture remain crucial. For long-term evaluation, you should check whether Syslog or Central Reporting is additionally needed.

Troubleshooting

No Traffic in the Collector

First, check system sflow show. Then verify whether collector IP, port, routing, and firewall rules match the collector. Additionally, check on the collector whether the UDP port is reachable and whether incoming sFlow packets are being discarded.

Only Part of the Traffic is Visible

sFlow works with sampling. It is normal that not every single packet is visible. If important flows are missing, the sampling rate can be adjusted or another interface chosen. For VLANs and aliases, check whether the correct hardware interface is being monitored.

Performance Changes After Activation

If a heavily used interface is monitored, the deactivation of FastPath can be relevant. In this case, sFlow should be deactivated for testing and performance compared. For productive core or WAN interfaces, a planned test is better than a spontaneous activation.

HA Data Seems Incomplete

In HA environments, the sFlow agent runs on the Primary. After a failover, check which firewall is currently Primary, which IP is used as the agent IP, and whether the collector continues to correctly assign the data.

Operational Checklist

• Place the collector in a secure network.
• Document ownership, purpose, access, and retention of flow data.
• Check UDP port and routing to the collector.
• Start with one or a few interfaces.
• Capture before-and-after baseline for interface load, CPU, latency, and throughput.
• Choose a conservative sampling rate and adjust thereafter.
• Consider FastPath impact on critical interfaces.
• Document return path: system sflow off or remove monitoring interface.
• Test HA failover if sFlow is used in the cluster.
• Align flow data with Log Viewer, Packet Capture, and Reporting.
• Regularly check whether the data is still being evaluated or just collected unused.

FAQ