How to sanitize a PCAP before sending it to a vendor

Support teams often ask for "a capture of the problem". The packets that show the problem also carry internal addresses, hostnames, and sometimes passwords and personal data. Sanitizing means giving the recipient what they need to diagnose the fault, and nothing more.

1. Know what a capture gives away

Before choosing tools, list what the file can reveal:

• Payloads: HTTP paths, cookies and form fields; credentials in clear-text protocols; email; file contents; DNS names, TLS server names and certificates; DHCP hostnames.
• Addresses: internal IP ranges and network layout, public IP addresses, MAC addresses (whose first half names the hardware vendor). IPv6 addresses built from a MAC address (EUI-64) contain it too.
• File metadata: a pcapng file can record comments, interface names, the capture filter, and the operating system, hardware and application that made the capture.
• Behaviour: timing and sizes alone can show what services exist and when people work. This rarely matters, but it can't be removed without destroying the diagnosis.

Then ask the recipient what they actually need. Most network faults (resets, retransmissions, slow handshakes, MTU problems) can be diagnosed from headers, sizes and timing alone. Application faults may genuinely need payloads, and then the honest answer may be a screen-share or an on-site session rather than a file.

2. Reduce it first

The safest data is data that isn't in the file. Cut the capture down to the conversation and time window that show the problem. In Wireshark, apply a display filter, then choose File → Export Specified Packets with All packets: Displayed. With tshark:

tshark -r incident.pcapng \
  -Y "ip.addr == 10.20.30.40 && tcp.port == 443" \
  -w reduced.pcapng

Keep both directions of the affected conversation, and its DNS lookup if name resolution is part of the problem. Keep the untouched original yourself: you may need to answer follow-up questions from it.

3. Strip payloads

editcap, shipped with Wireshark, can truncate every packet to a fixed number of bytes:

editcap -s 96 reduced.pcapng truncated.pcapng

Each packet's original length is still recorded, so Wireshark shows the true sizes and the TCP analysis keeps working. But a fixed length is a blunt cut:

• Too short loses headers: IPv6, IP options and TCP options push the transport header past 96 bytes, and the TCP analysis that needed it is lost.
• Too long keeps the start of every payload. Headers are short on UDP, so at 96 bytes a DNS query still carries its whole name; we checked, and every query name in a test capture survived.

Pick the length for the traffic in front of you (54 bytes covers Ethernet, IPv4 and a TCP header without options), and drop protocols the recipient doesn't need entirely, such as DNS or DHCP, with a display filter at the reduce step.

4. Replace addresses

Replacing addresses has to be consistent: the same original address must always become the same new one, or the conversations fall apart. tcprewrite, from the tcpreplay suite on Linux and macOS, can do this for IP addresses with a seed:

editcap -F pcap truncated.pcapng truncated.pcap
tcprewrite --seed=48213 --fixcsum \
  --infile=truncated.pcap --outfile=shareable.pcap

The mapping is deterministic, so anyone with the seed and tcprewrite can reproduce it: treat the seed like a key. tcprewrite can set MAC addresses to fixed values, but that collapses every host to one MAC, so check whether the recipient needs to tell hosts apart at layer 2. Things that are easy to miss:

• ARP: addresses inside ARP packets aren't IP headers, so not every tool rewrites them. Check them, or leave ARP out.
• Addresses inside payloads: DNS answers, SIP, FTP and HTTP headers carry addresses as data. Strip payloads first, then remap.
• Subnet structure: random replacement hides which hosts shared a subnet, and that is sometimes the clue. Some tools offer prefix-preserving modes; decide which matters more.

On Windows, TraceWrangler is a long-standing graphical option that reads pcapng and can replace addresses and remove payloads in one pass.

5. Drop the file metadata

Check what the file says about where it came from:

capinfos shareable.pcap

A pcapng file can name the capture machine's hardware and operating system, the interface, and carry comments. Converting to classic pcap with editcap -F pcap, as above, leaves all of that behind, since the older format has nowhere to keep it.

6. Check the result before it leaves

Open the final file and look for what you meant to remove:

# Any names left?
tshark -r shareable.pcap -Y "dns.qry.name || tls.handshake.extensions_server_name || http.host" \
  -T fields -e dns.qry.name -e tls.handshake.extensions_server_name -e http.host | sort -u

# Which addresses remain?
tshark -r shareable.pcap -q -z endpoints,ip

# Your own domain or hostnames, anywhere in the bytes
tshark -r shareable.pcap -Y 'frame contains "corp.example"'

Also check Statistics → Protocol Hierarchy for protocols you meant to drop. Then confirm the file still shows the problem: a sanitized capture that no longer reproduces the symptom wastes everyone's time.

Manual method vs PCAPNG Analyzer