Network TAPs and Packet Brokers: Visibility Guide

Network detection and response, intrusion detection and packet forensics are only as good as the copy of traffic they receive, and most visibility gaps start at the point where packets are copied. A sensor fed by an oversubscribed mirror port, a broker that sends half of each conversation to different workers, or a cloud mirroring session that silently stopped will all produce clean dashboards and missed detections. This guide covers the layer underneath the tools: where to copy traffic, when to use a network TAP or a switch mirror port, how a network packet broker should be designed, where decryption belongs, and how traffic mirroring works on Amazon Web Services, Google Cloud and Microsoft Azure. It is written for network and security engineers who build or run monitoring fabrics. For what to do with the traffic once it arrives (flow data, Zeek and Suricata metadata, full capture and retention), see the Network Monitoring and Packet Capture Guide.

Source note: cloud mirroring details below are summarised from the AWS, Google Cloud and Microsoft Learn documentation listed in the references, as checked in November 2026. Confirm against the official text before relying on it.

Key takeaways

Decide placement before hardware. Copy points should sit on trust boundaries: internet edge, data centre core, segment borders, remote access and partner links, and cloud transit points.
Use TAPs where completeness matters. A TAP copies every packet on the link; a mirror port is a best-effort copy the switch can drop under load. Evidence-grade and high-volume links deserve TAPs.
The broker is a security system, not plumbing. It decides what each tool sees, so filters, deduplication, flow-symmetric load balancing and masking must be designed, tested and change-controlled.
Cloud mirroring is encapsulated and metered. Mirrored packets arrive inside VXLAN (UDP 4789 on AWS), consume bandwidth, cost money per session or per byte and can stop without an obvious error.
Measure the copy, not just the alerts. Track drop counters, session health, flow symmetry and coverage of each boundary, or a broken feed looks exactly like a quiet network.

Where traffic should be copied

Start with a map of trust boundaries, not a list of switches. Each copy point should answer a detection or investigation question: what entered or left the organisation, what crossed between segments, and what a compromised host talked to.

Location	Typical copy method	Main tools fed	Notes
Internet edge, outside and inside the firewall	TAP on each uplink	IDS, NDR, full capture	Inside the firewall shows internal addresses after NAT; outside shows what was blocked
Data centre core and segment borders	TAP or mirror port on aggregation links	NDR, metadata, selective capture	Where east-west movement becomes visible
Remote access and partner connections	TAP after VPN termination	IDS, NDR, capture	Decrypted side of the VPN concentrator
Decryption zone	Decrypted copy from an inspection device	IDS, NDR, DLP	Highest sensitivity feed: restrict access tightly
Cloud transit or inspection VPCs and VNets	Provider traffic mirroring	NDR, IDS	Mirror at shared transit points rather than every workload
OT and industrial networks	Passive TAP only	Protocol-aware OT monitoring	No injection risk, no switch configuration changes on control networks

For OT, follow the OT Asset Visibility Guide: passive copy points are the norm on control networks.

TAP or mirror port

A network TAP is a hardware device inserted in a link that passes traffic through and sends a copy to monitoring ports. A mirror port (often called SPAN on switches) is a switch feature that copies traffic from chosen ports or VLANs to a destination port. Both are valid; they fail differently.

Factor	Network TAP	Mirror port (SPAN)
Completeness	Copies every packet on the link at line rate	Best effort: copies can be dropped when the destination is oversubscribed or the switch is busy
Oversubscription	Each direction gets its own monitor output, so a full duplex link is never squeezed into one port	Mirroring both directions of a busy port, or several ports, into one destination can exceed its capacity
Physical layer errors	Passes what is on the wire	Malformed or errored frames are usually not copied
Deployment	Needs a brief link outage to insert, and rack space	Configuration only, no outage
Failure behaviour	Passive optical TAPs need no power; active copper TAPs need fail-open behaviour on power loss	A configuration change or switch upgrade can remove the session silently
Tampering risk	Physical access needed	Anyone with switch admin rights can add, change or remove sessions

Decision guidance

