Network Traffic Capture

• Network Traffic Capture
  • Before you run a tool: where and how to capture
  • The Core Problem: Switched Networks
  • Capture Points
    • Host-Based Capture
    • Gateway / Router Capture
    • Switch SPAN / Mirror Port
    • Remote SPAN (RSPAN)
    • Inline Capture
  • Physical Tools
    • Passive Network TAPs
    • Aggregating TAPs
    • Active Regeneration TAPs
    • Protocol-Specific Considerations
  • Capture Strategies
    • Promiscuous Mode (Passive, On-Switch)
    • Configuring a SPAN Port (Managed Switch)
    • Replacing a Switch with a Hub
    • ARP Cache Poisoning (MITM)
    • SSL/TLS Interception
  • Capture in Virtual and Cloud Environments
    • Virtual Machine Hypervisors
    • Cloud Environments
  • Capture Points and Visibility Summary
  • Legal and Ethical Constraints
  • Key takeaways
  • References

Before you run a tool: where and how to capture

Capturing network traffic is a fundamental skill in network security — used for intrusion detection, incident response, protocol analysis, and vulnerability research. Before reaching for a tool, you need to answer two questions: where in the network can you see the traffic you want, and how do you get a copy of it to your analysis system? The tools themselves — tcpdump, Wireshark, and tshark — are covered in their respective pages. This page covers the architecture and strategy that precedes running any tool.

The Core Problem: Switched Networks

On a hub-based network (obsolete but instructive), every device sees every packet — the hub simply electrically repeats each frame to all ports. Capture anywhere, see everything.

Modern networks use switches. A switch builds a MAC address table by observing which MAC address sent frames from which port. Once learned, the switch forwards each frame only to the port behind the destination MAC. A host capturing on its own NIC in promiscuous mode sees only:

• Traffic destined for its own MAC address
• Broadcast frames (destination FF:FF:FF:FF:FF:FF)
• Multicast frames subscribed by the interface
• Frames sent before the switch has learned the destination’s port

This means that on a switched network, a host cannot passively observe traffic between two other hosts without additional techniques. Solving this problem is the central challenge of network capture strategy.

Capture Points

Where you place the capture determines what traffic is visible. The right capture point depends on what you are trying to see.

Host-Based Capture

Capturing directly on an endpoint or server. The NIC is placed in promiscuous mode, which instructs it to pass all received frames to the OS rather than discarding frames addressed to other MACs. In practice, on a switched network, this only adds value if the switch is also sending you extra traffic (via SPAN, ARP poisoning, or a hub).

What you see: All traffic the switch sends to your port — typically just your own flows plus broadcasts and multicasts.

Best for: Capturing your own host’s traffic; endpoint forensics; capturing on a server that carries interesting traffic by virtue of its role (DNS server, gateway, etc.).

Linux:

# Place an interface in promiscuous mode manually
ip link set eth0 promisc on

# tcpdump and tshark do this automatically when run as root
sudo tcpdump -i eth0

Limitations: You are limited to your own port’s traffic. Any traffic that never crosses your port is invisible.

Gateway / Router Capture

A router or firewall sits at a choke point — all traffic leaving or entering a network segment must pass through it. Capture here sees all inter-segment traffic.

What you see: All traffic crossing the gateway — north-south (to/from the internet or other networks). Does not capture east-west (host-to-host traffic within the same broadcast domain that never leaves the segment).

Best for: Monitoring an entire site’s internet traffic; capturing all DNS queries leaving a network; detecting C2 beaconing.

Common approach: Run tcpdump on the router’s WAN interface, or on a dedicated capture port if the router supports traffic mirroring. pfSense, OPNsense, Cisco IOS, and most enterprise firewalls support packet capture via CLI or GUI.

Switch SPAN / Mirror Port

A SPAN port (Switched Port ANalyzer — Cisco terminology; also called a mirror port) is a switch feature that copies frames from one or more source ports (or an entire VLAN) to a designated destination port where your capture device is connected. The switch does the copying in hardware — the destination port receives a copy of every frame from the source, without affecting normal forwarding.

    [Server A] ──── port 1 ──\
    [Server B] ──── port 2 ───>── Switch ──── port 24 (SPAN) ──── [Capture Host]
    [Server C] ──── port 3 ──/

What you see: Exact copies of all frames from the monitored source ports or VLANs, in both directions.

Best for: Passive, non-intrusive monitoring of specific segments or hosts without touching their traffic.

Configuring SPAN on a Cisco switch:

monitor session 1 source interface Gi0/1 both
monitor session 1 source interface Gi0/2 both
monitor session 1 destination interface Gi0/24

Configuring on a managed Linux bridge (e.g., Open vSwitch):

