Planning and Validating Traffic Mirroring for Sophos NDR

Traffic Mirroring provides Sophos NDR with a copy of network traffic. For local or virtualized networks, this is usually done with SPAN; remote sources are encapsulated using ERSPAN over GRE or VXLAN; and in AWS, it is done through VPC > Traffic mirror sessions. The goal is not to mirror as many ports as possible without review. NDR needs the right traffic relationships without loops, unnecessary duplicates, or an overloaded destination path.

The safe process is:

define the traffic relationships and boundaries to be monitored,
select exactly one suitable observation point for each relationship,
check capacity from the source to the NDR sensor,
mirror a small pilot source first,
validate the chain from source to processing in stages,
expand sources only in a controlled manner and measure again after each change.

Before activation, the source, direction, filter, destination, maintenance window, permitted data scope, and rollback responsibility must be approved and documented. Mirrored data can contain payloads and other sensitive information. Unintended user, administration, identity, or other sensitive segments must therefore not be mirrored broadly as a precaution or “just in case.” The pilot source is limited to the approved operational and privacy scope.

Select Sources and Observation Points

A short coverage matrix is useful before configuration. Rather than simply listing every switch port, it lists the relevant communication paths, for example:

clients to the internet and external services,
clients to internal servers,
traffic between servers, especially across segment or security-zone boundaries,
data center to branch offices or cloud networks,
east-west traffic between virtual machines that does not traverse a physical uplink.

For each path, select a point where both directions are visible. This is generally a trunk, VLAN, or port near a segment boundary. An internet uplink provides good visibility into north-south traffic, but it does not see local traffic within the same VLAN. A physical switch, in turn, does not see traffic that remains within the same vSwitch. Such gaps cannot be inferred from a green sensor status; they must be identified from the topology and test matrix.

Source and Direction

Depending on the platform, a SPAN source can be a port, port group, or VLAN. Where possible, mirror both directions—that is, inbound and outbound traffic. Mirroring only one direction can hide responses, errors, and parts of a session.

A trunk or entire VLAN simplifies coverage, but increases the data volume and likelihood of duplicates. Individual access ports are more targeted, but are easier to overlook when systems move or workloads are dynamic. The choice should therefore be based on the traffic relationship, not the number of available sources.

Destination

The mirror destination is exclusively the capture path of the NDR sensor:

for a VM, the port group or vSwitch to which SPAN1 or SPAN2 is connected,
for a physical connection, the dedicated switch port connected to the SPAN interface,
for ERSPAN, the sensor’s configured GRE or VXLAN destination address,
in AWS, the NDR SPAN Target created by the CloudFormation stack.

The management interface does not belong in this chain as a SPAN destination. The destination port must also not be used as a normal source and should not send production traffic back into the network.

Avoid Loops and Duplicate Packets

Port Mirroring copies packets; it must not return them to the production forwarding path. A loop can occur, for example, if the SPAN destination is mirrored again or used as a normal uplink. Duplicate data is more common: the same packet is captured at the access port and the uplink, on both sides of a segment boundary, or simultaneously through local SPAN and ERSPAN.

Before activation, check the following:

The destination interface is only a destination and never a source for the same or an overlapping session.
Whenever possible, mirror an end-to-end traffic path at exactly one meaningful boundary.
Two SPAN ports must not receive overlapping sources unless the overlap is documented and intended for a time-limited test.
Broadcast and multicast traffic must not be collected at multiple points in the same Layer 2 domain.
For a cluster or vMotion, establish which host and uplink receive the physical mirror. An NDR VM using standard SPAN from a physical switch must remain on the ESXi host that receives this traffic.
In AWS, only the necessary session should exist for each ENI and intended traffic scope. Also check session order and filters.

Duplicates consume capture, tunnel, and CPU capacity without improving operational coverage. Packet or byte rates that nearly double after a source is added, even though production traffic remains unchanged, are suspicious. If this happens, disable the most recently added source and check the topology for overlaps.

Configure SPAN Locally or in the Hypervisor

The exact syntax varies by switch and hypervisor. Regardless of the platform, the model remains the same: select the source and direction, define a dedicated destination, and ensure that the virtual capture port group permits promiscuous reception.

