What an iftop Screen Can and Cannot Prove About a VPN

An iftop screen answers one question at a time: which host pairs are exchanging bytes through the interface you pointed it at. It does not answer whether every application is following a VPN policy, and an empty screen does not prove that nothing leaked. The gap between those two statements is where most leak-test arguments go wrong. Three conditions decide what the display actually means, and all three are visible in the command line you used.

Three conditions decide what the screen means

The conditions are which interface is being displayed, what the filter and the tool itself are hiding, and what the test actually exercised. Answer them in that order, because a mistake in the first one makes the other two meaningless.

The interface condition matters because a tunnel view and a physical view show different layers of the same traffic. Looking at the tunnel interface shows the flows inside the tunnel; looking at the physical interface shows the tunnel's carrier, plus whatever legitimate setup, control or local traffic shares that link. Neither view is wrong, and neither is the whole picture. Naming which one you are looking at is the difference between evidence and an impression.

Condition one: which interface is displayed

iftop takes the interface explicitly with -i, and its manual describes the behaviour when you do not: it picks one, which may be the external-looking device rather than the tunnel. That default is a reasonable choice for a bandwidth tool and a poor one for a leak test.

Always pass the interface, and write it down next to the result. A screenshot without the interface name is not reproducible.

Condition two: what the filter and the tool hide

iftop accepts a filter expression, and a flow the filter excludes is invisible by construction rather than by absence. The tool also performs hostname lookups to label addresses by default, and those lookups generate their own DNS traffic, which is traffic you did not intend to observe. -n disables the lookups and makes the display numeric; hiding the DNS rows afterwards is not the same as not generating the queries.

That distinction is worth stating plainly, because it appears in other tools too: suppressing the display of an activity is not the same as preventing it. If the DNS lookups are part of what you are testing, run the test with lookups off so the observation is not contaminated by the observer.

Condition three: what the test actually exercised

A single request from one application, to one destination, in one address family, proves something about that request. It does not prove anything about a different application, a different destination, or the other address family, and IPv6 is the family most often forgotten in exactly this kind of check.

So define the request before you start: a harmless destination, from the application you care about, in the family you care about, with the tunnel in its approved state. Then check the receiving side or the client's own diagnostics, because the far end knows what arrived in a way the local screen cannot. Then exercise the approved unavailable-tunnel case and see whether the traffic stops, which is the behaviour the requirement is usually really about.

DNS deserves its own observation. The recipient of the query and the route the query took are two facts, and a bandwidth screen shows neither of them.

Using iftop as supporting evidence

Only then does iftop add value, and it adds it as corroboration. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" shows whether the flow you expected appears on the interface you expected, with byte counts that make an idle claim checkable.

Compare that with ss -tnp for the socket-level view and ip route get for the route the kernel would choose, and you have three observations of one request instead of one impression of a machine. The iftop manual documents the interface selection, the filter syntax and the lookup behaviour, which are the three things a leak test depends on. A bandwidth screen locates activity; the route, the exceptions and the failure behaviour decide whether that activity meets the requirement.