ovs-vsctl add-port br0 mirror-port -- set Interface mirror-port type=internal
ovs-vsctl -- --id=@m create Mirror name=m0 select-all=true \
    output-port=$(ovs-vsctl get Port mirror-port _uuid) \
    -- set Bridge br0 mirrors=@m

Limitations:

• Only one SPAN session is often supported per switch (vendor-dependent).
• If the monitored ports generate more traffic than the SPAN destination’s bandwidth, the switch will drop mirrored frames — you will miss packets under high load.
• The capture host’s NIC must be able to handle line rate from all mirrored sources simultaneously.
• Requires access to the switch’s management interface (not available on unmanaged switches).

Remote SPAN (RSPAN)

RSPAN extends SPAN across multiple switches by forwarding mirrored traffic over a dedicated VLAN to a capture switch in another part of the network. Useful when the capture station cannot be co-located with the monitored segment.

[Target Switch] --RSPAN VLAN--> [Aggregation Switch] ---> [Capture Host]

RSPAN requires VLAN support across all intermediate switches and careful capacity planning on the RSPAN VLAN.

Inline Capture

An inline capture device sits directly in the traffic path — every packet passes through it. Unlike SPAN (which copies), inline devices see the original traffic and can optionally drop or modify packets (making them suitable for IPS as well as capture).

[Upstream] ──── [Inline Capture Device] ──── [Downstream]
                         │
                    [Analysis Host]

The capture device typically has at least two network interfaces (a bump in the wire) and forwards traffic between them while copying it to a capture interface. Hardware taps (see below) implement this passively; software implementations run on Linux with bridging or a raw forwarding daemon.

Linux bump-in-the-wire with tcpdump:

# Bridge two interfaces and capture on the bridge
ip link add br0 type bridge
ip link set eth0 master br0
ip link set eth1 master br0
ip link set br0 up
tcpdump -i br0 -w capture.pcap

Best for: Environments where SPAN is unavailable; capturing on links between two specific devices; IDS/IPS deployment.

Limitations: Adds latency and a potential failure point. If the capture device fails or loses power, the link is broken (unless a hardware bypass switch or failopen tap is used).

Physical Tools

Passive Network TAPs

A network TAP (Test Access Point) is a hardware device inserted into a network link that passively copies traffic to a monitor port. It has no IP address, consumes no bandwidth, and is electrically passive — it cannot introduce latency, and most passive optical TAPs fail open (traffic continues to flow if the TAP loses power).

[Device A] ──── [TAP] ──── [Device B]
                  │
            [Monitor Port]

Passive TAPs come in two forms:

Copper (10/100/1000BASE-T) TAPs

Copper Ethernet uses separate transmit and receive wire pairs. A passive copper TAP uses transformer coupling to split each direction onto a separate monitor port:

• Monitor Port A: sees only traffic from Device A → Device B (the TX pair of Device A)
• Monitor Port B: sees only traffic from Device B → Device A (the TX pair of Device B)

This means a copper TAP requires two capture ports (or an aggregating TAP that merges both directions onto one port). Because physical splitting weakens the signal, passive copper TAPs work well at 10/100 Mbps but are unreliable at gigabit speeds — most gigabit copper TAPs use active regeneration.

Optical (fiber) TAPs

Fiber taps use an optical splitter — a passive glass component that diverts a fraction of the light signal (typically 50% or 70/30 split) to the monitor port. No electronics required; no failure mode that affects the main link; completely transparent to the devices on either side.

Common passive TAP products:

Using a Throwing Star TAP:

The Throwing Star has four RJ45 ports: two inline (A→B and B→A path) and two monitor ports (one per direction). Connect the two inline ports between the devices you want to monitor. Connect each monitor port to a NIC on your capture machine. Use tcpdump -i or Wireshark to capture on both NICs simultaneously, then merge the pcap files for full bidirectional analysis:

# Capture on both monitor interfaces simultaneously
tcpdump -i eth1 -w direction_a.pcap &
tcpdump -i eth2 -w direction_b.pcap &

# After capture, merge and sort by timestamp
mergecap -w combined.pcap direction_a.pcap direction_b.pcap

Aggregating TAPs

An aggregating TAP combines both directions of a link onto a single monitor port. This simplifies capture (one NIC, one pcap file) but requires that the monitor port can sustain twice the link speed — a 1 Gbps link between two devices may generate up to 2 Gbps of mirrored traffic.

Active Regeneration TAPs

At gigabit and higher speeds, passive copper splitting degrades the signal too much. Active TAPs use a PHY chip to fully receive the signal and re-drive it to both the pass-through port and the monitor port. They require power, which means they can fail — most enterprise active TAPs include a bypass relay that closes the inline path if the TAP loses power, preserving network connectivity.

Protocol-Specific Considerations

Some TAPs include on-board packet brokers that can filter, deduplicate, or load-balance traffic before it reaches the capture host — useful when capturing at high-speed links where sending everything to a single capture station is impractical.

Capture Strategies

Promiscuous Mode (Passive, On-Switch)

Works without any network modification. Effective when your host is the subject of the capture (you want to see your own traffic) or when the switch is poorly secured and leaks traffic (aging MAC table entries, flooding conditions).

Configuring a SPAN Port (Managed Switch)

The cleanest approach for monitoring a segment you have access to. No traffic manipulation; full visibility into the monitored ports; leaves the traffic path untouched. Requires switch management access.

Replacing a Switch with a Hub

Replacing a managed switch with an unmanaged hub forces all traffic onto a shared collision domain — every device sees every frame. Impractical on production networks and introduces a performance regression, but useful in isolated lab environments where you control all the devices and want the simplest possible setup.

ARP Cache Poisoning (MITM)

On a switched network where you cannot configure SPAN, a host can poison the ARP caches of two targets so that each believes the attacker’s MAC is the MAC of the other. Traffic intended for Target B is sent to the attacker’s MAC instead; the attacker forwards it to Target B, creating a transparent man-in-the-middle position.

Normal:   [A] ──> Switch ──> [B]
Poisoned: [A] ──> Switch ──> [Attacker] ──> Switch ──> [B]
                                  │
                             [Capture]

Tools: arpspoof (from dsniff), ettercap, bettercap.

# Enable IP forwarding so captured traffic continues to its destination
echo 1 > /proc/sys/net/ipv4/ip_forward

# Poison A's cache: tell A that B's IP has our MAC
arpspoof -i eth0 -t 192.168.1.10 192.168.1.20 &

# Poison B's cache: tell B that A's IP has our MAC
arpspoof -i eth0 -t 192.168.1.20 192.168.1.10 &

# Capture the intercepted traffic
tcpdump -i eth0 host 192.168.1.10 and host 192.168.1.20 -w mitm.pcap

Important considerations:

• ARP poisoning is active and detectable — it generates ARP traffic and changes state on target hosts. It is not passive.
• Without ip_forward enabled, traffic is dropped rather than forwarded — you become a denial-of-service attack on both targets.
• ARP poisoning on high-traffic hosts can overwhelm the attacker’s NIC or CPU.
• Dynamic ARP Inspection (DAI) on managed switches will drop spoofed ARP replies and may alert on the attack.
• Only perform ARP poisoning on networks you own or have explicit authorization to test.

SSL/TLS Interception

Encrypted traffic (TLS) cannot be read by network capture alone unless you have the session keys. Two approaches:

Key logging (preferred for controlled environments):

Most TLS implementations support the SSLKEYLOGFILE environment variable, which writes per-session symmetric keys to a file. Wireshark and tshark can use this file to decrypt captured TLS traffic in post-processing — no traffic manipulation required.

export SSLKEYLOGFILE=~/tls_keys.log
firefox &
tcpdump -i eth0 -w capture.pcap
# Later, load capture.pcap in Wireshark with Edit → Preferences → Protocols → TLS → Key Log File

See the tshark page for usage of -o tls.keylog_file: in post-processing.

TLS MITM proxy (for traffic from devices you do not control):

An intercepting proxy (mitmproxy, Burp Suite, Squid with SSL bump) terminates the TLS connection from the client and establishes a new TLS connection to the server. The proxy sees plaintext. This requires installing a trusted CA certificate on the client device.

Why? TLS clients verify the server’s certificate against a list of trusted Certificate Authorities (CAs). When the proxy intercepts, it presents its own certificate — signed by the proxy’s CA — instead of the real server’s certificate. Without your CA in the client’s trust store, the client rejects this certificate and aborts the connection. Adding the proxy’s CA to the trust store tells the client “I trust certificates signed by this CA”, allowing the interception to proceed transparently.

Capture in Virtual and Cloud Environments

Virtual Machine Hypervisors

Traffic between two VMs on the same hypervisor never hits a physical wire — it flows through the virtual switch inside the hypervisor. A physical TAP or SPAN port on a physical switch will not see this traffic.

VMware vSphere / ESXi: Enable Promiscuous Mode on the virtual switch’s port group. A VM with promiscuous mode enabled on its port group will receive all frames on the virtual switch, including traffic between other VMs.

vSphere Client → Networking → vSwitch → Port Group → Edit → Security →
    Promiscuous Mode: Accept
    MAC Address Changes: Accept
    Forged Transmits: Accept

Or configure a dedicated monitor port group mirroring all traffic to a capture VM (similar in concept to a physical SPAN port).

