VM connected to a Shared Subnet is missing from Security Group membership

Products

• VCF Automation

Issue/Introduction

When configuring dynamic Security Groups or VM Groups in VCF Automation using Namespace and label criteria, group membership behavior differs based on the subnet type:

• Successful Membership: VMs on subnets created directly for a namespace (Build & Deploy → Services → Network) join the group as expected.

• Failed Membership: VMs on Shared Subnets (Manage & Govern → Networking) are excluded from the group.

Because these VMs are missing from the group, they do not receive the firewall policies attached to that group.

Environment

• VCF Automation 9.1.0.0
• VCF Automation 9.1.1.0

Cause

A Shared Subnet can be shared with more than one namespace at the same time (and, for provider-level shared subnets, even across multiple organizations). Because of this, the subnet cannot be permanently associated with a single namespace the way a namespace-owned subnet can.

VCF Automation's Namespace-based Group criteria works by matching a namespace identifier that is automatically attached to each namespace-owned subnet. Since a Shared Subnet does not carry that identifier, the system has no way to recognize which namespace a VM on that subnet belongs to, and it is left out of the group.

Impact
- Affects only VMs connected to Shared Subnets. VMs on namespace-owned subnets are not affected.
- Dynamic Groups based on Namespace do not include these VMs as members.
- Firewall/security policies applied through such groups will not protect these VMs.

Resolution

There is currently no configuration to automate group membership for VMs on Shared Subnets.

To apply firewall policies to these VMs, you must implement one of these workarounds:

• Assign the VM or its explicit IP to a static Security Group instead of a dynamic group.

• Relocate the VM's network interface to a namespace-owned subnet, provided this aligns with your workload requirements.