Why a routed VPN capture never shows the branch VLAN tag

Captures taken on the tunnel interface will never show the branch VLAN ID, and that is a property of the design rather than a gap in the tool. A routed TUN tunnel carries IP packets, so the tagged Ethernet frame that carried them on the branch link ends at the router that routed them. If your policy question is about segments, the sensor position has to be chosen for that question before the capture starts. The VLAN field you were expecting has to be replaced by context you can defend.

Look at what the tunnel interface actually carries

TUN delivers IP packets to the host; TAP delivers Ethernet frames. A routed design uses the first, which means the packet that arrives after decryption has no link-layer header at all, and therefore no 802.1Q tag to read. Nothing was stripped in transit, because the tag never entered the tunnel. The inner packet begins at its IP header, so every field a VLAN-aware rule expects is simply absent.

Confirm the interface type before arguing about the capture, since a TAP device in the same deployment will behave differently and invite the wrong conclusion.

ip -d link show tun0
tcpdump -i tun0 -nn -e -c 20

The first command prints the device kind and its flags. The second prints link-layer headers for the first twenty packets, and on a TUN device the output starts at IP with no Ethernet block, which is the whole explanation in one screen.

Choosing TAP does not restore the tag either. A TAP device passes frames to a bridge, and what happens to the tag depends on the bridge's VLAN filtering and the port's configured membership. That is a separate design decision with its own failure modes.

Stand in one of three places and accept what it can see

On the branch Ethernet segment the tag is present, but the sensor only sees local traffic on that segment. On the outer VPN network the traffic is protected, so an observer learns endpoints and volume and nothing about the inner packet. On the TUN path after decryption the inner IP packet is available, with its addressing and ports, and without the branch frame. A trunked capture and a routed capture of the same flow therefore look like two different conversations.

Those three positions answer three different questions, and a single capture cannot be all of them at once.

tcpdump -i eth0 -nn -e 'vlan' -c 10
tcpdump -i tun0 -nn -c 10

Run the pair and compare. The first shows tagged frames and their VLAN IDs where the branch link is trunked to the host; the second shows the same conversation as plain IP after routing. If the first returns nothing at all, check whether the host port is an access port, because then the tag was already removed by the switch and no capture on the host will ever show it.

Replace the missing tag with a mapping you can defend

If policy distinguishes segments by IP prefix, write that mapping down together with its limits. Overlapping address ranges, source translation and a shared gateway can each make one prefix insufficient to identify where a packet really came from.

Trust the interface and routing context you control, not a label the client supplies. A header field that a peer can set is not evidence of membership, and an inspection rule that treats it as such is trivially bypassed.

ip route get 10.20.30.40
ip -br addr show

The first command reports the interface and source the kernel would use for a destination, which is the local view of segment attachment. The second lists addresses per interface so the prefixes in your mapping can be checked against reality rather than against the diagram.

Check the return path and the payload before trusting the result

An inspection point that sees only one direction will miss half the conversation, and asymmetric routing is common once a VPN is involved. Confirm that replies traverse the same sensor before you treat a one-sided capture as complete.

Recovering the inner IP packet also does not decrypt an HTTPS session inside it. If the policy question is about content rather than flows, the sensor position has to move again, and that decision belongs to the same design document.

Extending an unrestricted trunk to a sensor just to make a VLAN field appear enlarges the network boundary without answering the original question. Pick the position for the information the policy needs, record what it cannot see, and revisit the choice when the question changes.