Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

9 module online course

Start now!
back to overview

OMG, VXLAN Is Still Insecure

A friend of mine told me about a “VXLAN is insecure, the sky is falling” presentation from RIPE-77 which claims that you can (under certain circumstances) inject packets into VXLAN virtual networks from the Internet.

Welcome back, Captain Obvious. Anyone looking at the VXLAN packet could immediately figure out that there’s no security in VXLAN. I pointed that out several times in my blog posts and presentations, including Cloud Computing Networking (EuroNOG, September 2011) and NSX Architecture webinar (August 2013).

Another conclusion I made in NSX Architecture webinar (slide 28, included below) was “transport network MUST be secure” (notice the RFC2119 use of MUST).

I would also like to point out that VXLAN is no different from most other layer-heaping technologies including GRE, L2TP, and MPLS, or earlier virtual circuit technologies like Frame Relay and ATM. The moment an intruder gains access to the transit network it’s game over… but of course it’s so much more fun to make the same point with examples like “I can insert UDP packets into a VXLAN network”.

Well, the presenter should have gone a step further: in VXLAN networks that use dynamic MAC learning instead of a decent control plane, the VTEPs would blindly accept whatever is injected from the outside, and create forwarding entries that would ensure the return traffic gets back to the intruder.

Does that mean VXLAN is broken? Not really, any technology can be dangerous in hands of clueless incompetents… including Kinder Surprise Eggs (there must be a reason they are banned in some countries).

As always, whenever you want to start using a new tool, you should understand how it works, and what its advantages and limitations are… after all, you want to call yourself an engineer, right? Oh, and don’t be surprised when the $vendors don’t tell you what the limitations and drawbacks are.

Finally, I would love to see security researchers shift their focus from “OMG, look how I managed to break it” to “there are some fundamental limitations of what can be done, and if you don’t know what they are you might get hurt… like in this example.”

And the ubiquitous “here’s more” list:

Please read our Blog Commenting Policy before writing a comment.


  1. Linux philosophy says that small (light) pieces interconnected together in the creative is the way to go. So the awareness of the component features is crucial and combining it with security stuff like ipsec / tls etc is just architecture choice (if the security is needed).
    Yes, 'OMG' here is a little bit surprising

  2. Our security team is responsible for security measures not the network team. If you have the intruder in your castle, you have other serious problems.

  3. Although VXLAN does not have native encryption there are ways to resolve this. Cisco has CloudSec for VTEP-VTEP encryption and I believe it is also possible if you integrate MACSEC into your design

    1. Docker Swarm approaches it using IPsec:

  4. VXLAN control planes are like the garage where you park an unlocked car. Is the garage secure? Since the most popular VXLAN control planes are proprietary, we've really no idea!

    E.g., NSX-V's "hybrid" mode and hardware-VTEP support are both just as risky as flood-and-learn multicast VXLAN.

    (if Captain Obvious wants another OMG, point out that live migration puts unencrypted computer memory inside unencrypted packets on unencrypted wires)

    1. > (if Captain Obvious wants another OMG, point out that live migration puts unencrypted
      > computer memory inside unencrypted packets on unencrypted wires)

      Someone actually already did:

  5. Hi
    Is SPB-M more secure because of the mac-in-mac and some security in the control plane?

    1. It’s “more secure” (or so some “experts” would claim) because it’s not using IP transport, so it’s impossible to inject packets into SPB-M from external destinations... but if you manage to do that with VXLAN you have bigger problems than VXLAN anyway.

      However, regardless of what tunneling protocol you use, if it doesn’t have data plane encryption, and someone manages to get access to the underlay network it’s game over... doesn’t matter if it’s VXLAN, MPLS or PBB (what SPB-M uses).

      These challenges were known for decades (at least since the days of early MPLS), but that doesn’t stop so-called security researches from making sensationalist presentations.


Constructive courteous comments are most welcome. Anonymous trolling will be removed with prejudice.