Configure sFlow Monitoring on Sophos Firewall

With sFlow Monitoring, a Sophos Firewall can send traffic samples to an external collector. This makes volume spikes, unusual flows, unexpected destinations, and load distribution across interfaces easier to see than in individual live logs. The feature is available in 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.

If NetFlow v5 records from specifically logged firewall rules are required instead of interface samples, Configure and test NetFlow on Sophos Firewall is the better fit. If a switch instead needs to deliver a mirrored packet stream passively to the firewall, Discover Mode with TAP and SPAN is the suitable, clearly separate model.

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 on a WebAdmin page. In WebAdmin on SFOS 22, open the username menu (for example, admin) in the top-right corner and select Console; on SFOS 23, click the Account icon there and select Command line. Then choose 4. Device Console in either version to run system sflow. The Advanced Shell is not the right place for this. Sophos Firewall troubleshooting: services and logs explains the distinction.

If you use an SSH client instead, go to Administration > Device access > Local service ACL, allow SSH from the required source zone, and click Apply. Do not open an entire zone unnecessarily. A Local service ACL exception rule is the narrower choice when only specific management hosts need access. Confirm existing console or SSH access before changing sFlow, not when you already need to roll back.

Minimal Flow

The actual configuration is short. The important part is to plan the monitoring path first and only then turn on sFlow:

1. Define the collector, port, and network path.
2. Select one hardware interface for the first pilot.
3. First run system sflow show to check whether old collectors or monitor interfaces are already configured.
4. Configure the sampling rate and, optionally, the polling interval.
5. Use system sflow show to verify that the collector and interface are configured correctly.
6. Turn on sFlow with system sflow on.
7. In the collector, check that data arrives from the expected firewall agent IP.

The following sections explain the individual steps and the operational limits.

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.

In SFOS 22, the agent uses an IP address from one of the hardware interfaces. In SFOS 23, this is the automatic fallback when no agent IP is configured with agent-ip. However, the SFOS 22 help does not specify which address is selected when several hardware interfaces are suitable. Do not infer a specific agent IP from routing or interface names alone. After activation, identify and document the agent IP that actually arrives at the collector; any collector allowlist must reflect that observation.

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 production interface worsens, do not change the sampling rate, collector, routing, and firewall rules at the same time. First, turn off sFlow or remove the affected interface from monitoring, and then measure again.

For a first-time pilot using the example values without changing the agent identity, the return path is below. This block does not reset an identity configured with agent-ip; the limitation in the optional SFOS 23 step still applies:

system sflow off
system sflow monitor delete interface-name Port1
system sflow collector delete ip-address 192.0.2.10 port 6343
system sflow polling-interval 60
system sflow show

This removes only the entries created by the example and resets the polling interval to the documented default of 60 seconds. If sFlow was already configured, this block is not a blanket rollback. Remove only your additions, restore the polling interval and on/off state recorded earlier with system sflow show, and run system sflow show again to verify the final state. If SSH was enabled only for this pilot, also restore the previously documented Local service ACL or exception rule without removing other management access.

Add sFlow Collector

First, the collector is defined. If no other port is planned, sFlow typically uses 6343. Sophos allows port values from 1 to 65535; the documented default is 6343. In production environments, the port must still match the collector in use and the firewall rules on the path to it.

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

Optional: Set the Agent Identity in SFOS 23

This step applies only to SFOS 23; the existing SFOS 22 workflow remains unchanged. With agent-ip, you can specify a valid unicast IP as the firewall’s sFlow identity in the collector. Only one configured agent IP is allowed per firewall. This is not the collector’s destination address. Without a configured identity, SFOS 23 automatically uses a hardware-interface IP.

⚠️ Before changing anything, save the initial configuration with system sflow show, including any existing agent IP. A different identity can change attribution and identity filters in the collector. Do not blindly replace an existing identity; first confirm the procedure for the installed version. The SFOS 23 description disagrees internally about deletion: the syntax summary requires an IP address, while the detailed description and example omit it. Consequently, no deletion command or complete rollback for a newly configured identity is provided here. If reliable return to automatic identity is required, skip this optional step until the deletion syntax is authoritatively clarified for the installed version. system sflow off stops export but is not evidence that the previous identity has been restored.

Only after this preflight and with no existing configured identity, the following is an adaptable Device Console example:

system sflow show
system sflow agent-ip add 192.0.2.20
system sflow show

192.0.2.20 is a documentation value: replace it with a valid unicast IP intended to identify your firewall unambiguously in the collector. 192.0.2.10 remains the separate collector destination in this example. The agent identity does not guarantee the UDP source address, routing, interface assignment, or transport ACL behavior; check the network path separately.

Check the configuration after the change and, after activation, compare the agent IP actually decoded from the sFlow data by the collector with the planned value. Adjust identity filters only based on that observation. If it differs, first check configuration and collector decoding rather than guessing further identity changes. Recheck reception and attribution after HA failover too; identity stability across a role change is not guaranteed.

Configure Interface and Sampling Rate

Next, it is determined which interface is monitored and with what sampling rate packets are selected. In SFOS 22, the sFlow agent uses a hardware-interface IP; in SFOS 23, this applies only without a configured agent-ip. In the collector, a hardware-interface IP can therefore appear even if the actual analysis concerns a VLAN or alias below that port.

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; the default is 60 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. By default, sFlow is turned off:

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 the collector IP, port, and network path. On the collector, check whether incoming sFlow packets are being discarded or filtered for the wrong agent IP. When the firewall has several hardware-interface IP addresses, do not guess the agent IP in advance.

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