Tun Implementation?

[ghost]

Trying to test a project that uses OpenVPN, when I try to start OpenVPN I get this message:
ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)

Upon running modprobe tun:
FATAL: Module tun not found in directory /lib/modules/4.4.0-43-Microsoft

So is tun going to be implemented at any stage? I've seen in other threads people recommending using a VPN in native Windows, but that doesn't really solve the problem.

Any help would be greatly appreciated.

[fpqc]

Unlikely for now. Eventually you might be able to (or are already able to) install OpenVPN on Windows and then use the Tun/Tap adapter provided there. OpenVPN relies on a driver, and there is no way, given the design of WSL, for WSL to load native Linux Kernel Modules. The ABI facing userspace on Linux is kept pretty stable between Linux Kernels, but the kernel-facing ABI (for drivers and modules) is constantly changing and shifting.

In the future, MS might create an API for makers of Windows drivers to make their devices available to WSL, and indeed, such an API does exist privately at MS (this is how they implement devices), but it is not stable right now and therefore not public either. As WSL matures, they may add the documentation for this API to the Windows Driver Kit or the Kernel Mode Driver Framework.

[therealkenc]

...you might be able to (or are already able to) install OpenVPN on Windows and then use the Tun/Tap adapter provided there.

Yes that's the solution. I tunnel out of WSL (which is Windows) using Windows OpenVPN all day long. If MSFT implements/emulates the kernel ip routing surface in WSL it would just end up talking to Windows TAP (or their own hand-rolled equivalent). The whole exercise would be circular.

Note however that despite working perfectly fine, none of this is a supported scenario, and some folks have had all manner of problems with their third-party Windows VPN software (I use PIA as my provider, not an endorsement mind). So be prepared to put "reformat Windows and start over" on the table because there is nowhere to whinge if you bork everything.

Also worth pointing out that SSH port forwarding works great on WSL. If you just want to secure endpoints you probably want that anyway.

[fpqc]

@therealkenc Also, until some way of managing root and Windows admin credentials together is figured out, you probably wouldn't be able to control a hypothetical interface for the Windows driver from the Linux side unless you start your lxsession with administrator credentials.

[therealkenc]

Or you do it with a Windows service on the Windows side; which is how a number of Windows VPN packages work (nevermind hypothetical WSL scenarios). This is usually the part where you suggest one could do it with the ionescu007/lxss stuff. Which you can. And then no one does. So I'm happy you've resisted the temptation lately.

Anyway, this is #874 with User Voice here and here.

[fpqc]

@therealkenc Yeah, I gave essentially the same exact answer last year haha.

[benhillis]

Marking as duplicate of #874.

[WaleedAshraf]

hi @therealkenc
How did you fix this issue by using windows openvpn? I'm facing the same issue.

[therealkenc]

How did you fix this issue by using windows openvpn?

^--- Nothing special, really. Windows OpenVPN (which is what my VPN provider ships, but you can also hand roll) just works out of the box. There is (was) nothing to "fix". WSL is oblivious to the fact the bytes are going through the tunnel, and /dev/net/tun (aka "this") doesn't enter into the equation. YRMV.