A VLAN (Virtual Local Area Network) allows a single physical network switch to be logically divided into multiple, separate networks, as though they were connected to entirely different physical switches — even though all the traffic is actually travelling across the exact same cables and hardware. 802.1Q is the IEEE standard that defines how this is actually achieved: by inserting a small tag into an Ethernet frame identifying which VLAN it belongs to.
Without VLANs (or an equivalent, more expensive approach of running genuinely separate physical switches for every network), most organisations simply couldn’t afford to keep dozens of logically distinct networks properly isolated from one another.
Why VLANs exist
Without VLANs, every device connected to the same physical switch exists on the same single, flat network, sharing the same broadcast domain — meaning every broadcast frame sent by any device is received by every other device connected to that switch. This creates two related problems as a network grows:
- Broadcast traffic doesn’t scale. A large, flat network with hundreds of devices generates a correspondingly large volume of broadcast traffic (ARP requests, for example — see the ARP page), which every single device has to process, even if the vast majority of it is irrelevant to most of them.
- There’s no logical separation between different groups of devices. A guest Wi-Fi device, an accounting department’s workstation, and a security camera might all end up on the exact same network, with no straightforward way to keep them apart, purely because they all happen to plug into (or connect wirelessly through) the same physical infrastructure.
VLANs solve both problems by creating multiple, separate broadcast domains on the same physical hardware — broadcast traffic on one VLAN never reaches devices on another, and devices on different VLANs can’t communicate at all unless a router (or a Layer 3 switch, which performs the same function) is specifically configured to permit and route traffic between them.
How VLAN tagging works
Access ports
A port on a switch configured as an access port belongs to exactly one VLAN, and the device plugged into it (a laptop, a printer, a security camera) has no awareness that VLANs even exist — it simply sends and receives ordinary, untagged Ethernet frames, exactly as it would on any other network. The switch itself is responsible for internally associating that traffic with the correct VLAN.
Trunk ports and the 802.1Q tag
A trunk port, by contrast, is used to carry traffic for multiple VLANs across a single physical connection — typically the link between two switches, or between a switch and a router. To keep each VLAN’s traffic properly identified as it travels across this shared link, 802.1Q inserts a small tag into the Ethernet frame itself, containing (among other fields) a VLAN ID — a number from 1 to 4094, identifying which of the up to 4,094 possible VLANs that specific frame belongs to.
When a switch receives an untagged frame on an access port, it adds the appropriate 802.1Q tag internally before forwarding it out across a trunk link. When a frame arrives back on an access port destined for an end device, the switch strips that tag back off first, since the connected device was never expecting to see it in the first place. This tagging and untagging happens entirely within the switching infrastructure — ordinary end devices, like a normal laptop or a Modbus-speaking industrial sensor, never need to know VLANs are involved at all.
Inter-VLAN routing
Because devices on different VLANs are, by design, unable to reach each other directly, something needs to sit between VLANs and make a deliberate decision about whether traffic should be allowed to cross from one to another. This is typically handled by a router-on-a-stick configuration (a single router interface, connected via a trunk port, configured with a separate logical sub-interface for each VLAN) or, more commonly on modern networks, a Layer 3 switch — a switch capable of performing routing functions directly, without needing a separate physical router device at all. Either way, this is the natural point at which firewall rules can be applied, deciding precisely which traffic is permitted to cross between, say, a corporate IT VLAN and an OT/industrial VLAN — directly implementing the kind of controlled, monitored boundary recommended on the Modbus and CAN Bus pages.
A practical example
A small business might segment its single physical network into VLANs like this:
| VLAN ID | Purpose |
|---|---|
| 10 | Staff workstations |
| 20 | Guest Wi-Fi |
| 30 | VoIP phones |
| 40 | Security cameras / building automation |
| 99 | Network device management |
Even though every one of these devices might plug into (or connect wirelessly through) the exact same physical switches and access points, each VLAN behaves as an entirely separate network — a compromised guest Wi-Fi device on VLAN 20, for example, would have no direct network path at all to a staff workstation on VLAN 10, unless a router had been specifically, deliberately configured to permit that.
VLANs and security
VLANs are widely used as a genuine, meaningful security control, but the assumption that VLAN separation is inherently unbreakable has been directly challenged by a few well-known attack techniques.
VLAN hopping describes a category of attacks that allow traffic to cross between VLANs without passing through the router/Layer 3 switch boundary that’s supposed to enforce that separation. Two common variants:
- Switch spoofing: Many switches support a feature called Dynamic Trunking Protocol (DTP), which allows a switch port to automatically negotiate whether it should become a trunk port, based on signals from whatever’s plugged into it. If this auto-negotiation is left enabled on a port that shouldn’t ever need to become a trunk (for example, an ordinary office wall socket), an attacker can plug in a device that deliberately mimics a switch requesting a trunk connection, potentially tricking the port into becoming a trunk and granting the attacker’s device direct access to traffic from every VLAN carried across it, rather than being confined to just one.
- Double tagging: This exploits a specific quirk in how 802.1Q handles a frame carrying two VLAN tags stacked on top of each other. Under the right conditions — specifically, when an attacker’s own access port happens to share the same VLAN as a trunk link’s “native VLAN” (the one VLAN on a trunk that’s conventionally left untagged) — a switch can be tricked into stripping only the outer tag and forwarding the frame onward still carrying the inner tag, causing it to land on a different VLAN than the one the attacker’s device was actually assigned to. This is a one-way attack (it doesn’t allow a full two-way conversation), but it’s enough to inject traffic into a VLAN the attacker shouldn’t have any access to at all.
Defending against VLAN hopping is mostly a matter of switch configuration discipline rather than any deep protocol-level fix: disabling DTP auto-negotiation and manually, explicitly configuring which ports are trunks; never using VLAN 1 (the factory-default VLAN on most switches, and consequently a common target) as the native VLAN, or ideally avoiding using VLAN 1 for anything meaningful at all; and explicitly tagging the native VLAN on trunk links rather than leaving it implicitly untagged, which closes off the specific mechanism the double-tagging technique relies on.
VLANs are a strong logical control, but not a substitute for genuine physical/network isolation in the highest-stakes environments. Given the misconfiguration risks above, and given how much can go wrong with a single mistyped trunk configuration, safety-critical OT networks (the kind discussed on the Modbus and CAN Bus pages) are often kept on genuinely separate physical infrastructure entirely, rather than relying purely on VLAN segmentation across shared switches, precisely because a VLAN misconfiguration is a meaningfully lower bar for an attacker to exploit than a fully air-gapped, physically separate network would be.
A misconfigured trunk port is one of the simplest ways segmentation quietly fails. Beyond deliberate attacks, a huge proportion of real-world “we thought these networks were separated” incidents come down to something far more mundane than a sophisticated hopping attack — a trunk port accidentally left carrying a VLAN it shouldn’t, or a new switch added to the network without its port configuration being checked against the intended segmentation design at all. This is a good, concrete illustration of a theme that runs throughout this site’s security content: a security control that exists on paper (documented VLAN design) is only as strong as its actual, ongoing configuration in practice.