Choose a TAP: for internet and data centre uplinks, any link where captures may become evidence, links above the speed of a spare switch port, and OT networks where switch changes need change windows.
Choose a mirror port: for short-term troubleshooting, low-volume segments, branch sites without TAP budget, and as a first step before TAPs are installed.
Small organisations: one TAP on the internet uplink feeding one sensor gives most of the value; add a broker once links outnumber tool ports.
Large organisations: TAPs on every boundary link feeding a broker fabric, with mirror ports reserved for ad hoc use and recorded in the change system.

A mirror port is also a security-relevant configuration. ATT&CK lists T1020.001 Traffic Duplication, where an adversary with access to network devices configures mirroring to copy traffic to a host they control, and T1040 Network Sniffing. Inventory every mirror session and alert on new ones.

Packet broker design

A network packet broker sits between copy points and tools. It aggregates many TAP and mirror feeds, then filters, shapes and distributes them so each tool receives exactly what it needs, at a rate it can process. The common functions:

Function	What it does	Design caution
Aggregation	Combines many feeds onto fewer tool ports	Sum of inputs at peak must not exceed output capacity
Filtering	Forwards or drops by VLAN, address, port or protocol	A wrong filter creates a blind spot that no tool reports
Deduplication	Removes copies seen at several points	Window too short leaves duplicates; too long can remove legitimate retransmissions
Flow-symmetric load balancing	Spreads traffic across sensors, keeping both directions of a flow on one sensor	Asymmetric hashing breaks session reassembly and protocol detection
Tunnel header stripping	Removes VXLAN, GENEVE, GRE or MPLS so tools see the inner packet	Keep the outer header for tools that need source context
Packet slicing	Truncates payload after a set number of bytes	Good for metadata tools, wrong for content inspection or carving
Masking	Overwrites selected fields such as payment card patterns	Apply before data reaches storage tools that many people can read

Flow symmetry is the requirement that breaks most

IDS and NDR engines reassemble sessions, so both directions of every connection must reach the same sensor process. The Zeek documentation describes this directly: the Zeek binary does not split traffic itself, a frontend does, packets are assigned by flow so all packets of a flow reach the same worker, and its AF_PACKET support uses symmetric flow hashes by default so both directions should land on the same worker. Check that the broker's hash uses the same fields in both directions, and that asymmetric routing (two firewalls, two uplinks) is collected at points where both directions pass.

Securing the broker itself

Management plane: put broker and TAP management on an out-of-band management network, with named accounts and MFA through central authentication, not shared local logins.
Change control: treat filter and map changes like firewall rule changes: reviewed, logged, and backed up so a known-good configuration can be restored.
Tool ports: monitoring outputs should be one-way where hardware supports it, so a compromised sensor cannot inject traffic back into the network.
Access to output: anyone who can attach to a broker output can read the traffic. Restrict physical access to the rack and logical access to the map configuration.

Where identity fits

The copied traffic contains credentials and tokens: cleartext protocols, API keys in unencrypted service calls, Kerberos and NTLM exchanges, and everything in decrypted feeds. That makes the monitoring fabric a store of secrets and the accounts that manage it privileged. Give brokers, TAP managers and cloud mirroring roles to named administrators and controlled service accounts only, and audit their use. Treat the automation account that creates cloud mirror sessions as a non-human identity with scoped permissions. See the Network Monitoring and Packet Capture Guide for handling credentials found in captures.

Decryption placement

Most application traffic is encrypted, so the visibility design must state what each tool will see. There are three practical options:

Metadata without decryption: TLS handshake fields, certificates, server names, TLS client fingerprints and flow timing remain visible to NDR on the encrypted copy. This is the default for most east-west traffic.
Inline decryption that exports a cleartext copy: an inspection proxy or firewall decrypts permitted categories and sends a decrypted copy to a broker port for IDS and NDR. Decrypt once and share the result, rather than running several decryption devices.
Decryption at the workload or load balancer: traffic is mirrored after TLS termination, for example from the tier behind a reverse proxy. This suits internal applications you own.

Decrypted feeds must be on separate broker ports, sent only to tools that need content, and excluded from long retention unless policy allows it. Respect exclusion categories (health, banking, legal) set by the decryption policy. See the TLS Inspection Guide for the decryption side.