KVM / Linux bridge: Add a mirroring rule to the bridge:

# Mirror all traffic on br0 to capture interface vnet_cap
tc qdisc add dev br0 ingress
tc filter add dev br0 parent ffff: protocol all u32 match u32 0 0 \
    action mirred egress mirror dev vnet_cap

Proxmox / Open vSwitch: See the SPAN configuration above (OVS mirror).

Cloud Environments

Cloud providers implement their own virtual networking layers. Physical packet capture is not possible; instead, cloud-native mirroring features must be used.

AWS VPC Traffic Mirroring: Mirrors traffic from an ENI (Elastic Network Interface) to a target ENI or Network Load Balancer. Captured traffic is encapsulated in VXLAN and delivered to the target. Filter rules control which traffic is mirrored.

# Create a mirror session via AWS CLI
aws ec2 create-traffic-mirror-session \
    --network-interface-id eni-SOURCE \
    --traffic-mirror-target-id tmt-TARGET \
    --traffic-mirror-filter-id tmf-FILTER \
    --session-number 1

Azure VNet Flow Logs / Network Watcher Packet Capture: Azure Network Watcher can capture packets on a VM’s NIC and store them as pcap files in Azure Storage.

GCP Packet Mirroring: Mirrors traffic from VM instances, subnets, or instance groups to a Collector’s Internal Load Balancer. A Wireshark or tcpdump instance on the collector VM can then capture the mirrored traffic.

VPC Flow Logs (AWS/GCP/Azure): All major cloud providers offer flow logs — metadata records of network connections (5-tuple, byte counts, packet counts, timestamps) without full packet content. Flow logs are useful for traffic analysis and anomaly detection but do not contain payload data.

Capture Points and Visibility Summary

Legal and Ethical Constraints

Network capture is legally and ethically sensitive. The key principle: you may capture traffic on networks and systems you own or administer, or on which you have explicit written authorization to perform security testing.

Relevant US law includes:

• Electronic Communications Privacy Act (ECPA), 18 U.S.C. § 2511 — prohibits interception of electronic communications. Exceptions exist for system administrators monitoring their own networks, and for authorized security testing.
• Computer Fraud and Abuse Act (CFAA) — prohibits unauthorized access to computer systems. Capturing traffic on a network you do not have authorization to access may constitute a CFAA violation.
• State wiretapping laws — many states have their own interception statutes, some broader than federal law.

In practice: capture on the lab VMs and lab network for this course. Do not perform ARP poisoning, MITM, or SPAN configuration on networks other than your own lab environment without explicit written authorization from the network owner.

Key takeaways

• On a switched network a host sees only its own traffic plus broadcast/multicast — passively observing two other hosts requires help: a SPAN/mirror port, a TAP, a gateway vantage point, or an active technique.
• Where you tap decides what you see: host capture sees your own flows, a gateway sees north-south traffic, a SPAN port or TAP sees a chosen link or VLAN in both directions.
• TAPs are passive and undetectable; SPAN copies in hardware but can drop frames under load; ARP poisoning and TLS MITM are active and detectable — and only lawful on networks you own or are authorized to test.
• Encrypted traffic needs either an SSLKEYLOGFILE (decrypt in post with Wireshark/tshark) or an intercepting proxy whose CA you install on the client.
• Virtual and cloud traffic between peers never touches a physical wire — use hypervisor promiscuous mode/port mirroring or cloud-native mirroring (AWS Traffic Mirroring, GCP Packet Mirroring, Azure Network Watcher); flow logs give metadata, not payload.
• Capture is governed by the ECPA, the CFAA, and state wiretap law: capture only on the lab network for this course, or with explicit written authorization.

References

• Wireshark Wiki — Capture Setup. https://wiki.wireshark.org/CaptureSetup
• Wireshark Wiki — Ethernet capture. https://wiki.wireshark.org/CaptureSetup/Ethernet
• Hak5 Throwing Star LAN TAP Pro. https://shop.hak5.org/products/throwing-star-lan-tap-pro
• AWS VPC Traffic Mirroring documentation. https://docs.aws.amazon.com/vpc/latest/mirroring/
• Electronic Communications Privacy Act, 18 U.S.C. § 2511. https://www.law.cornell.edu/uscode/text/18/2511

Related course pages: Capturing traffic with tcpdump · Analyzing traffic with Wireshark · tshark on the command line · Network reconnaissance

🛠️ Maintenance note: vendor specifics drift — Cisco SPAN/RSPAN syntax, Open vSwitch mirror commands, and the cloud mirroring CLIs (AWS/GCP/Azure) all change between releases, so re-check the linked docs each term. TAP product lines and the SSLKEYLOGFILE decryption workflow also evolve. Legal citations are US-centric and not legal advice.