Client VLANs or a tagged trunk: pick the right OpenVPN mode

Two requests arrive with almost the same wording: put every VPN client into a chosen VLAN, or carry an existing VLAN trunk across the VPN. They are different products. OpenVPN's built-in VLAN-aware mode is a switch model for the first request, and it is not a synonym for transparent tag transport. Choosing the wrong one produces a design that looks configured and silently drops the frames you cared about.

What the VLAN-aware mode actually builds

With vlan-tagging enabled on a server-only TAP deployment, the daemon models its TAP device and each connected client as ports on an internal switch. Client ports are untagged, and their VLAN association is set on the server through the per-client vlan-pvid context rather than by anything the client sends. That is the whole point of the model: membership is a server-side decision about an authenticated peer. Nothing in the client profile needs to know which VLAN it belongs to.

The server's TAP side gets its own tagged or untagged acceptance policy through vlan-accept. Forwarding inside that switch only happens between matching VIDs, including when client-to-client is set, so two clients in different VLANs cannot reach each other through the server even though both are connected to it.

That model is an access-port model. Frames leaving a client are untagged, and the association is imposed by the server based on identity. Asking the laptop to tag its own traffic is asking for a different design.

Assignments must follow the authenticated client identity, not a value the client offers about itself. An omitted assignment is not a quarantine state either: the client lands on the default PVID, so a missing ccd entry is a silent policy decision rather than a neutral one.

What a transparent trunk requires instead

Carrying already-tagged frames end to end starts by turning the VLAN-aware processing off. The switch model and tag preservation are alternatives, and enabling both asks one feature to do the other's job.

Disabling it is only the beginning. The bridge at each endpoint and the physical switch ports must agree on which VLANs are permitted, which tag is native, and how untagged frames are treated. Extending an unrestricted trunk exposes far more broadcast domains than the two you meant to connect.

Frame size needs its own budget. A tagged Ethernet frame plus encapsulation is larger than the payload figure people copy from a guide, and an MTU that was fine for a routed tunnel is not evidence that a trunk path works.

Three conditions that decide the answer

First, does the client platform support TAP at all? Android and iOS do not, and macOS support is limited, so a fleet of mobile users rules out either TAP design regardless of how the VLANs are arranged. A routed TUN session carries IP packets, not Ethernet frames, and no amount of server-side VLAN configuration changes that. Check the fleet before designing the topology, because this condition is the one that cannot be worked around. It is also the condition most often discovered after the switch work is finished.

Second, who assigns the VLAN? If the answer is "the server, based on who authenticated", the switch model fits. If the answer is "the existing switch infrastructure, with tags that already exist", you need the trunk design.

Third, how much of the network should be reachable? The switch model keeps each client in one VLAN by construction. The trunk design is a bridge, and a bridge that is misconfigured joins broadcast domains that were supposed to stay apart.

Testing the choice you made

Connect one client that should be in the permitted VLAN and one that should not, then test from the real endpoint rather than from the server itself. Server-side reachability proves the bridge or switch exists; it does not prove which VLAN a client landed in.

ip -d link show tap0
bridge vlan show

On the server, the second command shows the VLAN membership of each bridge port, including whether a port is tagged or untagged. Compare that against the assignment you intended before you debug anything above layer two.

Record which of the two designs the deployment uses. A note that says "VLAN aware" is ambiguous, and the next engineer will assume whichever one they learned first. The OpenVPN VLAN reference defines the switch behaviour and the per-client context, and it is the shortest path to confirming which model you are running.