Windows VLAN chaos: How do I stop Windows combining untagged and phone vlans?

Question

After a lengthly debug session, I discovered that our Windows10/Windows11 machines receive packets from our phone VLAN, strip the VLAN tags off the phone VLAN packets, and then forward the packets on, making the packets indistinguishable from packets on our regular untagged VLAN.

With the two networks smooshed together, the Windows machines randomly get IPv4 addresses from the untagged network (like they should), then the phone network (like they shouldn't), and back again. The breakage is clear to see in IPv6 - Windows gets IPv6 addresses on both the untagged VLAN and the phone VLAN at the same time and assigns these to the same interface.

Chaos ensues.

Is there a setting, a driver, some mechanism that would get Windows to do the sensible thing - receive untagged packets as it normally does, while utterly ignoring the VLAN tagged packets that it has not been told about?

MacOS and Linux machines work without any trouble.

Answer 1

We discovered the Windows networking stack has a bug where VLAN tags are stripped from network packets, and the now stripped packet is passed along. The effect of the bug is that all VLAN traffic and all non-VLAN untagged traffic are combined inside Windows, and appear to be on the same network. The rest of the network correctly believes the untagged LAN and the tagged VLAN are separate networks.

The subtle mismatches cause symptoms like the Windows machine negotiating an IPv4 address on the untagged LAN, and then later negotiating an IPv4 address on the tagged VLAN, triggering unexplained and sudden outages. IPv6 SLAAC addressing breaks straight away - the Windows machine sees two different announcements from two different networks, and immediately give itself two separate IPv6 addresses. With the IPv6 gateway being a link local address with an identical name on both networks, chaos ensues with upstream routing.

For Realtek network drivers, a registry entry called MonitorModeEnabled set to 1 tells the driver to pass the VLAN packets through "for monitoring purposes". This has the effect of the VLAN packets being dropped as they should be. We have not yet found a workaround for Intel adapters.