Shaping OpenVPN Traffic: Which Interface Sees It?

Work through four checks: what you want to limit, which packet carries the information that identifies it, which interface the shaper can see, and what the router sustains while encrypting. Routers ship with both an OpenVPN page and a bandwidth page, and their coexistence proves nothing about either. The order matters, because a rule written against the wrong packet never matches, however correct its rate.

Start with the goal: cap a single device, share capacity fairly, or prioritise one application. Each needs a different match.

Name the Goal Before the Rule

A per-device cap needs a match on that device's address, which exists only inside the tunnel. Fairness between competing flows needs a queue they all share, not a rule per host. Application priority needs something that identifies the application, the hardest of the three once encryption removes inner headers from view. Writing the goal down first tells you which fact you need and where you could possibly obtain it.

A cap that works on direct WAN traffic is no evidence that the same host is covered inside the tunnel. The rule may be matching an address that never appears in the header the shaper sees.

Inside the Tunnel or Outside It

With a router-owned VPN client, many LAN flows travel inside one encrypted transport. Before encapsulation the router still sees the inner source and destination, so policy attached at that stage can classify per device. After encapsulation, ordinary equipment sees only the outer connection, and a match on the VPN port says nothing about which device is responsible. That one fact decides where the rule belongs.

Platforms differ in how they expose this. Some provide a shaper that queues and classifies on a tunnel interface; others treat limiters as interface rules that behave the same for VPN and non-VPN traffic; some do both with different capabilities. Read the firmware's own documentation for the interface it supports instead of copying an interface name from another vendor's guide.

Identify where addresses remain available, where translation happens and which queue actually controls the bottleneck.

Three Policies, Three Kinds of Evidence

A rate cap is proven by a sustained transfer from the capped device while another transfers at the same time. Fair sharing is proven by two flows reaching similar rates rather than one starving, which is a different measurement. Application priority is proven by an interactive task staying responsive during a bulk transfer, and by checking that the classifier recognised the flow at all. Each policy needs its own observation, and none is proven by a configuration page.

Classification deserves particular suspicion. An outer encrypted port match cannot recover every inner application's identity, so a rule that appears to prioritise one application may in practice be prioritising everything from that tunnel. Read the rule's counters rather than its intent.

Measure the Encrypted Workload, Not the Bare One

Shaping, classification and encryption compete for one CPU, and hardware acceleration may move traffic past the very rules and counters you are watching. A throughput figure from a plain routing test says little about the box under an encrypted and shaped workload. Test both directions, several representative clients, and a small interactive task alongside the bulk transfer. Loaded responsiveness matters more than the peak number on an idle link.

Include the exceptions in the measurement: traffic that should bypass the tunnel, both address families if both are in play, and what happens when the tunnel is down. A policy that behaves sensibly only while the tunnel is healthy is half a policy.

Write the specification as three lines: the traffic match, the enforcement point and the measured workload. OpenVPN plus QoS is not a specification.