The idea is to create virtual vlan tagged network interfaces in the host using Hyper-V virtual switch functionality (provided you don't have Intel or Realtek NIC; see the note at the end of this blog for details), then adding a bridge adapter to the virtual machine with the correspondent vlan interface.
One would assume by convention that using virtual machines is sufficient in terms of isolating what's running inside the VM from the host and the rest of the network, but that's not always the case. VMware Workstation provides three types of network adapters; Host-only, NAT, and Bridged network. Host-only network adapters provides access to the host machine only, NAT adapters translate the VM source ip to the host ip address, while bridging provides an adapter that acts as if it is physically connected to the host NIC.
Now, let's follow what happens when the VM gets compromised in each adapter case. If a Host-only adapter is given to the VM, the host is exposed to the VM directly and nothing else, assuming no host-based protections are in effect, the host could be vulnerable.
In a case of NAT adapter, all traffic originating from the VM destined outside the VM net, is masqueraded under the host ip address, so in addition to having access to the host, the VM has access to whatever the host machine has in the local network.
Bridging the VM adapter directly to the host NIC can also be problematic, the VM will have direct access and discovery of the local devices in the network.
The Better Approach
Since VMware workstation does not provide some sort of vmnet firewall, it is better to offload that function to the physical firewall and have better visibility. This can be done by providing entirely isolated networks using VLANS. VMware Workstation does not support handling of VLANS since they are mostly managed by the host NIC drivers, nevertheless there are workarounds.
The way it is done is by creating virtual interfaces in the host, each corresponds to specific vlan tag. Then bridging that interface to the VM adapter, effectively passing-through that vlan to the VM.
Let's consider the following scenario:
Provided that the host NIC supports trunking, creating a virtual interface that is bound to a specific vlan tag in the host and bridging that interface to the VM, allows better control and isolation hence achieves our goal.
Create VLAN interfaces with Hyper-V VSwitch
First you need to enable Hyper-V Services and Hyper-V Module for Windows PowerShell from Windows features, click OK and restart.
Then open PowerShell with admin privileges and create a new virtual switch
Create virtual adapters for each vlan you want to assign.
Add-VMNetworkAdapter -ManagementOS -Name VLAN10 -SwitchName External_network
Then configure the interface you just created to listen for the vlan tag needed
Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName VLAN10 -Access -VlanID 10
Now you have a virtual interface that is configured for a specific vlan. To have access to that vlan inside a virtual machine, simply change the settings from VMware Workstation Virtual Network Editor and have a vmnet that is bridged with the Hyper-V virtual NIC.
If the host machine participation is not needed in a specific vlan interface (maybe for security reasons), you can disable all services and protocols from interface properties except for 'VMware Bridge protocol'.
Caveat when using Hyper-V
Once Hyper-V is enabled, your Windows host actually becomes a VM, so your VMware Workstation VMs becomes nested, and their performance greatly decreases.
Note if you have Intel or Realtek NIC
Intel and Realtek provide utilities for Windows to add virtual adapters with vlan tag support. You can use them instead of the Hyper-V Virtual Switch method.