WSL2 and VLAN on Intel NIC -> No network access #6410
Labels
Comments
|
Thanks for reporting the issue @flobernd. WSL2 should use a NATed network, so something weird is probably happening, let's have a look at logs. Can you please follow these instructions and share the script output, and both |
|
Sure, will post the results here when I have some time to check it. |
|
@OneBlue Chiming in with the log output:
Output: |
|
Same behaviour here |
|
me2 unfortunately |
|
I'm facing same issue, and I known them:
|
|
Long story short:
Fixing Issue 1: Problem: Your WSL2 clients are sending packets out a tagged VLAN interface on the host, something in network stack or WSL2 client doesn't like this, so packets are dropped. Quickest Solution:
The downside of this approach, is that all of your Windows 10 host machines default routed traffic will be sent out the untagged vlan (for me, I used to ship down a specific VLAN with fancier firewalling rules on the firewall, IPS/IDS etc). It's not a deal breaker, but annoying that it's needed. There are other possible solutions I'm looking at around weak/strong multihoming and/or PBR/Source Routing, but the complexity goes way up, might introduce security risks if you aren't careful, and might not work with WSL2 exactly the way it would with a real host or full VM. Anyway, hope that helps someone. Took an hour of mucking about to solve this after coming back to using WSL after not having touched it for a year. Upgraded to WSL2 just to discover that it broke all the networking....Anyway, running all WSL2 clients happily again, without impact to the VLANs, and mostly without adversely impacting network functions of default routed traffic from the host. |
|
@IAmIlliest Thanks for the guide. Sadly this approach does not work for me because of the current network topology and isolated VLANs. Anyways, still hoping for a proper fix from the Microsoft guys 😋 |
|
having the same challenge. However, untagged network is still reachable from WSL2 without any of the steps above. VLAN2 is not. From Windows Powershell, both VLANs are reachable. |
|
I guess im in this boat too :) |
|
Linux Guests don't do "Vlans" natively and you need to configure them to do so. This is an issue I have had with various Linux distros (both VMs and physical servers) over the years. To get them to understand VLAN's you need to configure sub interfaces under the main one. The Red Hat guide is pretty clear and concise. It can be found here. . Config may vary slightly depending on your flavour of *nix but broadly it's the same across all. So this isn't a MS issue, this is an issue with the guest itself. Fix the network config on the guest with the specific VLANS you need, and it uses trunks and VLANS just fine. :D edited to for clarity |
|
@SnowWombat This sadly is not the case here. The Windows host has a tagged VLAN adapter (this is handled by the Intel driver). WSL should be able to use this one transparently without any changes to the guest OS. It just uses the wrong adapter (it should use one adapter that has a default gateway assigned, but it does not do that) and there is no way to configure that behavior. |
|
"WSL should be able to use this one transparently without any changes to the guest OS" This has never been my experience with *nix VMs hosted on MS hosts where VLANs are involved, WSL or otherwise. Same with physical *nix hosts where VLAN's are involved. You always have to do the above config to get them to behave properly. The guest doesn't even add the VLAN field to the packet unless you do, which results in the behaviour described above. If the VLAN part of the packet is missing, then it will always default to the "untagged" Vlan. The Windows Host won't add the VLAN field to the packet coming from the VM, it just blindly passes it on. I have a client who has this exact issue, so we'll test my fix and get back to you all if it resolves the problem, or if I come up with a work around. Watch this space. :) |
|
@SnowWombat The Intel driver creates a pseudo network interface and indeed automatically tags it with the configured VLAN id. I can set this as an upstream interface in Vmware Workstation and get the expected results -> all traffic comming from the VM is tagged with the correct VLAN ID. This works without any changes to the guest (with Windows and Linux guests). Basically the driver acts the same like a managed switch with a tagged VLAN port. You are speaking about untagged ports / interfaces. In these cases it's ofc up to the software side to add proper VLAN tags. This does not apply to my initial issue tho. |
|
Same problem,, any updates on this matter? |
|
Same issue here. I'm not 100% sure but this seems to be the same issue as #6001 |
|
Having exactly the same issue here |
|
Hi. Can you please collect networking logs by following the instructions below? |
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Steps to reproduce
Expected behavior
WSL2 subsystem uses the virtual VLAN adapter for network access.
Actual behavior
WSL2 subsystem seems to use the "native" network adapter which prevents all network access from the linux system to the LAN or WAN.
The text was updated successfully, but these errors were encountered: