Unless it has changed in the past couple of versions, NO, this is not possible with Workstation.
2 people found this helpful
Hate to reply to an old thread, but I spent hours looking for a solution on a VMWare 12 system with a Windows 10 host.
First of all, switching to the vmxnet3 driver gave the option for VLAN tagging in the driver's advanced settings. Just change ethernet0.virtualDev to "vmxnet3" in your VM's .vmx file.
Once that was done, I discovered that you must disable "Priority & VLAN" on the HOST LAN adapter that you are bridging... otherwise it drops all of the packets that contain tags targeting the VM.
Hope this helps someone else!
Hey Confuzed, Please don't hate replying to old posts, just made my day.
It also works with Workstation 11.5
Wow! Thank you so much. You are such a time saver
Then how should we set VLAN tag in guest OS? I just saw VLANID in device manager-->vmxnet3-->Advanced-->VLANID.
Do we have to set VLANID here? Or we can change it somewhere else? What about other Guest OSes? Like Mikrotik RouterOS? Or Linux? How can I use this valuable feature?
I tried this workaround and it didn't seem to work. I intend to configure VLANs inside the guests.
- Host: Windows 10
- VMware: Workstation 12 and 15 Pro
- Host NIC: Intel I350-T2 (2 port)
- Driver: e1i65x64.sys Version 188.8.131.52 (standard Windows 10 driver)
- One port of the NIC ("#2"), which I intend to use for VMs, has all protocols disabled except for VMware Bridge Protocol (and Wireshark npcap)
- A Linux guest has a VLAN virtual interface ("vlan20")
- For diagnosing this issue, I have another Linux system "Remote" connected directly to the Port #2.
- It also has a VLAN virtual interface ("vlan20")
When I send a packet out of the guest vlan20, it seems to work correctly:
- Sniffing guest eth0 with Wireshark, I see the VLAN tag was applied by the guest kernel
- Sniffing host "#2" connection, I see the VLAN tag
- Sniffing on "Remote" eth0, I see the VLAN tag -- this proves that I can transmit tagged frames
- Sniffing on "Remote" vlan20 interface, I see the packet with VLAN tag removed (as expected)
However, receiving packets does not work as expected. When I send a packet out of "Remote" (on a VLAN virtual interface "vlan20"):
- Sniffing "Remote" eth0, I see the VLAN tag was applied
- Sniffing host "#2" connection, I see the VLAN tag is missing
- Of course, the guest eth0 also shows no VLAN tag...
- ...and thus, guest vlan20 interface does not see the packet
So it appears that the Intel NIC driver is, for some reason, stripping the VLAN tag, even though the host should know nothing about VLAN 20.
I even tried disabling "Priority & VLAN" and all other offload features, but it made no difference.
You can only do it on the same workstation host if your trying it doing two, I have it working on my workstation esxi lab using Sophos utm. Tagging a bridged interface doesn't seem to work.
A colleague and I figured it out! It turns out the Intel driver was stripping the VLAN out of the frames.
This article explains how to enable "Monitor Mode" for the NIC. Apparently the "VMware Bridge Protocol" operates at the same level as a "sniffer":
Set "MonitorMode" or "MonitorModeEnabled" (or both if you're not sure!) to "1".