For a Sophos Switch session, a small pilot configuration could, for example, mirror ports 1 through 4 in both directions to port 8:

configure terminal
monitor session 1 destination interface gigabitethernet 0/8 allow-ingress
monitor session 1 source interface gigabitethernet 0/1 both
monitor session 1 source interface gigabitethernet 0/2 both
monitor session 1 source interface gigabitethernet 0/3 both
monitor session 1 source interface gigabitethernet 0/4 both
save
end
show monitor session 1

The interface numbers are examples and must match your cabling. Before saving, verify that 0/8 leads only to the NDR capture path. For other vendors, use their documented SPAN commands; similar names do not automatically have identical semantics.

For an ESXi Standard vSwitch, set the capture port group to VLAN ID 4095 and set Promiscuous mode under Security to Accept. Physically mirrored traffic also requires a dedicated uplink from the switch to the appropriate vSwitch. Internal VM traffic may require a separate virtual mirror source. With Hyper-V, the NDR capture interface must be connected to the correct vSwitch as the port-mirroring destination; verify the platform configuration separately from the NDR sensor setting.

Sophos NDR enables SPAN Port 1 by default; SPAN Port 2 is disabled by default. A second SPAN port is useful only when it receives a separate source without unnecessary overlap. The VM requires at least 8 vCPUs for SPAN Port 2.

Use ERSPAN with GRE or VXLAN

ERSPAN transports copies from remote sources to the sensor over an IP network. This makes the transport path part of capacity and fault analysis: MTU, routing, ACLs, and possible fragmentation can affect capture even when the source session is correct.

Configure the appropriate capture interface under Settings in Sophos Appliance Manager:

VXLAN

Enable Enable ERSPAN next to the intended SPAN port.
Under Tunnel Protocol, select vxlan.
Under IP Address, enter the address of the VTEP interface.
Set VXLAN ID and VXLAN Port exactly as configured on the encapsulating source.
Select Save.

GRE

Enable Enable ERSPAN next to the intended SPAN port.
Under Tunnel Protocol, select gre.
Under IP Address, enter the address of the GRE destination interface.
Enter the GRE Port that matches the source configuration.
Select Save.

Changes to the SPAN settings take effect only after the VM is restarted. Before restarting, check whether the same appliance processes other integrations; their data collection will also be interrupted. Afterward, validate the tunnel parameters and processing again.

Using SPAN together with VXLAN on the same appliance is a common design. Use VXLAN and GRE simultaneously on the same appliance only when the sources, capacity, and failure domains are clearly separated and documented.

Understand AWS Traffic Mirroring

In AWS, the architecture follows the same model: the Mirror Source is the ENI of the approved workload, not the management ENI of the NDR sensor; the Mirror Target and filter must belong to the deployed NDR design. Limit the filter to the intended data scope. The AWS deployment itself and creation of the Traffic Mirror Session are described in “Deploy Sophos NDR on AWS” and are not repeated here.

For acceptance, use the evidence chain described below. The mere existence of an AWS session proves neither packet flow to the destination nor processing, upload, or detection.

Limit Capacity Before Acceptance

SPAN Port 2 is not a capacity expansion: the VM needs at least 8 vCPUs to enable it, but the second input adds traffic and therefore processing demand. Use it only for a separate, non-overlapping source. If the rate or packet loss increases after activation, check whether SPAN2 introduced additional or duplicate load.

“Monitor Sophos NDR Health and Capacity” explains how to evaluate status, unicast, and drop signals and assess capacity. For symptom-based troubleshooting steps, see “Diagnose the NDR Integration Appliance and Sensor”. Depending on the platform, capacity measures can include additional VM CPU or non-overlapping distribution to another appliance; other CPU-intensive integrations must be planned separately. Adding SPAN2 alone does not increase processing capacity.

Validation: From Source to Detection

Perform the validation with a known pilot host and a defined time window. This makes it possible to assign an error to a particular stage instead of changing the switch, tunnel, sensor, and Sophos Fusion simultaneously.

1. Configuration and Topology

Compare the source, direction, and destination with the coverage matrix.
Check the vendor status of the SPAN or AWS session.
Ensure that the destination is not included as a source.
For ERSPAN, verify the destination address, GRE or VXLAN parameters, and network path.
For virtual platforms, verify the assignment of the capture NIC, port group, or vSwitch.

