TAP Bridge for One VLAN: Attach the Subinterface

A TAP client that reached the LAN before VLANs and stopped afterwards usually has a bridge still containing the wrong interface. Frame forwarding does not add a VLAN tag, so an untagged client frame sent to the physical uplink arrives untagged on a trunked port and is either discarded or lands in the native VLAN. The subinterface existing somewhere on the host changes nothing about the bridge's member list. That is the myth to kill first: the tag is applied by the interface that owns it, not by the host merely having one.

One VLAN extension means one layer-2 domain, and the bridge has to join that domain rather than the trunk carrying all of them.

The Tag Does Not Appear Because You Bridged the Trunk

Take a Linux uplink eno1 carrying VLAN 120 to a managed switch. The design that works for a single VLAN is tap_vpn bridged to br_vpn, with br_vpn containing eno1.120 rather than eno1. The VLAN subinterface applies the tag on egress and strips it on ingress, so the bridge only ever sees untagged frames for that one VLAN. Put the physical interface in the bridge instead and the same frames leave untagged on a trunk port, which is not what you planned.

Bridging the trunk with VLAN filtering turned off is no shortcut to the same result. It hands the bridge every VLAN on that wire, including the ones clients have no business seeing.

Two Legitimate Designs, One Tag Owner

A VLAN-aware bridge is the other valid arrangement: the trunk enters a bridge port, and per-port membership, PVID and tagged egress settings decide which VLANs pass. There the bridge owns the tagging, and adding a VLAN subinterface beneath it would install a second owner for one job. Both designs work; fragments of both do not. Decide which object applies the tag before editing any membership list.

The switch port has to agree with whichever design you pick. An access port carrying the VLAN untagged pairs with the physical interface as the attachment, while a trunk port pairs with a tagged subinterface. Adding a subinterface to a mismatched access port repairs nothing.

Move the Address with the Membership

In the subinterface design, the host's address for the bridged subnet belongs on br_vpn, not on the enslaved VLAN port where it may have lived before. Leaving it on the port can appear to work and then behave strangely, because the bridge forwards at layer 2 while the address sits on a member. Move it as part of the membership change rather than as a separate experiment.

Moving an address can cut off the administration path. Establish an independent recovery route, save the existing configuration through the distribution's own network manager, and avoid a competing startup script that will fight it after the next upgrade.

Client addressing needs the same care. A bridged VPN places clients in the extended subnet, so a pool must not overlap other leases or static assignments, and a DHCP-served arrangement has to be the one the LAN actually expects. A working layer-2 path says nothing about duplicate addresses.

Verify Membership Before Blaming Routes

Read the current state instead of the intended one: ip -d link show dev eno1.120 prints the VLAN id and its parent, ip link show master br_vpn lists bridge members, and bridge vlan show reports per-port membership and egress treatment. In the subinterface design, confirm that the TAP device and the VLAN device are the members. In a VLAN-aware bridge, check the port policy itself, since a bridge existing does not prove what it allows.

Then test one permitted client against a service in that VLAN, remembering that ARP, firewall policy and the reply path are separate concerns from membership. If you capture packets, note that hardware offload can change where VLAN tags appear in a trace. Keep the scope honest as well: a routed TUN client is not made a VLAN member by any bridge change, and client-to-client traffic does not replace the host-to-VLAN attachment.