One tc Shaper Does Not Cap Each VPN Client by Itself

The instruction sounds complete: limit every VPN client to 20 Mbit/s. It is not complete, and a single queueing discipline on the tunnel interface will not deliver it. Per client could mean per tunnel address, per device or per account, and each choice classifies packets differently. Before writing any rule, decide which one the requirement actually names.

Everything below concerns the distance between that sentence and something that works.

What "Per Client" Has to Mean First

A tunnel address is easy to classify and easy to recycle. A device is harder, because one account may carry several, and a device may hold several addresses, especially with IPv6. For a fairness policy the account is the most meaningful unit, and the hardest to spot in a packet header. Every definition implies its own counting key, so a policy that drifts between them will not do what the description claims.

Direction is the second missing word. Upload, download and combined are three different requirements, and a single egress rule on one interface rarely covers both paths.

Choose a Point Where the Client Is Still Visible

Every direction is defined against an interface. What leaves the server's tunnel toward a remote client counts as download for that client; what a client sends enters the tunnel and then leaves toward its destination. Pick a scheduling point for each direction and ask which fields exist there. Before source NAT, an upload still carries the client's inner address; after translation, a simple source match may no longer identify it.

Out on the encrypted path the headers belong to the VPN transport, so a filter matching inner addresses has nothing to match. A design may classify earlier and hand a mark to a later scheduler, though that handoff must be deliberate: packet marks, connection marks and scheduler classes are different state, not one value passed along.

Buckets Do Not Appear by Themselves

A token bucket attached to an interface shapes whatever traffic uses it; it does not mint a fresh bucket per source address. A class-based design instead sorts selected traffic into classes, with filters deciding membership, and the HTB manual separates a class's rate from its ceiling when the parent has spare bandwidth. If the intent is a hard cap, set the ceiling and decide the borrowing behaviour on purpose; do not treat every rate figure as an absolute maximum.

When the requirement is per client, a pair of transfers running at once should split a single allowance. Handing each flow the full rate is a different policy, and it survives any test that watches only one download.

Two Devices, One Account, One Allowance?

Limiting two device addresses separately never adds up to a single account-wide allowance, even when both devices log in as the same person. The same applies to a whole LAN translated behind one peer, or to additional IPv6 addresses the classifier never expected. Keep the address-to-identity association current, and remember that a stable address simplifies the map without authenticating its owner.

Define burst and queue behaviour too. Token buckets permit short bursts above the average, and buffering adds delay; policing excess and queuing it for later are different decisions with different symptoms.

For validation, run two transfers from one client, add a second client, and read the class counters each way.