In this blog post, we will look at what a Native VLAN is and how it works. But, before we dive into Native VLAN, let's have a quick look at Access ports and Trunk ports. If you are someone new to the world of networking, the terms access, trunk, tagged and untagged can be very confusing.
Cisco uses the terms "access" and "trunk," while HP/UniFi/Meraki/some other vendors use "untagged" and "tagged" ports to describe the same concepts.
Suresh Vina
Quick Recap on VLANs
VLAN stands for Virtual LAN, and it's a way to logically segment a network, even if all devices are connected to the same physical switch. Different vendors use slightly different terms when it comes to VLAN port types. For example, Cisco calls them access and trunk ports, while others might refer to them as untagged and tagged ports.
An untagged (or access) port is typically used to connect end devices like PCs or printers. These devices have no awareness of VLANs, they just send regular Ethernet frames. When the switch receives a frame on an access port, it tags it with the VLAN configured for that port before forwarding it internally or out via a trunk port.
Tagged (or trunk) ports are used between switches or to other network devices that understand VLAN tagging. When a tagged frame arrives at the other end, the switch looks at the VLAN tag and forwards it accordingly. If the destination is an access port, the switch strips the tag before sending the frame to the end device. As shown in the diagram, the PC sends a plain frame, the switch tags it with VLAN 10, forwards it through a trunk port, and the receiving switch removes the tag before delivering it to the second PC.
Native VLANs
Native VLAN is used to carry untagged traffic on a trunk port. When a switch receives untagged traffic on a trunk port, it automatically assumes the traffic belongs to the native VLAN.
When a frame with a native VLAN tag leaves a trunk port, the switch strips out its VLAN tag. However, when a frame with a native VLAN tag leaves a trunk port that has a different native VLAN configured, the frame will retain its original VLAN tag, as it doesn't belong to the configured native VLAN on the transmitting switch.
Native VLAN Use Case
Let's say we have an Access Point (AP) connected to a switch using a trunk port. The AP provides wireless connectivity for two different SSIDs: Office-WiFi and Guest-WiFi, which are associated with VLAN 10 and VLAN 15, respectively. The management traffic of the AP is associated using VLAN 100, which is set as the native VLAN for the trunk port. This configuration ensures that untagged management traffic is tagged with VLAN 100 before being forwarded.
To achieve this setup, we would configure the switch port connected to the AP as a trunk port and allow the necessary VLANs to pass through (10 and 15). Additionally, we would also set VLAN 100 as the native VLAN for management traffic.
Native VLAN Mismatch
A native VLAN mismatch occurs when two switches connected via a trunk link have different native VLANs configured on their respective trunk ports.
In a native VLAN mismatch scenario, untagged traffic from one switch's native VLAN is incorrectly tagged with the other switch's native VLAN on the receiving end. This mistagged traffic can then be forwarded within the wrong VLAN, potentially allowing unauthorized access to sensitive information or systems. It may also cause network loops when the mistagged traffic is sent back to the originating switch.
To avoid native VLAN mismatches, it is essential to ensure that the native VLAN is consistently configured on both ends of the trunk link. This will prevent potential security risks and network issues that can result from mismatches.
Native VLAN Security Considerations
An attacker could exploit a native VLAN mismatch to inject traffic into a VLAN they shouldn't have access. For example, an attacker connected to a switch with native VLAN 10 could send untagged frames that would be tagged with VLAN 10 by the switch. If the trunk port on the receiving switch is configured with native VLAN 20, the frames would be assumed to belong to VLAN 20 and would be forwarded accordingly.
To prevent these issues, it is crucial to ensure that the native VLAN is consistently configured on both ends of the trunk link.