Cloud traffic mirroring by provider

Cloud networks have no physical links to tap, so each provider offers a mirroring service that copies packets from workload interfaces to a collector. Providers are listed alphabetically. These are customer-side settings under the shared responsibility model.

Amazon Web Services: VPC Traffic Mirroring

Model: a session links a source (an elastic network interface), a filter (rules for what to mirror) and a target. Targets are the network interface of another instance, a Network Load Balancer with a UDP listener, or a Gateway Load Balancer with a UDP listener. Sources and targets can be in the same VPC or connected through intra-Region peering, a transit gateway, or a Gateway Load Balancer endpoint.
Format: matching traffic is encapsulated in VXLAN (RFC 7348) and sent to destination port 4789. Through a Gateway Load Balancer the appliance must parse outer GENEVE and inner VXLAN.
VNI is a label only: AWS states the VXLAN network identifier is caller-chosen, not validated or authenticated, and may not be unique across accounts that share a target. Do not use it as a trust boundary.
Sizing: mirroring adds 54 bytes of headers for IPv4 and 74 for IPv6; with the Gateway Load Balancer MTU of 8500, AWS gives 8446 bytes (IPv4) and 8426 bytes (IPv6) as the largest packets delivered to an appliance without truncation.
Behaviour to know: inbound traffic dropped by security groups or network ACLs is not mirrored; with a Network Load Balancer target, removing the UDP 4789 listener stops mirroring without an error. Deploy targets across at least two Availability Zones with cross-zone load balancing. If the appliance cannot handle out-of-order packets, AWS recommends a network interface target.
Availability: supported source instance types are listed in the AWS documentation; each active session is billed hourly until it is deleted, including when the source is stopped.

Google Cloud: Packet Mirroring

Model: a packet mirroring policy selects sources by subnet, network tag or instance name and sends copies to a collector: an instance group behind an internal passthrough Network Load Balancer. Selecting a subnet covers future instances too.
Filters: all IPv4 traffic is mirrored by default; filters narrow by protocol, CIDR range and direction, and can add IPv6. Traffic between two mirrored VMs is captured twice unless direction is restricted.
Sizing: mirroring uses the VM's own bandwidth. Google's example: 1 Gbps in and 1 Gbps out can become 1 Gbps in and 3 Gbps out once mirrored copies are counted. Filters reduce this.
Behaviour to know: VPC Flow Logs do not log mirrored packets; GKE pod traffic on the same node needs intranode visibility; a VM cannot mirror and collect on the same interface.
Access: compute.packetMirroringAdmin on the mirrored sources and compute.packetMirroringUser in the collector's project.
Availability: sources must be in one project, VPC network and region, with the collector in the same region; each policy takes up to 5 subnets, 5 tags or 50 instances. Google recommends Network Security Integration Packet Mirroring for new deployments that use third-party appliances at scale.

Microsoft Azure: virtual network TAP

