A Guide to tcpreplay on Linux: Capture, Modify, and Replay Packets to Test Firewalls and IDS/IPS

Real-World Challenges When Testing Firewalls and IDS/IPS

When deploying a new firewall cluster or fine-tuning rules for Snort and Suricata, NetOps engineers inevitably run into the same dilemma: How can you be certain that your rules accurately detect attacks without accidentally dropping legitimate user traffic?

Using curl or ping is far too simplistic. Traffic generators like iperf3 only push raw throughput at Layer 4; they completely lack real-world application payloads, malformed TCP flags, and malware signatures. On the other hand, executing live exploit scripts in your lab makes pacing difficult to control, rendering 100% accurate session reproduction virtually impossible.

I learned this lesson the hard way during an intermittent packet loss incident on a payment gateway. The issue only surfaced during peak hours—between 2:00 PM and 4:00 PM—at roughly 5,000 CCU. By nightfall, the network was idle, and the on-call team obviously could not ask thousands of users to simulate production traffic at 2:00 AM for debugging. The most practical solution was to use tcpreplay to replay the exact pcap file captured during the congestion window.

What Is the tcpreplay Suite and How Does It Work?

tcpreplay is not just a single command. It is a comprehensive suite designed to edit and replay network traffic directly from .pcap files:

• tcpreplay: Reads packets from a capture file and injects them directly onto Layer 2 (Data Link) of the Network Interface Card (NIC). By bypassing the kernel’s entire TCP/IP stack, the sender can achieve line rates from hundreds of Mbps to tens of Gbps, depending on your hardware.
• tcprewrite: Directly edits packet headers. You can alter MAC addresses, map source/destination IP ranges, or recalculate checksums. When bringing a production pcap into a lab, the original IPs and MACs will inevitably mismatch your lab topology, making this tool essential for remapping.
• tcpprep: Splits traffic flows into separate client and server directions. The resulting .cache file allows tcpreplay to transmit across two distinct network interfaces simultaneously (for example, client traffic on eth1 and server traffic on eth2).

The workflow is straightforward: capture live production traffic once, rewrite the IP and MAC addresses to align with your lab environment, and blast it directly at your firewall or IDS/IPS to analyze its behavior.

A 5-Step Workflow to Capture, Edit, and Replay Packets

Step 1: Install the Tools on Linux

Most popular distributions include tcpreplay in their standard package repositories.

On Ubuntu / Debian:

sudo apt update
sudo apt install -y tcpreplay

On RHEL / Rocky Linux / AlmaLinux:

sudo dnf install -y epel-release
sudo dnf install -y tcpreplay

Verify the installation:

tcpreplay -V

Step 2: Capture a Traffic Sample (.pcap)

Capture 1,000 suspicious packets on your network interface using tcpdump:

sudo tcpdump -i eth0 -c 1000 -w attack_sample.pcap

Quickly inspect the captured file metadata with capinfo:

capinfo attack_sample.pcap

This command reveals capture duration, total packet count, and average bitrate.

Step 3: Modify MAC, IP, and Checksums with tcprewrite

If you retain external public IPs, your lab’s L3 switches and firewalls will immediately drop the packets due to routing or ARP mismatches. You must remap the headers.

Assume the following lab topology:

• Sender interface: eth1
• Simulated client IP (source): 192.168.10.50, MAC: 00:11:22:33:44:55
• Firewall/IDS gateway IP (destination): 192.168.10.1, MAC: aa:bb:cc:dd:ee:ff

Execute the rewrite command:

tcprewrite --enet-smac=00:11:22:33:44:55 \
           --enet-dmac=aa:bb:cc:dd:ee:ff \
           --srcipmap=0.0.0.0/0:192.168.10.50/32 \
           --dstipmap=0.0.0.0/0:192.168.10.1/32 \
           --fixcsum \
           --infile=attack_sample.pcap \
           --outfile=ready_to_send.pcap

Crucial Technical Note: Modifying IP headers or ports invalidates the original checksums. The --fixcsum flag forces tcprewrite to recalculate all IPv4, TCP, and UDP checksums. Without this flag, Snort or Suricata will silently drop the packets right at the interface level due to checksum verification failures.

Step 4: Replay Traffic Through the Network Interface

Depending on your test objective, choose one of the following three replay strategies:

Scenario 1: Real-time Replay

Best for evaluating IDS/IPS detection accuracy. This preserves the exact inter-packet timing recorded during the capture:

sudo tcpreplay --intf1=eth1 --realtime ready_to_send.pcap

Scenario 2: Rate Limiting and Looping

Ideal for determining performance thresholds. For instance, transmitting at a sustained 50 Mbps and looping 20 times:

sudo tcpreplay --intf1=eth1 --mbps=50.0 --loop=20 ready_to_send.pcap

Scenario 3: Maximum Throughput (Top Speed)

Tailored specifically for stress-testing firewall hardware capacity:

sudo tcpreplay --intf1=eth1 --topspeed ready_to_send.pcap

Step 5: Inspect Logs and Evaluate Results on IDS/IPS

Open another SSH session on your Suricata or Snort host to monitor alerts in real time:

# For Suricata:
sudo tail -f /var/log/suricata/fast.log

# For Snort:
sudo tail -f /var/log/snort/alert

If your rules match the signature correctly, alert logs will stream in sync with each replayed burst. If no alerts appear, verify two things: whether the rule syntax is valid, and whether the packets were dropped by the NIC before ever reaching the detection engine.

Conclusion

Packet replay eliminates guesswork from network troubleshooting. Armed with tcprewrite and tcpreplay, you can reliably reproduce virtually any network issue within a secure lab environment. Build a curated library of pcap files containing common attack vectors (such as SYN floods, SQLi, and specific CVE exploits). Whenever you update your rule sets, a quick run through your automated replay suite takes only minutes before pushing changes to production.