VLANs are not just a way to segment your network; they can actively break your network analysis tools if you’re not careful.
Let’s see this in action. Imagine you’re monitoring a switch port that’s carrying traffic for multiple VLANs. Without proper configuration, Wireshark will see this:
No. Time Source Destination Protocol Length Info
1 0.000000 192.168.1.10 192.168.1.1 ARP 42 Who has 192.168.1.1? Tell 192.168.1.10
2 0.000150 192.168.1.10 192.168.1.1 ARP 42 192.168.1.1 is at 00:11:22:33:44:55
3 0.050000 192.168.1.20 192.168.1.10 TCP 66 192.168.1.20:54321 -> 192.168.1.10:80 [SYN] Seq=12345 Win=8192 Len=0 MSS=1460
4 0.050100 192.168.1.10 192.168.1.20 TCP 66 192.168.1.10:80 -> 192.168.1.20:54321 [SYN, ACK] Seq=67890 Ack=12346 Win=8192 Len=0 MSS=1460
This looks like normal traffic, right? But what if 192.168.1.10 is in VLAN 10 and 192.168.1.20 is in VLAN 20, and you’re expecting to see that separation? You don’t. Wireshark, by default, strips off the 802.1Q VLAN tag thinking it’s just part of the preamble.
The 802.1Q standard inserts a 4-byte tag into the Ethernet frame. This tag contains a 3-bit Priority Code Point (PCP) for Quality of Service (QoS), a 1-bit Drop Eligible Indicator (DEI), and most importantly for us, a 12-bit VLAN Identifier (VID). This VID is what allows switches to direct frames to the correct VLAN.
Here’s how you get Wireshark to see that tag. You need to tell it that the interface you’re capturing on is VLAN-aware. This is typically done via the command line when you start Wireshark or tshark (its command-line counterpart).
Let’s say you’re capturing on eth0. You’d start tshark like this:
tshark -i eth0 -f "vlan"
The -f "vlan" option instructs tshark to interpret incoming frames as potentially VLAN-tagged. Now, when you capture the same traffic, you’ll see something like this:
No. Time Source Destination Protocol Length Info
1 0.000000 192.168.1.10 192.168.1.1 ARP 46 Who has 192.168.1.1? Tell 192.168.1.10
2 0.000150 192.168.1.10 192.168.1.1 ARP 46 192.168.1.1 is at 00:11:22:33:44:55
3 0.050000 192.168.1.20 192.168.1.10 TCP 70 [VLAN 20] 192.168.1.20:54321 -> 192.168.1.10:80 [SYN] Seq=12345 Win=8192 Len=0 MSS=1460
4 0.050100 192.168.1.10 192.168.1.20 TCP 70 [VLAN 10] 192.168.1.10:80 -> 192.168.1.20:54321 [SYN, ACK] Seq=67890 Ack=12346 Win=8192 Len=0 MSS=1460
Notice the [VLAN 20] and [VLAN 10] in the Info column. This is because Wireshark now correctly identifies the 802.1Q tag and displays the VLAN ID. The frame length also increased by 4 bytes, reflecting the added tag.
On the graphical Wireshark application, you can configure this per-interface. Go to Capture -> Options. Select your interface, and then under the Capture Filter section, click the + button to add a new filter. In the Filter field, type vlan. Then click OK. This tells Wireshark to apply the vlan capture filter to that specific interface.
The underlying mechanism is that the capture driver (like libpcap or WinPcap) is instructed to pass the raw Ethernet frame, including the 802.1Q tag, up to Wireshark. Without this instruction, the driver might strip the tag before Wireshark even sees the frame, treating it as part of the frame’s preamble or header.
If you’re using a network tap or a SPAN/mirror port on a switch that’s configured to not tag traffic from specific VLANs (a common misconfiguration when sending traffic to a monitoring tool), you won’t see the VLAN information at all, even with the vlan filter enabled. The switch has already removed the tag before sending the frame to your capture point. Ensure your switch is configured to send tagged traffic to your monitoring interface if you need to see VLAN IDs.
If you’re capturing directly on a machine that’s part of a VLAN, and that machine’s network driver is configured to handle VLAN tagging (e.g., using vconfig on Linux or specific settings in Windows Device Manager for your NIC), Wireshark should see the tags. However, sometimes driver settings or conflicts can cause the tags to be stripped. In such cases, explicitly setting the vlan capture filter is the most reliable way to ensure Wireshark processes them.
A common mistake is to apply a display filter like vlan in Wireshark after capturing. This won’t work for showing the VLAN ID if the tag was stripped during capture. The vlan filter needs to be a capture filter, applied before or during the capture process.
The next step in VLAN analysis is often correlating the VLAN ID with specific traffic patterns or troubleshooting inter-VLAN routing issues.