Model: a TAP configuration on a VM network interface streams copies to a destination IP in the same or a peered virtual network, either a VM network interface or a load balancer (Microsoft suggests an internal load balancer in front of collectors for high availability). NICs from several subscriptions, including other Microsoft Entra tenants, can send to one TAP resource.
Access: Network Contributor, or a custom role with Microsoft.Network/virtualNetworkTaps/*, Microsoft.Network/networkInterfaces/read and Microsoft.Network/tapConfigurations/*.
Setup: enable peering before configuring TAP across virtual networks, and use direct virtual network peering between source and destination.
Behaviour to know: during the preview, a source VM is deallocated and started once before it is added, adding or removing a source can cause up to 60 seconds of network interruption, and live migration is turned off for source VMs.
Availability: as of November 2026 Microsoft documents virtual network TAP as a public preview in listed regions, for IPv4 traffic from VM network interfaces, with exclusions such as virtual networks with encryption enabled. Check the current page before design sign-off.

For the surrounding network controls, see the Amazon VPC Security Guide, the Google Cloud VPC and Cloud NGFW Security Guide and the Azure Virtual Network Security Guide.

How to implement

Define questions and boundaries: list the detections and investigations the fabric must support and map them to trust boundaries. Record the expected peak throughput on each.
Inventory existing copy points: every mirror session on every switch, every TAP, every cloud mirror session, and which tool each feeds. Remove unknown sessions after checking with owners.
Pilot one boundary: install a TAP or mirror at the internet edge, feed one sensor, and compare sensor packet counts against interface counters on the link for a week.
Add the broker: build maps per tool, enable deduplication and flow-symmetric balancing, and confirm symmetry by checking that the sensors report few one-sided connections.
Add decryption feeds: connect the decrypted copy on dedicated ports, with access limited to the tools and teams approved by policy.
Extend to cloud: mirror at transit or inspection points first, with filters, then add specific high-value workloads. Automate session creation in infrastructure as code so new workloads are covered and removals are visible.
Roll back safely: keep backups of broker configuration, insert TAPs during change windows with a bypass plan, and delete cloud sessions you no longer need so cost and access exposure end with them.

Detection and measurement

Monitor the fabric as carefully as the network it watches. Useful signals and metrics:

Drop counters: broker port drops, sensor capture drops and, on AWS Gateway Load Balancer endpoints, the PacketsDropped and BytesProcessed metrics.
Feed health: alert when any feed's volume falls to zero or below its normal baseline for a set period. A stopped mirror session looks like a quiet link.
Configuration changes: log and alert on new, changed or deleted mirror sessions on switches and in cloud audit logs.

Metric	Target
Boundaries with an active copy point	100% of boundaries in the map
Sensor capture loss at peak	Below 0.1% of packets
Connections seen in one direction only	Low and stable; spikes indicate asymmetry
Time to detect a dead feed	Under one hour
Mirror sessions without an owner record	Zero
Cloud workloads in scope covered by mirroring	Tracked per account, project or subscription

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	DE.CM-01	Networks and network services are monitored to find potentially adverse events
NIST CSF 2.0	DE.AE-03	Information is correlated from multiple sources
NIST CSF 2.0	PR.IR-01	Protecting the monitoring fabric from unauthorised logical access
NIST SP 800-53 Rev. 5	SI-4, SI-4(4)	System monitoring; inbound and outbound communications traffic
NIST SP 800-53 Rev. 5	AU-9, AC-6	Protecting captured data; least privilege for fabric administrators
NIST SP 800-53 Rev. 5	SC-7	Boundary protection, which defines where copy points belong
MITRE ATT&CK	T1020.001, T1040	Unauthorised mirroring and sniffing the fabric must detect and resist

Common failure patterns

Oversubscribed mirror ports: both directions of a busy uplink mirrored to one port of the same speed, so peaks are dropped exactly when attacks are busiest.
Asymmetric collection: outbound traffic leaves through one firewall and returns through another, so each sensor sees half of each session and detections that need reassembly never fire.
Silent cloud session loss: a load balancer listener removed, a target deleted or a workload rebuilt without its session, and nothing alerts. On AWS, removing the UDP 4789 listener stops mirroring without an error indication.
Decrypted traffic everywhere: cleartext copies sent to every tool and stored with ordinary retention, which turns the monitoring fabric into the largest store of sensitive data in the organisation.
Unmanaged mirror sessions: leftover troubleshooting sessions, or sessions created by an attacker with switch access, that nobody inventories.

Practitioner checklist

Map every trust boundary to a copy point, method and receiving tool.
Use TAPs on internet, data centre and evidence-grade links; record every mirror port session with an owner.
Size broker outputs and sensors for peak, not average, throughput.
Configure flow-symmetric load balancing and verify it with one-sided connection counts.
Place decrypted feeds on dedicated broker ports with restricted access and retention.
Mirror cloud traffic at transit and inspection points first, with filters, created through infrastructure as code.
Scope cloud mirroring roles to named administrators and controlled automation identities.
Alert on dead feeds, drop counters and any new or changed mirror session.
Keep broker and TAP management on an out-of-band network with central authentication and MFA.

Network TAPs and Packet Brokers: Reliable Traffic Visibility for NDR, IDS and Forensics