In our recent Implement Layer 2 Technologies series, we examined Q-in-Q tunneling in great detail. In this discussion, I mentioned a big caution about the Service Provider cloud with 802.1Q trunks in use for switch to switch trunking. This caution involved the use of an untagged native VLAN.

You see, this configuration could lead to what is known as the VLAN hopping attack. Here is how it works:

  1. A computer criminal at a customer site wants to send frames into a VLAN that they are not part of.
  2. The evil-doer double tags the frame (Q-in-Q) with the outer frame matching the native VLAN in use at the provider edge switch.
  3. The provider edge switch strips off the outer tag (because it matches the native VLAN), and send this frame across the trunk.
  4. The next switch in the path examines the frame and reads the inner VLAN tag and forwards the frame accordingly. Yikes!

Notice the nature of this attack is unidirectional. The attacker can send traffic into the VLAN, but traffic will not return. Admittedly, this is still NOT something we want taking place!

What are solutions for the Service Provider?

  1. Use ISL trunks in the cloud. Yuck.
  2. Use a Native VLAN that is outside of the range permitted for the customer. Yuck.
  3. Tag the native VLAN in the cloud. Awesome.

You can leave a response, or trackback from your own site.

8 Responses to “A VLAN Hopping Attack”

  1. Chris Riling says:

    Quick and to the point… nice! :)

  2. stretch says:

    Just wanted to chime in here that modern switches are immune to VLAN hopping attacks, as can be proven by experiment. @stake did an assessment as early as 2002 demonstrating that such an attack was unsuccessful on Cisco’s Catalyst switches.

  3. @Stretch: Those VLAN hopping attacks were due to hardware implementation bugs. The one described here is a design/configuration error (and is probably still doable).

    @Instructor: An even better solution is MAC-in-MAC encapsulation (PBB, 802.1ah), but you won’t hear much about it from Cisco ;)

  4. kexts says:

    Just a quick comment:
    to be successful in this attack the port that user are connected on the switch have to be set to DTP (Dynamic Trunk Protocol) this way you can craft your packets (Q-in-Q) and unleash the attack. I can never do run this attack with a different configuration.
    Anyway switches Cisco are not coming from factory default with the ports set to DTP.

  5. Jit says:

    Top stuff. Easy to understand

  6. Andrey says:

    Why switch would accept tagged frame on the “switchport mode access” port ?

  7. Jeff says:


    Attacks can be performed with the trunk configuration of an access port with a voice vlan configured… and can be bi-directional. If you want to try for yourself, here’s how I recommend.

    - set up a VOIP network using G.711.

    - From a linux box that is daisy chained behind a Cisco 79XX ( i think I was using a 7940 when I did this), enable packet forwarding and start running a voip sniffer, such as vomit.

    - If you find a script that will arpspoof with vlan tags, great… I used my own python code. Surprisingly simple. Direct poisoned arp with a vlan tag (that of your voip vlan) towards a voip phone on another port of that switch, (double tag to traverse switches).

    - Now that the phone thinks your mac is that of the phones gateway… you are operating at layer 2 and your mac is now in the switches CAM, under the voice vlan.

    You can now record a phone call. I’ve done this on a catalyst 3750… I would consider that a modern switch, and a bidirectional attack.




Leave a Reply


CCIE Bloggers