Why Your VPN Sensor Never Sees the Branch VLAN Tag

A sensor on the VPN side sees two branch VLANs as plain IP traffic, and the tag that identified each branch on its own wire is gone. That is what a routed tunnel does: it recovers packets, not the Ethernet frames that delivered them. Whether the missing tag matters depends entirely on the question you are asking the sensor. Work the four checks below in order and you will know which observation point can answer it.

First, Establish What Your Tunnel Recovers

A TUN interface carries IP packets, so the branch frame's VLAN header stops at the router that pushed the traffic into the tunnel. A TAP interface carries Ethernet frames, which means tags can survive when the bridge and the VLAN admission rules allow them through. Read the interface type before reasoning about what a capture ought to contain.

Neither choice is a defect. The two designs answer different questions and leave the tag in different places.

Confirm the interface yourself instead of inferring it from the product name. The link details name the kind of device and show the flags in force, and a capture taken on a TUN device will not grow an Ethernet header because you asked for one. If tags do appear on a TUN capture, you are almost certainly reading a different interface or a tunnel that carries frames inside its payload. Note which case you are in before continuing.

Second, Place the Sensor Where the Object Still Exists

Three positions cover most routed designs: the branch Ethernet segment, the outer network between the tunnel endpoints, and the path after tunnel processing. Each one sees a different object, and the tag exists only at the first. Choosing a sensor position is a decision about which object the policy needs, not a matter of convenience.

Ask the policy question in terms the table can answer, and it usually resolves itself. If the rule needs to know which branch a packet came from, the prefix mapping downstream may be sufficient, but only while that mapping is accurate and unambiguous. If the rule needs to know which port the frame arrived on, you need the first position, because nothing downstream can reconstruct it. Sensors placed by habit rather than by question are how teams end up demanding a field the design never carried.

An Ethernet-carrying tunnel is a different design and needs its own check of what the endpoints preserve or rewrite. Selecting TAP on its own still does not define the bridge, the VLAN admission rules or the inspection policy.

Third, Earn the Source Context Instead of Trusting It

One address range per branch is the usual stand-in for VLAN identity, and it holds only while the mapping stays one-to-one. Overlapping prefixes, translation and a shared gateway each break that assumption in a way that looks like a data quality problem rather than a design one. Write the mapping down with its boundaries and say what happens to a packet that matches two rows. A prefix that appears in two branches should be an error you detect, not a coin flip you accept.

Context supplied by the client is not evidence of membership. It is a claim, and it belongs in a different column.

Where the distinction matters, use association data you control: which tunnel instance accepted the connection, which interface the packets arrived on, what the local route table says for that peer. A client-provided label is a useful hint and a useless authorization input. If the sensor cannot establish the association from its own side, the policy needs a broader rule rather than a confident guess.

Fourth, Confirm the Reply Path and What Decryption Misses

A sensor that sees only one direction can still look healthy, because requests keep arriving on schedule. Check the reply path explicitly, and check it for the same flow rather than for general reachability. Half-duplex visibility becomes a silent gap in any stateful conclusion you draw from it.

Recovering inner IP traffic is not the same as seeing the application inside it either, because TLS carried over the tunnel remains TLS.

ip -d link show tun0
tcpdump -i tun0 -n -e -c 5

Those two commands answer the interface question and show what the capture really contains, which is faster than arguing about the architecture. Substitute the interface name your design uses and run the capture while the flow you care about is active. When no tag appears on a TUN device, the finding is that the design routed instead of bridging, not that the sensor dropped data. Then either move the sensor to a position that can see the tag, or rewrite the rule in terms the current position can support.