PVLAN-like Behavior with ACL on VXLAN Network

Private VLANs (PVLANs) are useful in multitenant environments where there is a need to provide access to single server for all customers while not allowing them to see each other and NAT or dedicated networks are not an option. Agent based backup with central backup server or VM monitoring are example of such use-cases.

There might be a constraint that does not allow the usage PVLAN. For example hardware that does not support it (Cisco UCS) or VXLAN logical network. The latter I used in one of my designs. There was a need for single backup network stretched over pods without L2 connectivity. VXLAN can overlay L3 fabric and thus create single network spanning the pods however VXLAN does not support PVLANs. If VMware NSX is used then distributed (in-kernel) firewall can be used instead. If vCloud Network and Security is providing the VXLAN networks then there is App Firewall (vShield App) which unfortunately provides significant performance and throughput hit as it is inspecting every packet/frame in user-space service VM. It also adds complexity to the solution.

Access Control Lists

As of vSphere 5.5 vSphere distributed switch (vDS) supports access control lists (ACL) at the portgroup level. The ACL configuration is available only via the vSphere Web Client in the vDS portgroup > Manage > Settings > Policies > Edit > Traffic filtering and marking section. The following configuration can be used to provide the similar behavior to private VLAN.

Rule 1: Allow VMs to Server

Action: Allow
Type: MAC
Protocol/Traffic type: any
VLAN ID: any
Source Address: any
Destination Address: MAC address of the promiscous server or router

Rule 2: Allow Server to VMs

Action: Allow
Type: MAC
Protocol/Traffic type: any
VLAN ID: any
Source Address: MAC address of the promiscous server or router
Destination Address: any

Rule 3: Allow ARP

Action: Allow
Type: MAC
Protocol/Traffic type: any
VLAN ID: any
Source Address: any
Destination Address: FF:FF:FF:FF:FF:FF

Rule 4: Drop all

Action: Drop
Type: MAC
Protocol/Traffic type: any
VLAN ID: any
Source Address: any
Destination Address: any

Screenshot of the final configuration:

ACL rules

Note: As with PVLANs there is still a security issue of the tenant misconfiguring VMs IP address and causing Denial-of-Service for another VM with the same IP address. There are ways to remediate it but out of scope of this article.

 

Advertisements

6 thoughts on “PVLAN-like Behavior with ACL on VXLAN Network

  1. I’ve also ran into the same issues regarding UCS not supporting PVLANs, or at least not passing PVLANs correctly through to a VDS. We couldn’t actually do VXLAN at the time (we wanted to have our IGMP snooping/querier done at the fabric interconnect, but the version of UCS firmware on the chassis didn’t support it yet), and after discussions with Cisco, we found the only way to support that was by introducing a N1KV.

    Not the best solution, but it’s another way to deal with the above scenario…albeit what you describe is far more desirable. (Sweet post, man :D)

  2. Hello Tom

    Regarding the note at the end of the post, have you addressed the ways to mitigate this risk of tenant using wrong IP address in another post or could you kindly share your thoughts on how to do this ?

    thanks

      1. Thanks Tomas. Have you yet seen some solutions automating this as well as integrating it with IPAM system having self service capabilities ?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s