Marking Your VPN Port Does Not Prioritize Voice Calls

Marking the VPN's UDP port as high priority is the most common voice QoS change, and it does not separate a call from the file transfer sharing that tunnel. Both flows leave through the same encrypted socket. The mark tells the next hop that all of it matters equally, which is the same as telling it nothing. What protects a call is a trusted classification before encryption plus a queue you actually control.

The tunnel hides the flow you wanted to classify

Encryption replaces the inner headers with one outer header per tunnel. After that, voice and backup traffic present the same source, destination and transport port, so a classifier keyed on the tunnel port cannot tell them apart. Whatever you promote, you promote in bulk.

A DSCP value set by the originating application only survives if something copies it outward. OpenVPN 2.6 has passtos, documented with an IPv4 scope; IPsec applies its own copy or mapping policy at the tunnel boundary. Without that step the outer packet is marked with whatever default the tunnel interface uses, and the queue downstream never learns that a call is inside.

Copied marks deserve the same suspicion as any client-supplied value. A workstation can claim expedited forwarding for a backup job, so admission and remarking at the trust boundary belong in the design before the mark is believed.

Priority only counts where the queue forms

A saturated uplink is what turns a good codec into a robotic voice, and the queue that fills is usually in the access device or the provider's buffer. Shaping the outbound path to the usable rate, minus tunnel and link overhead, is what keeps that queue on hardware you administer instead of in someone else's buffer.

Fair queuing and active queue management help even without a voice class, because they stop one bulk flow from filling the buffer. CAKE on Linux bundles shaping, per-flow fairness and optional Diffserv classes in one qdisc, and the deployed network manager should own that configuration rather than a second competing queue setup. Without shaping, a class that outranks bulk traffic still waits behind a buffer that is already full.

Ingress handling is not useless, but it acts after the packet has crossed the receiving link. It can influence a responsive sender and it cannot refund delay already spent upstream, so it is a mitigation rather than a guarantee.

What survives the public internet

The Diffserv architecture describes treatment inside administrative domains, which is why a provider may ignore or rewrite a marking at a boundary. The opposite claim, that every network always strips it, is just as unsupported. The honest question is what this particular path is contracted and policed to do. Test that with a marked probe instead of repeating a rule you read somewhere.

Ask what the provider does with the class, then measure it. A marking that is preserved but not scheduled is decoration; a path that schedules without seeing the mark is a different problem, and the two need different fixes.

A measurement plan that isolates the stage

Run one ordinary call with a controlled competing upload, then repeat it on a wired link. Look at what the call lost, what the class counters recorded, and how close the interface runs to its real limit rather than the plan's headline speed.

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

If the voice class counter stays at zero, classification or mark copying is broken and no amount of priority will help. If the class counter moves locally while delay still climbs, the bottleneck is beyond your gateway. Neither result is fixed by raising the priority value.