WSL2: ifconfig not showing all network connections

[xibalbus]

This is almost identical to the issue that was found in original WSL at:

#2685

Version 2004, Build 19041.84

This is a SonicWall VPN through Win10 VPN.

Output of sudo cat /proc/net/dev

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
 bond0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth0: 31998563   29285    0    0    0     0          0      1216   484606    6680    0    0    0     0       0          0
    lo:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
dummy0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

output of ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.227.60  netmask 255.255.240.0  broadcast 172.17.239.255
        inet6 fe80::215:5dff:fe93:3343  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:93:33:43  txqueuelen 1000  (Ethernet)
        RX packets 29277  bytes 31996835 (31.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6680  bytes 484606 (484.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

A full ipconfig shows

PS C:\WINDOWS\system32> ipconfig

Windows IP Configuration


Unknown adapter Local Area Connection 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Ethernet adapter Ethernet:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Wireless LAN adapter Local Area Connection* 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Wireless LAN adapter Local Area Connection* 3:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : home
   Link-local IPv6 Address . . . . . : fe80::edd5:b664:f65f:1a8e%27
   IPv4 Address. . . . . . . . . . . : 192.168.1.96
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.254

PPP adapter GlasgowVPN:

   Connection-specific DNS Suffix  . : something.internal
   IPv4 Address. . . . . . . . . . . : 172.21.11.111
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (Default Switch):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe40::34a8:9102:1910:c0c2%30
   IPv4 Address. . . . . . . . . . . : 172.22.111.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::19b8:9766:bd3:f15d%90
   IPv4 Address. . . . . . . . . . . : 172.17.224.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :
PS C:\WINDOWS\system32>

Our use case for needing this is as follows.
We have a huge number of servers deployed to the cloud (AWS). Some are pretty static, some are very transient.
These are accessible only if routing over our corporate VPN.
We connect to the VPN typically using sonicwall netextender in Windows but can also use native Windows 10 VPN.

We have a bunch of tooling to support deployment of these cloud instances written in in bash. Part of this tooling is a script to identify the public IPs of the cloud instances from aws, identify the gateway IP of the VPN, and add a route. This isn't just so that WSL can hit the node, it's so Windows can see the nodes too.
In WSL1 this allowed our Windows 10 host OS to access these AWS instances over HTTPS in a browser. Allowed our mssql tools to connect to the cloud SQL instances, allowed our oracle sql developer tooling to connect to Oracle RDBS, and so on.
It's not a persistent route. The routes vanish when we disconnect from the VPN, and that's absolutely fine.

[therealkenc]

If this is WSL2 (which it appears to be) this is for all intents by-design. WSL2 has its own Real Linux™ network stack inside a VM, and a virtual Ethernet device. Contrast WSL1 which took the approach of attempting to present the Windows network stack inside Linux.

[xibalbus]

If this is WSL2 (which it appears to be) this is for all intents by-design. WSL2 has its own Real Linux™ network stack inside a VM, and a virtual Ethernet device. Contrast WSL1 which took the approach of attempting to present the Windows network stack inside Linux.

I understand it has a different architecture, but i hoped it would still have the same functionality.
Using WSL to manage the host OS, such as routing tables, allows us to use the same processes and tooling across linux, mac, and windows desktops. Thats very important for us.
If WSL2 is further decoupling itself from the host OS - to the point things like this are no longer possible - that's a problem for us

[therealkenc]

I understand it has a different architecture, but i hoped it would still have the same functionality.

If you believe you've lost functionality vs. WSL1, that would make for a reasonable submission under a different cover including use case details etc. [Notwithstanding already identified WSL2 networking gaps notably glaring #4150, localhost transparency, and variations thereof.] It is possible (probable even), that the hole in functionality for a given specific use case can be plugged.

Using WSL to manage the host OS, such as routing tables, allows us to use the same processes and tooling across linux, mac, and windows desktops.

That is variation #874 (message).

to the point things like this are no longer possible - that's a problem for us

It is, as I understand it anyway, a design goal of WSL2 to provide WSL1 functionality and then some, to the extent that is achievable and notwithstanding the various trade-offs thereof (landing zone "I wish WSL1 turned out better" #4022).

You were not able to manipulate iptables(8) or the networking device layer in WSL1. There is no "things like this are no longer possible" at least in that narrow respect. You were not able to do BPF aka perennial #1349 in WSL1. Now you can. WSL2 has /dev/ppp ref #4201, WSL1 does not. For its part, #874 /dev/tun0 is probably destined for a fixedinwsl2 tag as well.

It would make an interesting masters thesis (or at least a thought experiment) to identify with specificity your ask (nevermind a describing an implementation). It isn't, paraphrasing, "Linux /proc/net/dev is missing another operating system's networking devices". I couldn't, personally, do a spec in a github post. With the obligatory caveat: near anything is technically possible even if it isn't especially feasible. Hence, the short and practical answer: PPP adapter GlasgowVPN does not appear in WSL2, by-design. That said, someone above my pay grade would have to close this issue submission as such. This submission can remain open at least as long as #874. And who knows... surprises happen around here all the time.

[xibalbus]

I understand it has a different architecture, but i hoped it would still have the same functionality.

If you believe you've lost functionality vs. WSL1, that would make for a reasonable submission under a different cover including use case details etc. [Notwithstanding already identified WSL2 networking gaps notably glaring #4150, localhost transparency, and variations thereof.] It is possible (probable even), that the hole in functionality for a given specific use case can be plugged.

Using WSL to manage the host OS, such as routing tables, allows us to use the same processes and tooling across linux, mac, and windows desktops.

That is variation #874 (message).

to the point things like this are no longer possible - that's a problem for us

It is, as I understand it anyway, a design goal of WSL2 to provide WSL1 functionality and then some, to the extent that is achievable and notwithstanding the various trade-offs thereof (landing zone "I wish WSL1 turned out better" #4022).

You were not able to manipulate iptables(8) or the networking device layer in WSL1. There is no "things like this are no longer possible" at least in that narrow respect. You were not able to do BPF aka perennial #1349 in WSL1. Now you can. WSL2 has /dev/ppp ref #4201, WSL1 does not. For its part, #874 /dev/tun0 is probably destined for a fixedinwsl2 tag as well.

It would make an interesting masters thesis (or at least a thought experiment) to identify with specificity your ask (nevermind a describing an implementation). It isn't, paraphrasing, "Linux /proc/net/dev is missing another operating system's networking devices". I couldn't, personally, do a spec in a github post. With the obligatory caveat: near anything is technically possible even if it isn't especially feasible. Hence, the short and practical answer: PPP adapter GlasgowVPN does not appear in WSL2, by-design. That said, someone above my pay grade would have to close this issue submission as such. This submission can remain open at least as long as #874. And who knows... surprises happen around here all the time.

I have added the use case to initial post.
TLDR is that we have a corporate sonicwall vpn, and bunch of servers in the cloud (AWS) that we need to access via windows - they they can only be hit if traffic to those instsnces is routed via the VPN. Some in house tooling (in bash) identifies the VPN gateway in windows, the IPs of the AWS instances we need to hit, and adds a route. This lets windows access the AWS instance, meaning we can browse to the apps hosted on the nodes.

[therealkenc]

, and add a route

For context, what was the crux of the WSL bash script that added the route? It doesn't need to be long or detailed, just the part doing the heavy lifting. It can even be in the abstract (the commands run) not a copy-paste of the real code.

[xibalbus]

, and add a route

For context, what was the crux of the WSL bash script that added the route? It doesn't need to be long or detailed, just the part doing the heavy lifting. It can even be in the abstract (the commands run) not a copy-paste of the real code.

It runs a route -n with a grep to find the VPN interface (this is essentially the bit that is failing now as WSL2 has no sight of it, so it presented as the same issue as we once had in WSL1 which I linked to)

It then calls into our cloud tooling to get a list of IPs from AWS and iterates and adds a route via

sudo route add -host $INSTANCE -interface $GATEWAY

[therealkenc]

sudo route add -host $INSTANCE -interface $GATEWAY

[retake]
Appreciate the follow up. If route(8) add was working for you in WSL1 that would count as functionality regress of sorts. route add does not take for me on WSL1 19596, but now I am starting to second-guess that there may have been a regress on running WSL as Administrator ref my own #4868.

Assuming this is the case, on WSL2, interop with Windows route.exe/ipconfig.exe or in the alternative powershell.exe commands is going to be the practical solution for your use case. At least until some network device layer bridge on steroids for the native Linux kernel comes along.

[ReyB59]

Hello,
May be related to this one #6001 ?

[therealkenc]

May be related to this one #6001 ?

The use case is vlan, so they are related. Thank-you for the reference. The gist of the original poster's ask was:

I understand [WSL2] has a different architecture, but i hoped it would still have the same functionality.

Which is very similar to #2685, for WSL1. In WSL1 the non-physical network interfaces were filtered outright (by-design). So this ask is pretty much "where did they go?", but in the context of WSL2. WSL2 has its own virtual eth0. #6001 is more along the lines of the "wsl2 network didn't work" (presumably internet not available) in their vlan scenario. In the OP presumably the network was working, or that would have been mentioned. Just that /proc/net/dev was not populated.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!