Configure Sophos Firewall Discover Mode with TAP and SPAN

In Discover Mode, Sophos Firewall receives a copy of network traffic through a TAP interface. The switch mirrors selected ports or VLANs to a SPAN or mirror port connected to an unbound firewall port. The firewall is not inline and does not change the production packet path.

Quick procedure: Make sure a separate management path is available, configure a bidirectional SPAN port on the switch, select an unbound firewall port, run system discover-mode tap add PortD in the Device Console, and verify the incoming traffic with Packet Capture first. Then review Current Activity, reports, and, if needed, a Security audit report.

⚠️ Discover Mode is an observation mode. Security policies cannot be applied to traffic on the TAP interface, and the firewall can neither block nor drop it. HTTPS is not supported in this mode. Therefore, a report without findings proves neither complete visibility nor effective protection.

PortD is an example in this guide. Use the physical port that is actually free on the appliance.

Discover Mode in eight steps

1. Verify an independent firewall management port and a safe recovery path to administration.
2. On the switch, define which ports or VLANs are to be mirrored in both directions.
3. Connect a dedicated mirror port to an unbound physical firewall port.
4. In the Device Console, record the initial state with system discover-mode tap show.
5. Activate the example port as a TAP with system discover-mode tap add PortD.
6. Under Network > Interfaces, verify the type Discover, physical (TAP).
7. Generate a known test flow and confirm its packets on the TAP interface.
8. Only then assess reports, user attribution, and a Security Audit Report.

The switch and firewall are configured separately. A visible TAP interface does not yet prove that the switch is mirroring the correct frames.

When TAP fits and when it does not

Discover Mode is suitable for passive inventory, a proof of concept, or preliminary analysis before a later inline deployment. Typical objectives include:

• making traffic relationships and active applications visible;
• classifying web and application categories within the technical limits;
• observing IPS detections without changing the data path;
• collecting reports for later policy and segmentation planning;
• evaluating a new firewall alongside the existing infrastructure.

TAP is not the right choice when traffic must already be actively blocked, decrypted, modified with NAT, or controlled by user-based rules. That requires gateway, bridge, or another inline mode with suitable firewall rules.

Discover Mode can be combined with gateway, mixed, and bridge mode. Security rules then apply to the normal inline interfaces, not to the TAP interface. Plan Sophos Firewall zones and interfaces explains how physical ports, zones, bridges, and other interface types fit together.

Example topology and replaceable values

The example uses these components:

• Core switch: SW-Core-01
• Uplink to mirror: Switch-Port 1, receive and transmit
• SPAN destination: Switch-Port 24
• Firewall TAP: PortD, unbound and without IP configuration
• Firewall management: PortA - 10.10.10.16/24
• Test client: 10.20.30.40

The names and addresses are examples. Their function is what matters: the TAP port only receives the mirrored frames. Management, updates, DNS, and report delivery use a different, normally configured interface.

The mirror port must be at least as fast as the traffic being observed. If several heavily utilized source ports are mirrored to a slower destination port, the switch may drop packets from the copy. Production traffic continues to flow, but the report remains incomplete. TAP is therefore not a lossless forensic capture, and a missing event does not prove that it did not occur.

Requirements and security boundaries

Clarify these points before activation:

• A managed switch supports SPAN or port mirroring.
• A physical firewall port is unbound and not used in production.
• Administration remains available through a separate interface.
• The firewall has internet access for cloud classification, IPS updates, and Security Audit Report generation.
• If the report must show users rather than only IP addresses, a suitable external authentication source is integrated.
• The purpose, retention, and recipients of the mirrored data meet privacy requirements.

Mirrored frames may expose internal addresses, DNS requests, unencrypted protocols, and communication relationships. Therefore, retain packet captures and reports only as long as necessary and transfer them securely.

Understand port affinity correctly

For certain platforms, the Sophos guide recommends binding the TAP interface to a CPU with bind-with before activation. XGS appliances do not require manual port affinity because processing is distributed automatically across the CPU cores.

On other appliances and virtual platforms, a suitable CPU assignment depends on the hardware, adapter, and load. Do not copy a CPU value from an unrelated example. If the platform requires manual assignment, plan it before the TAP rollout using the relevant device or support guidance. A generic set port-affinity command does not belong in the normal quick procedure.

For a virtual firewall, also make sure that the hypervisor, vSwitch, and virtual network adapter actually deliver the mirrored frames to the VM. The status of the virtual network adapter alone does not confirm this; packet evidence in SFOS is decisive.

Prepare SPAN or port mirroring on the switch

The exact configuration depends on the switch vendor. At minimum, define these values on the switch:

1. Source: the physical port to observe or the intended VLANs.
2. Direction: receive and transmit so that both directions are visible.
3. Destination: the dedicated port connected to firewall PortD.
4. Session status: enabled.

Do not use the destination port simultaneously as a normal access or trunk port for endpoints. Do not connect the firewall management port to the mirror port either. Otherwise, management and observation paths become mixed or the switch creates an unexpected Layer 2 design.

Before configuring the firewall, document which VLANs and directions the switch really mirrors. On large uplinks, begin the pilot with a single test VLAN or a clearly limited port instead of the entire core traffic.

Activate the TAP interface on Sophos Firewall

Under Network > Interfaces, the selected port must have zone None and must not have an IP configuration or production dependency. Do not unbind an in-use port only for the test: this can interrupt interface hosts, DHCP, routing, rules, or other services.

After logging in to Sophos Firewall through SSH, open Option 4: Device Console. Read the current state first:

system discover-mode tap show

Then activate the intended example port and verify it again:

system discover-mode tap add PortD
system discover-mode tap show

Sophos documents the message Discover Interface added successfully for a successful activation. The port then appears under Network > Interfaces as Discover, physical (TAP).

The command does not configure SPAN on the switch. If the port shows the correct SFOS status but no traffic, check the switch side first instead of creating a firewall rule on suspicion.

Verify traffic and reports

1. Perform a controlled packet check

Generate a clear DNS or unencrypted HTTP test on test client 10.20.30.40. Under Diagnostics > Packet capture, use a narrow BPF filter:

host 10.20.30.40

The capture must show packets with In interface PortD. With bidirectional mirroring, request and response appear. A Firewall Rule ID or Forwarded status is not a success criterion on the passive TAP path because SFOS does not forward this traffic or apply a security policy to it.

Packet Capture in Sophos Firewall WebAdmin explains operation, filters, and export limits. Stop the capture after the test and retain only the necessary time window.

2. Check visibility in context

After confirming packets, review Current activities and the appropriate local reports. Expectations must match the protocol:

• visible source and destination addresses match the test;
• an application or web category is only expected where SFOS can classify the traffic;
• an IPS detection is an observation, not a block;
• users appear only with a working identity source and correct attribution;
• HTTPS content is not supported in Discover Mode.

Test the external user source separately. Connect Active Directory to Sophos Firewall helps with Active Directory. Otherwise, a missing username does not automatically mean that the TAP traffic is missing.

3. Generate a Security Audit Report

Under Reports > Show report settings > Report scheduling > Add, select Security audit report as the type. Enter recipients and organization deliberately, then verify mail transport and report content separately.

Schedule Sophos Firewall reports and send them by email explains the boundaries of Send test mail, Generate now, privacy, language, and HA behavior. A successful test email proves only the mail path. Only a generated report with plausible data confirms the complete path.

HA and mixed operating modes

Discover Mode supports only active-passive HA. Active-active HA is not possible when either firewall operates in Discover Mode.

An active-passive cluster cannot be created while the TAP interface is active. To set up HA, disable the TAP port on both appliances, create HA, and then enable the TAP interface individually on both devices. Sophos also notes that the TAP interface remains active on the passive appliance.

For this reason, verify cabling, switch mirroring, and data reception again after a planned role change. Do not assume that an existing report period or TAP observation continues without interruption on the other node. Set up Sophos Firewall HA explains roles, synchronization, and node-local behavior.

The boundary remains clear in a mixed gateway or bridge design: normal interfaces can forward and protect traffic. The TAP interface only receives the mirrored copy.

Troubleshoot by symptom

The TAP interface shows no packets

1. Check the configured port with system discover-mode tap show.
2. Under Network > Interfaces, verify the type Discover, physical (TAP) and the physical link.
3. Compare the switch destination, source ports or VLANs, and mirror direction.
4. Repeat a known test flow without an overly narrow capture filter.
5. On a VM, check whether the virtual network path delivers mirrored foreign frames to the firewall.

A firewall rule is not the solution because TAP traffic is not forwarded through the normal rule engine.

Only one direction is visible

The switch mirror source is often set to RX or TX only. Change the session to both, or both directions, and repeat the same test. With asymmetric routing, the return path may also use another physical uplink that is not mirrored.

Packets are visible, but reports are empty or incomplete

First check the time window, report type, internet access, pattern status, and the protocols actually mirrored. HTTPS is not supported in Discover Mode. An oversubscribed SPAN destination may also lose copies without affecting production traffic.

If users are missing, continue with the authentication source. If only email delivery fails, check email notifications first. Do not restart reporting services on suspicion or delete local report data as an initial step.

A report shows risks, but nothing is blocked

This is expected behavior. Discover Mode assesses a copy. A finding becomes a later inline policy, segmentation measure, or other protection only after technical review. The TAP firewall cannot stop the observed original flow afterward.

Roll back Discover Mode safely

Before rollback, save the required reports, time windows, and findings. Then:

1. Disable the SPAN session on the switch so that no further copies arrive.
2. Remove the example port in the Device Console:

system discover-mode tap delete PortD
system discover-mode tap show

3. Under Network > Interfaces, verify that the port no longer appears as Discover, physical (TAP).
4. Remove unneeded Security Audit schedules in a controlled manner.
5. Reuse the switch destination port normally only after documented verification.
6. If the firewall port will be used in production, plan and test its zone, IP, dependencies, and rules as a separate change.

Do not mix a TAP rollback with an improvised inline migration. Gateway or bridge mode changes routing, rules, and outage risk and requires a separate migration plan.

Checklist

• Separate management access works.
• The TAP port is physical, unbound, and not used elsewhere.
• SPAN source, direction, and destination are documented.
• The mirror destination is not oversubscribed.
• system discover-mode tap show shows the expected port.
• Packet Capture sees a known test flow in both directions.
• Reports are assessed only within the supported visibility.
• HTTPS and the lack of enforcement are documented.
• User attribution was tested separately if required.
• Report recipients and retention are approved.
• HA or VM boundaries were tested in the real deployment.
• Rollback and later inline migration are separate changes.

FAQ