In Cisco LAN switch environments the native VLAN is typically untagged on 802.1Q trunk ports. This can lead to a security vulnerability in your network environment. It is a best practice to explicitly tag the native VLAN in order to prevent against crafted 802.1Q double-tagged packets from traversing VLANs.
In many enterprise networks VLANs are used to separate the network into logically separated networks. Sometimes these networks contain computers that should be contained in separate trust domains but they are simply separated by VLANs but still connected to the same physical switch. Many organizations use network enclaves to separate their network to help prevent against threats in one domain from spreading to another. In more security-conscious environments these networks of different trust levels are physically separated from each other.
Now if two VLANs are routable then all bets are off. The packet will be routed at layer-3 between the two VLANs by Switched Virtual Interfaces (SVIs) configured on the layer-2/3 switch. The technique of tagging the native VLAN we are talking about applies to layer-2 VLANs that are supposed to be separated from each other logically, without layer-3 connectivity, but yet these VLANs ride across the same switched Ethernet LAN infrastructure.
It is possible to create crafted packets that are encapsulated with two 802.1Q tags. The outer tag is the local VLAN of the attacker and the native VLAN that is untagged. The inner tag is the destination VLAN of the attacker’s desired victim. When the packet is received by the local switch the outer tag is stripped off and the switch gladly forwards the remaining single-tagged packet toward the destination VLAN across a trunk port. There are tools such as Yersinia and Scapy that can be used to craft these attacks.
This issue has been documented extensively. In fact, my coauthor for our IPv6 Security book wrote a book for Cisco Press titled “LAN Switch Security: What Hackers Know About Your Switches” that covers these risks and proscribes solutions. Chapter 4 covers the security implications of using VLANs. Even though this book has been available for over a year and a half, about 90% of networks that I encounter are not using the native VLAN tagging technique to avoid this risk of VLAN traversal.
One of the key Cisco commands for helping determine the native VLANs and allowed VLANs on trunks is “show interface trunk”. This command will show your trunk ports and show you clearly the native VLAN ID. The command’s output will go on to tell you about what VLANs are allowed to traverse the various trunks you have configured, the VLANs allowed and active in the management domain, and the VLANs that are in spanning tree forwarding state but not pruned. This is a useful command to detect any inconsistencies on undesirable VLAN trunking configuration.
There are several ways to prevent these types of attacks double-encapsulated tagging attacks. One technique this is to simply tag all VLANs on trunk ports. That is simple enough. The other technique is to not use the native VLAN on trunk ports on any access port where an attacker may be located. This can be done by using the “switchport trunk native vlan [vlanid]” on the Ethernet switch’s trunk port interface and then removing that VLAN from the trunk port. It is also a bad practice to simply tag all VLANs across all trunk ports without regard to how the network should actually be configured. Therefore, it is better to explicitly permit only the specific VLANs that need to be allowed on the trunk. Below is an example of what that might look like.
interface GigabitEthernet1/1 switchport switchport trunk encapsulation dot1q switchport trunk native vlan 100 switchport trunk allowed vlan 100-200 switchport mode trunk allow vlan remove 100
The second method is to use the Cisco global command “vlan dot1q tag native” which will prevent the double-encapsulation attacks. This command globally works on all switchport trunks on that entire Ethernet switch. This command will make sure that the native VLAN is always tagged on every trunk on the switch. This is a great best practice and takes care of the issue with a single command. This command should be entered in every switch in the campus.
However, if you wanted to have a technique that can be applied on a case-by-case basis then there is a third technique that can be configured on the interface. On specific trunk ports you can simply use the “switchport trunk native vlan tag” Cisco command to achieve the same results but at the interface level. Below is what that configuration may look like. I imagine that entering this command on every trunk port may be cumbersome in some environments.
interface GigabitEthernet1/1 switchport switchport trunk encapsulation dot1q switchport trunk native vlan tag switchport trunk allowed vlan 100-200
Regardless of which technique you use it is important to recognize that the native VLANs are typically untagged and there is a risk to this practice. You should use these techniques to help protect your network from possible insider threats trying to traverse your VLANs.