2. Packets at the Destination

Use controlled unicast test traffic from the pilot host to verify that packets arrive at the intended capture destination. Record the time window, destination interface, expected source and destination addresses, and—where applicable—both directions as evidence. This stage proves that the tested packets arrived at the intended destination, but not yet that they were processed or uploaded. Broadcast traffic alone is not a reliable test. If packets are missing, initially limit the investigation to the source, filter, direction, transport, and virtual port group.

3. Capture and Flow at the Intended SPAN Port

Under Sophos Appliance Manager > NDR, record the displayed capture percentage for the specific intended SPAN port and the activity in the Total Flow graph during the 30-second window. Both must align in time with the pilot traffic. This demonstrates activity at the selected input; the displays prove neither complete packet capture nor the correct data scope, both directions, or a successful upload.

The current Sophos classification rates a SPAN port as healthy when at least 2 percent of network packets are unicast. This value is solely the minimum health classifier: it merely rules out a zero unicast proportion in the observed sample. An incorrect, partial, duplicate, outdated, or unsuitable feed can also meet the 2-percent threshold. The value therefore proves neither the expected source and direction, useful traffic, coverage, the displayed capture value, upload, nor detection. Older references to 100 percent unicast are not used as the current requirement.

4. Processing and Upload

Under Sophos Appliance Manager > NDR, record the displayed upload percentage for the same time window and compare its timing with capture and flow activity. This documents upload activity, but does not prove that every mirrored packet was uploaded or that a detection will subsequently be created. Connected primarily confirms the appliance connection and does not replace this evidence. If health, capture, upload, and drop signals differ, follow the systematic diagnosis of the appliance and sensor.

5. Operational Coverage

For each row in the coverage matrix, generate targeted, permitted test traffic and record the time, test device, expected segment, source, destination, and direction. Associate the evidence from stages 2 through 4 with this test. Only these samples show that the tested paths are captured in principle; they do not provide evidence for untested segments or time windows.

6. Harmless End-to-End Detection

Only after successful mirror acceptance should you perform the separate, approved procedure “Generate and Verify a Safe Sophos NDR Test Detection”. Test generation is not anticipated here. Verify the result for the expected test device and time window under Threat Analysis Center > Detections and link it to the preceding evidence chain. A test detection observed there proves the tested end-to-end path; it guarantees neither detection of every attack technique nor coverage of other paths.

Narrow Down Discrepancies Stage by Stage

If acceptance fails, investigate only the first stage without the expected evidence: the actual source path, direction, and filter; then destination cabling or virtual capture assignment; for ERSPAN, transport and matching tunnel values next; then capture/flow at the intended port; and finally upload and detection. A green status or at least 2 percent unicast does not skip any of these stages. Make only one change at a time and measure again using the same pilot and time window.

If only a direction or segment is missing, compare the coverage matrix with the actual physical or virtual path without preemptively adding more sensitive segments or all ports. If the rate is unusually high, check documented overlaps individually against counters and the visibility of the pilot traffic. This process ends with mirror acceptance and fault localization; for sensor, upload, or platform errors, continue with the diagnosis of the appliance and sensor.

Safely Roll Back Changes Made by This Procedure

Before each expansion, record the session ID, sources, directions, filters, destination, tunnel parameters, and baseline rates. The following rollback covers only mirror changes newly made during this procedure; it is not guidance for dismantling an appliance, cloud stack, or other infrastructure.

If problems occur, roll back in reverse order:

remove the most recently added local source; delete an AWS Traffic Mirror Session newly created for this procedure,
restore the most recently expanded filter to the documented pilot scope,
disable newly enabled ERSPAN or restore the previous tunnel values,
disable SPAN Port 2 if it introduced the new load or overlap,
restore the previous switch session if a physical mirror was changed,
check packet flow, drop rate, integration status, and pilot traffic again.

Rolling back the Sophos SPAN settings again requires Save and a VM restart before the change takes effect. The impact on other integrations on the same appliance must also be considered. Rollback is complete only when the status is not merely green again, but the previously documented pilot paths are visible without new duplicates or problematic packet loss.