Using Flow Network Security and AHV for a Better PVLAN

The Problem: Security and Efficiency

PVLANs solve this problem by subdividing existing VLANs into smaller isolated logical segments. Here’s a quick summary of PVLAN features.

You can entirely isolate traffic within the subdivided PVLANs (using isolation ports, or I-ports), separating anything in the subdomain from anything else in the subdomain, while traffic can still flow in and out, usually to the Internet. This approach is helpful in a hotel use case, for example, or any untrusted user situation where the user needs Internet access, but you don’t want that user to access any of their neighbors.

In another use case, you can also allow traffic in the subdivided PVLANs to flow freely within the subdomains (using community ports, or C-ports) and to the Internet, while blocking subdomains from talking to each other. This configuration conserves IP addresses and VLANs while also providing separation. With this approach, you don’t need to burn an entire VLAN and subnet for each application; instead, all of the applications can be in the same VLAN and subnet, with the traffic boundaries located inside the PVLAN subdomain. This structure lets the administrator use the limited number of VLANs and IP addresses more efficiently.

PVLANs are great for enabling both of these traffic patterns, but they require vendor-specific switch configuration that isn’t always simple to understand. In the virtual world, they also require matching up the configuration between the hypervisor and the physical switch, which is time consuming and easy to get wrong.

There is a better way!

A Better Solution: Flow Network Security

Let’s look at the previous use cases—supporting untrusted users with isolation and creating subdivided groups with community ports—and see how we’d do the same thing with Flow Network Security and AHV. 

Untrusted Users: Secured Entity Isolation

To isolate a VM’s traffic from all other VMs in Flow Network Security, while still allowing outbound Internet traffic, just assign this VM a category that’s a secured entity inside an application security policy. Within application security policies, the secured entity has a special property that can disallow communication between all VMs in the same secured entity. This option appears in the Security Policy editing UI as “Can VMs in this group talk to each other?” 

In this example, the two VMs in Secured Entity “Environment: Testing” can reach outbound to the defined proxy or to any set of allowed destinations. However, the untrusted VMs in this secured entity cannot reach any other VM that is untrusted. This capability gives us the exact isolation behavior we used PVLAN to achieve, but it only took a single radio button to disallow communication in the tier.

The great thing about this approach is that we don’t have to do any configuration on the physical network. All of these VMs can be in the same subnet and the same VLAN, and still get the isolation behavior thanks to Flow Network Security. 

Subdivided Groups: Application Security Policy

To create a subdivided group inside Flow Network Security, we can use the same application security policy and change just one parameter on the Secured Entity to allow traffic within the group. The application policy can block all inbound and outbound communication, while still allowing traffic within the Secured Entity. We can even add specific allowed inbound sources and outbound destinations if desired.

VMs in “Environment: Testing” in this example can communicate with each other, but not with any other group of VMs, unless we change a setting to explicitly allow that communication as inbound or outbound rules. 

Changing the Question

Security policies in Flow Network Security control VM traffic independent of network address schemes. The administrator or architect can use a flat IP address space and a single VLAN to create many subdivided groups in just a few clicks, with no changes required to the physical network.

Thanks to Flow Network Security we can isolate environments and applications from each other while still allowing defined inbound and outbound communication—all without PVLANs.

©2024 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product and service names mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).