VPC Networking with VCF NSX

This post is also available in: German

With version 4.0 of NSX (the network stack in VMware Cloud Foundation), multi-tenancy was introduced using projects and shortly afterwards expanded to include VPCs.

The introduction of VPCs (Virtual Private Cloud) at the network level provides a “self-service” for network, security and other network services in an isolated environment. Those responsible for the VPC can create networks and security rules (within their limits), thus relieving the burden on the network and security teams. It also enables the VPC owners to provide new services more quickly.

The network and security team can define guard rails for the VPCs at the project or global level in NSX and determine which resources can be used.

Shifting of responsibilities

The VPC construct transfers responsibility for network management, network security and other services to the VPC owner(s).

But…!!! The VPC owner is not necessarily a network or security expert…

Nobody wants the entire network infrastructure to come to a standstill or to end up in the press with a security incident because changes were accidentally made to the network infrastructure.

In order to be able to use the advantages of a VPC but at the same time not to endanger the infrastructure, appropriate security precautions must be taken.

In addition, it must be as easy as possible for the VPC owner to configure the network requirements themselves.

Wouldn’t it be nice if certain tasks could be delegated to the application managers?

NSX Networking for VMware Cloud Foundation – briefly explained

NSX is part of Broadcom’s VMware Cloud Foundation and provides the virtual network for the private cloud.

Using NSX provides virtual routing functionality on the ESX hosts (DR – Distributed Router), which is responsible for communication between the VMs.

Communication between VMs on different hosts takes place via Geneve Tunel (highlighted in yellow); the underlying network infrastructure “only” sees the Geneve Tunel endpoints of the individual ESXi servers, but not the communication between the virtual machines.

Communication in external networks takes place via the NSX EDGE, which removes the Geneve Tunel and propagates the internal networks to the outside using routing protocols (or static routing).

In addition, an L4-7 firewall can be activated in front of each individual VM and on the gateways using the VMware vDefend Firewall AddOn.

!!!The diagram is a high-level view and does not claim to be complete. It is only intended to help understand the basic structure required to form the VPCs!!!

The following picture logically emerges from this:

• The virtual machines are connected to a segment, which represents the respective subnet.
• The segments are usually connected to a Tier-1 gateway, which handles local routing between the segments.
• The Tier-1 gateway performs distributed routing locally on the ESX servers and can also provide other services such as NAT, firewall and DHCP. It also exchanges routing information with the Tier-0 gateway. Several Tier-1 gateways can be connected to a Tier-0 gateway.
• The Tier-0 gateway establishes the connection (using the NSX Edge, see Figure 1) to the external router, and the parameters for routing are set there.

Projects and VPCs in NSX

The introduction of projects and VPCs results in new roles that have different access rights to the virtual network structure.

In the current VCF(5.2)/NSX(4.2) version, a project is required to create a VPC. At VMware Explore 2024, it was announced, among other things, that native VPCs can also be created in VCF 9. -> https://news.broadcom.com/releases/vmware-explore-2024-vmware-cloud-foundation

The roles described below can also be implemented differently and different roles could also be taken on by a team.

NSX Enterprise Admin

The Enterprise Admin has access to all objects in NSX and is responsible for the router configuration for the external network. Together with the network team, they determine which routing protocols are used, which IP address spaces may be used in the private cloud and, together with the security team, they create the basic security rules. The Enterprise Admin should have sufficient network and security knowledge and ideally work closely with the respective teams.

In addition, the Enterprise Admin manages the individual projects (tenants). The following settings should be made for a project:

• Creation of quotas (how many resources are available to the project? Networking, security, inventory, etc.)
• Project name
• Assignment of the users/user groups that can access the project
• Determination of which gateway(s) the project can use to communicate externally
• Determination of the external IP ranges that the VPCs in the project can use
• Log identifier (to be able to clearly identify the VMs in the log)

Project Admin

The project admin can use the resources assigned by the enterprise admin (external router, external IP address spaces), but cannot change them. Unlike with a VPC, however, it is still possible to make additional configurations at this level that must be agreed upon with the enterprise admin.

The project admin manages the VPCs of his project. The following tasks are carried out to create the VPC:

• Creation of Qoutas (How many resources are available to the respective VPC? Networking, security)
• VPC name
• Assignment of the users/user groups that can access the VPC
• Assignment of the gateway through which the VPC can communicate externally (of course, only the gateways that have been assigned to the project are available)
• Assignment of the external IP ranges that the VPC can use
• Definition of private IP ranges (for the VMs that do not need to be accessible from outside)
• DHCP service (if desired. Either via the NSX management or external DHCP server)
• additional services such as default outbound NAT for all VMs in the private networks, default firewall rules, integration of the NSX Advanced Load Balancer.
• Basic switch settings (QoS, IP discovery, MAC discovery, etc.)

VPC user

The VPC user can create network segments (virtual switches) in their VPC and see which virtual machines are connected to the network segments.

With the VMware vDefend Firewall AddOn, firewall rules can be created within the VPC, as well as inbound and outbound firewall rules. Firewall rules created at the global level take precedence over the VPC firewall rules.

When creating a segment, the VPC user can choose between 3 network types:

• Isolated – There is no connection to a router and the IP network can be created freely
• Private – The segment receives an IP subnet from the private IP address space. The VPC admin selects the number of IP addresses required from a dropdown menu and NSX automatically configures the corresponding subnet mask and the default gateway. The VMs in a private segment can only be reached within the VPC. External communication is possible via NAT. For this purpose, one IP address per VPC is used from the external IP address space. The NAT settings are made automatically. However, it is also possible to create your own NAT rules both inbound and outbound in the VPC.
• Public – The segment receives an IP subnet from the external IP address space. Here, too, the VPC admin selects the number of IP addresses required from a dropdown menu. The VMs in a public segment can communicate externally without NAT and can be reached from outside.

Summary

By introducing NSX VPCs, companies can offer their internal customers a networking as a service model. This can reduce the burden on administrator teams and give users more flexibility, which helps to provide business-relevant services more quickly.

Clear structures and roles ensure that end users can use the resources but cannot damage them through incorrect input.

Next Steps

My next blog entry https://vrealize.it/2025/02/14/vcf-nsx-vpc-configuration-step-by-step-guide/ will include step-by-step instructions on how to set up the VPC in NSX and at the same time give a user in the vCenter access to the assigned networks.

A blog entry with automation is already being planned and will be published by the beginning of March at the latest.

Stay tuned – As soon as VCF 9 is available, I will write another article about the changes in NSX.