Hi,
Hyper‑V port isolation relies on Private VLAN (PVLAN) semantics, so if you’re seeing broadcast traffic leak between isolated ports, it usually means the adapters are not bound to the correct PVLAN type. Each VM NIC has two attributes: the primary VLAN ID and the secondary PVLAN type. The primary VLAN ID is the base VLAN, and the secondary defines whether the port is promiscuous, community, or isolated. For isolated VMs, the primary VLAN ID must match across all ports, but the secondary type must explicitly be set to Isolated. That ensures they can only talk to promiscuous ports (like a router or gateway) and not to each other.
You can check this in PowerShell with Get-VMNetworkAdapterIsolation -VMName <VMName>. This will show the current isolation mode and VLAN IDs. If you need to correct it, use Set-VMNetworkAdapterIsolation -VMName <VMName> -IsolationMode Isolated -PrimaryVlanId <VLANID>. For the gateway or management VM, configure its adapter with -IsolationMode Promiscuous so that isolated VMs can reach it but not each other.
To verify isolation is working, the simplest test is to run a broadcast packet capture (for example with Wireshark) on one isolated VM while generating broadcast traffic from another. If the configuration is correct, the capture should show no broadcast frames arriving. You can also confirm by checking the Hyper‑V switch configuration with Get-VMSwitch and ensuring the PVLAN settings are applied consistently.
If broadcast traffic is still leaking, it usually means either the secondary PVLAN type was left at “Community” instead of “Isolated,” or the switch itself was not configured with PVLAN support enabled. Correcting those settings will stop the unwanted broadcast propagation.
I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!
Domic Vo.