Everything so far has been pass or block. Real links are messier: they add delay, lose packets, and run out of bandwidth. The firewall can recreate all three on purpose, which is how you test how an application behaves on a bad connection without waiting for a bad day.
The tool is tc (traffic control) on the firewall. Two parts:
- Bandwidth limiting uses
tbf, and it’s shown here with real before-and-after numbers from the lab. - Delay and loss use
netem, a kernel feature not every host has. Where it’s available (most desktop Linux and WSL2), the commands are here; the numbers are yours to read, because a measurement only means something from your own run.
You need: Phase 1 finished. iperf3 (the throughput tool) is in the images.
| Step | What you'll do | Time |
|---|---|---|
| 0 | Set up, and measure the baseline Start a throughput test between the client and the server, and record the link's speed before any shaping. | 10 min |
| 1 | Cap the bandwidth Limit the link to a slow speed and measure the drop, the one shaping this lab verifies with real numbers. | 10 min |
| 2 | Add delay and loss Use netem to make the link slow and lossy, and watch latency climb and packets disappear. | 15 min |
| 3 | Shape, measure, restore Pull the phase together: the firewall can pass, block, or shape, and every change is one command away. | 5 min |