Mapping VLAN Tags to Virtual Private Cloud Subnets

In a typical virtualized environment, a VM sends untagged traffic from its virtual NIC (vNIC). By default, the virtual switch drops any traffic that carries an 802.1Q VLAN tag. To allow this traffic, a feature known as Guest VLAN Tagging (GVT) must be explicitly enabled on the vNIC’s port connection.

Let’s review how this is traditionally handled before diving into the simple and powerful method available in Virtual Private Cloud (VPC) subnets.

Traditional Guest VLAN Tagging (Trunking)

On a vSphere Distributed Port Group (dvPortGroup) or a VLAN-backed NSX segment, GVT is enabled by configuring the port as a trunk. This involves specifying a range of allowed VLAN IDs instead of just one.

In this trunking model, traffic sent by a VM with VLAN tag X is forwarded onto the physical network, still tagged with VLAN X. The physical network infrastructure is then responsible for handling that tagged traffic.

Guest VLAN Tagging on NSX Overlay Segments

Enabling GVT on an NSX overlay segment (configuring a VLAN range) works similarly at first. Traffic from a VM with a VLAN tag is injected into the overlay segment while retaining its tag. Because NSX sees tagged frames, it treats this as simple Layer 2 traffic. Consequently, most advanced NSX services that only apply to IP traffic (like routing, load balancing, or distributed firewalling) cannot inspect or process this tagged traffic.

To solve this, NSX also provides a VLAN mapping feature. This allows a single vNIC to demultiplex its tagged traffic across multiple segments. With this configuration, traffic sent by the vNIC with VLAN tag X is automatically stripped of its tag and injected as untagged traffic into the specific segment associated with VLAN X. Since the traffic is now untagged on the segment, the full suite of NSX features can be applied. This feature, using the concept of parent/child port, is described here: https://blogs.vmware.com/cloud-foundation/2025/08/29/from-vlan-tag-to-segment-using-guest-vlan-tagging-in-nsx/

---

Implementing VLAN-to-Subnet Mapping in a VPC

In the Virtual Private Cloud (VPC) model, there is no direct Guest VLAN Tagging trunk option on a subnet, but the VPC model provides a more powerful and simpler equivalent to the segment VLAN mapping/demultiplexing feature mentioned above.

The key difference is that this mapping is configured at the subnet level, not on a per-port basis, which dramatically simplifies management.

The Scenario: Before Mapping

Let’s walk through an example. We have a VM (VM1) that sends traffic tagged with VLAN 10. This VM is attached to a primary subnet named sub-nogvt. By default, sub-nogvt expects untagged traffic, so any frames arriving from VM1 with VLAN tag 10 are dropped.

The Solution: Subnet Binding

To handle this, we first create another subnet within the same VPC, named subnet-10. This subnet will receive VLAN 10 traffic, with the VLAN tag stripped.

Next, we create a subnet binding to map VLAN 10 traffic from sub-nogvt to subnet-10. This is done with the following single API call:

/policy/api/v1/orgs/{org-id}/projects/{project-id}/vpcs/{vpc-id}/subnets/{subnet-id}/subnet-connection-binding-maps/{map-id}

In our example, assuming the VPC is called “myVPC”, this translates to:

This binding instructs the VPC switching infrastructure to watch for traffic tagged with VLAN 10 on any port attached to sub-nogvt. When it sees this traffic, it strips the VLAN 10 tag and forwards the (now untagged) frame into subnet-10.

Now, if we attach a VM2 to subnet-10, VM2 will receive the untagged traffic that VM1 originally sent with VLAN 10. The mechanism works both ways and effectively creates a communication path, mirroring the NSX port-level mapping but configured at the subnet level.

---

Key Benefits of Subnet-Level Mapping

The primary advantage of this approach is that it applies to all VMs on the subnet automatically:

New VMs on the source subnet

If we attach VM3 to sub-nogvt, it automatically inherits this behavior. It can send VLAN 10 tagged traffic to communicate with VM2 without any new configuration.

New VMs on the destination subnet

If we attach VM4 to subnet-10, it can immediately communicate with both VM1, VM2 and VM3 using untagged traffic.

Intra-Subnet Communication

This binding also enables communication between VMs on the same source subnet. If VM1 and VM3 are both on sub-nogvt, their tagged VLAN 10 traffic would normally be dropped. 

With the binding, traffic from both VMs is forwarded to subnet-10, allowing them to communicate via the mapped subnet.

Conclusion: A flexible way of handling VLAN tagging

This subnet-level binding method provides a clean, scalable, and API-driven way to handle guest VLANs, ensuring tagged traffic can be properly processed by the full suite of VPC network services. And of course, a given vNIC can be bound to multiple subnets at the same time, using multiple VLAN tags: