In many of our Cisco courses, we learn that networking best practices often point to the non-use of the Native VLAN. But why is this?
It turns out there are security vulnerabilities that could result from having a VLAN not tagged across your trunk links. For example, there is the VLAN hopping attack.
Here is how this attack could work:
Step 1: A bad person at a customer site wants to send frames into a VLAN that they are not part of.
Step 2: This person double tags the frame (Q-in-Q) with the outer frame matching the native VLAN in use at the provider edge switch.
Step 3: The provider edge switch strips off the outer tag (because it matches the native VLAN), and send this frame across the trunk.
Step 4: The next switch in the path examines the frame and reads the inner VLAN tag and forwards the frame accordingly.
Notice this attack is unidirectional. The attacker can send traffic into the VLAN, but traffic will not return. Even still, this is obviously not something we want taking place.
What are possible solutions?
- Use ISL trunks in the cloud – this becomes less and less possible as ISL trunks fade away.
- Use a Native VLAN that is outside of the range permitted for the customer.
- Tag the native VLAN in the cloud.
2 thoughts on “An Example of a Security Exploit Due to the Native VLAN”
I think removing the native vlan concept might work well on a normal trunk. With 802.1Q, you can tag everything with the command under the trunk interface:
config-if#no switchport trunk native vlan
So a double tagged frame comes in, out tag removed but dropped because it doesn’t match any of the tagged vlans.
Yes – love it!