OMG, VXLAN Encapsulation Has No Security!

Every now and then someone actually looks at the VXLAN packet format and eventually figures out that VXLAN encapsulation doesn’t provide any intrinsic security.

TL&DR Summary: That’s old news, the sky is not falling, and deploying VXLAN won’t make your network less secure than traditional VLAN- or MPLS-based networks.

Let’s start with the old news bit. This is a slide straight out of my VMware NSX Architecture webinar (you can also watch the related video).

Typical overlay virtual networking encapsulations in mid 2010s

Typical overlay virtual networking encapsulations in mid 2010s

As I clearly pointed out at that time, you (RFC 2119) MUST make the VXLAN transport network absolutely secure – anyone gaining access to the VXLAN transport network can insert packets into any VXLAN segment and potentially glean packets traversing a VXLAN segment. The intruder can do even more havoc in multicast-based VXLAN implementations that rely on traditional Ethernet flooding-and-learning: packets sent from intruder’s IP address can overwrite MAC-to-VTEP mapping entries in VXLAN endpoints, allowing the intruder to attract traffic sent to a particular MAC address.

Not surprisingly (as VXLAN is based on VLAN forwarding model), it’s easy to do the same in any VLAN-based network. As soon as an intruder gains access to a trunked switch port or a core link, it’s game over. VXLAN is thus no less secure than traditional VLAN-based networks.

MPLS networks are not much better. Once you have access to an MPLS-based backbone, you can insert packets into any LSP. This was evident to anyone who wanted to spend a few minutes thinking about MPLS security in the last decades. For more details, see this excellent presentation by Enno Rey.

Diverting MPLS traffic would require more effort, particularly in layer-3 MPLS-based VPNs.

Is it possible to insert VXLAN packets (and thus send traffic to other segments) from an end host? Sure – all you need is someone crazy enough to connect a server (or a VM) to the VLAN used for VXLAN transport, probably through some misguided use of native VLANs. Unfortunately there’s no easy cure for stupidity or fat fingers (in unrelated news, it’s also possible to read physical disk of an ESXi server if someone is stupid enough to allow customers to craft their own VMX files).

VXLAN implementations using control-plane distribution of MAC-to-VTEP mappings (VMware NSX, Nuage VSP, Juniper Contrail, Cisco EVPN on Nexus 9K) are less vulnerable to traffic redirection attacks (unless, of course, they use a combination of control plane and dynamic MAC learning). They might also include anti-spoofing features, which would drop traffic sent from illegal source IP addresses (VTEPs), but that just shifts the problem to the core network, which has to validate source IP addresses based on input ports – how many times have you seen that done in a data center environment?

The best way to deal with this problem seems to be to reuse the best practices we used to build secure VLAN-based backbones: make sure it’s hard for an intruder to get access to the transport network. What I’m usually recommending in my consulting engagements is to build a separate leaf-and-spine fabric used solely for VXLAN transport, and never connect it directly to the data center core. This slide from the VMware NSX Architecture webinar illustrates a typical approach:

Use VXLAN only over secure transport infrastructure

Use VXLAN only over secure transport infrastructure

Need More Information?

Start with the free VMware NSX Architecture webinar, continue with Overlay Virtual Networking and VXLAN Technical Deep Dive webinars, and conclude with Designing Private Cloud Infrastructure and VMware NSX Technical Deep Dive.


  1. Tom Herbert from Google has been adamant about overlay protocols having some way to support authentication/encryption of VNI traffic while preserving entropy for load balancing. He (and by extension I would guess Google) don't want to just blindly accept traffic at a VNI endpoint because the VNID matches. This is where things like additional metadata in the header come into play, where you can add additional data for the actual endpoints to use to either accept or reject the packet.

    The GUE draft has an example of supporting an IPSec header and maintaining entropy by using the original packet's information. The issue with that is it requires the source do all of the encryption/encapsulation at one time, which is a lot of processing. GUE also has a metadata portion which can be used as someone sees fit and may also be used for security/authentication.

    With VXLAN-GPE (next version of VXLAN) there was some discussion around adding metadata fields, but I believe the agreed upon solution was to use the "NSH" protocol field and use a NSH header to carry any additional metadata. This would ensure backward compatibility with existing VXLAN.
  2. We at Cisco share the concern that VXLAN encapsulation does not provide any security by itself. To address this in a simple and efficient way, we invested in incorporating additional capabilities for confidentiality, integrity and availability for VXLAN networks, specifically with the usage of the BGP based EVPN control-plane.
    By using the existing BGP authentication, we introduced additional measures to not only ensure the integrity of the control-plane information but also added a "whitelist" methodology. Via the control-plane, we receive the list of neighbor VTEPs and add these IP addresses to a Whitelist.
    While receiving VXLAN encapsulated data packets, we only accept packets from VTEPs which were previously distributed and stored in the Whitelist. VXLAN encapsulated packets from an unknown VTEP (not in Whitelist) are considered invalid and will be discarded.
    Cisco is shipping this functionality today with VXLAN/EVPN for Nexus 9000 and will make it available to other Platforms once supporting VXLAN/EVPN
Add comment