WinTUN: Windows Finally Gets A Good TUN Driver & It's Open-Source

[phoronix]

Phoronix: WinTUN: Windows Finally Gets A Good TUN Driver & It's Open-Source

With existing Windows APIs being a nuisance, under NDA'ed documentation, and other problems, WireGuard developers have taken to developing a "good" TUN driver for Windows. This lets user-space programs serve as virtual network adapters to read/write directly into the network stack...

http://www.phoronix.com/scan.php?page=news_item&px=WinTUN-Windows-TUN-Driver

[cybertraveler]

Jason sounds like he is highly knowledgeable in the area he is working. I also appreciate his engineering philosophy:

As usual, I wanted instead something tiny and dumb that we can reason about, which does things in a "right" and "boring" way for a narrower use case: layer 3 TUN.

source: https://lore.kernel.org/wireguard/CA...ail.gmail.com/

As trivial as that quoted statement may sound, I think there are far more software developers that don't grok the wisdom of it, than those that do.

[M@GOid]

It would be nice if the article explained what the hell is "TUN".

[cybertraveler]

Of note: this WinTun project is not ready for general use yet. Jason states in the mailing list announcement:

Have we succeeded in accomplishing our goals? Certainly not yet. At the present moment [folks reading this in the future: check the date of this email], I'd except for Wintun to be slower, buggier, and lower quality than anything else out there. But we thought it'd be a good idea to release sooner rather than later in order to have some more eyeballs on it. It's the kind of codebase that _certainly_ needs some cleanup and a thorough security audit. On the plus side, cloc(1) tells me that it's only 950 lines. Still, NT programming is hard, and I'm pretty certain we've made mistakes and left ugly corners. Consider this email a statement of intent rather than an announcement of a completed project.

Emphasis added.

He is also requesting assistance from any devs interested in NDIS programming that want to lend a hand.

[Michael]

It would be nice if the article explained what the hell is "TUN".

"This lets user-space programs serve as virtual network adapters to read/write directly into the network stack."

[cybertraveler]

It would be nice if the article explained what the hell is "TUN".

https://www.wintun.net/

TL;DR: it's a fake/software network card useful for creating network tunnels (IE data pops in one side of the tunnel and pops out somewhere completely different. As happens with VPNs).

[M@GOid]

Actually, what I mean is what "TUN" stands for, since is not a thing I had head before. Wikipedia says is for "network TUNnel".

[edwaleni]

I will read on it (WinTUN) some more, just wondering if they ever looked at PacketDirect for NDIS (aka PDPI).

https://docs.microsoft.com/en-gb/windows-hardware/drivers/network/introduction-to-ndis-pdpi

It's the same as DPDK for Linux and allows the network stack to be bifurcated. Increases performance.

It is really designed to reduce network stack overhead for voice traffic to reduce jitter, but could be designed for other protocols that user space wants to process.

[edwaleni]

I looked up Microsoft's VPN namespace API to see what if/any obvious roadblocks one would run into that would fall into NDA Land.

https://docs.microsoft.com/en-us/uwp/api/windows.networking.vpn

The problem seems to be that Microsoft has abstracted the VPN interfaces to such a degree, so that they will fit into the UWP model they have created (Universal Windows Program).

The classes in this namespace enable you to create, edit, and manage Virtual Private Network (VPN) connections, and to write plugins for controlling a VPN connection using the Windows VPN Platform.

However....

To use the classes in this namespace, you must declare the networkingVpnProvider restricted capability.

Which leads to:

If your app declares any restricted capabilities, you must provide info during the app submission process in order to be approved to publish the app to the Microsoft Store. You provide this info on the Submission options page of your submission, explaining how your app uses each restricted capability that it declares.

Said app can still be sideloaded, but basically if you want to use the UWP approach to developing your VPN manager for Windows, MSFT wants to know. I am assuming this is for all of the 3rd party VPN providers in the world that want "universal" Windows support across platforms, and not really about setting up "quick and dumb" private tunnels that WinTUN wants to do.

Looking at the feature set, this seems to be overkill for what WinTUN wants to do, and is probably immature (knowing MSFT).

As for MSFT Packet Direct:

PD works by allowing a PD client to explicitly manage networking traffic from a network adapter (NIC). PD gives the PD client control of the high performance send and receive functionality of the NIC through the PacketDirect client interface (PDCI). Internally, the PDCI send/receive functions are mapped directly to the PDPI. PD send/receive functions operate on PD queues created by the PD client on PD-capable NICs. PD provides the PD clients with the ability to set custom filters for very specific types of traffic or very generic traffic, based on the needs of the PD client. This allows the PD client to direct certain incoming packets to its PD queues. Packet processing in the PD model always takes place in an execution context that’s owned (or controlled/coordinated) by the PD client. The PD-capable NIC driver is completely passive, meaning it does not actively forward incoming packets or completion indications for sent packets to the PD client in a driver-owned execution context such as a DPC or worker-thread.

If a PD client does not understand how to process a packet or receives a control packet in one of its queues, such as an ARP, LLDP, or other protocol packets, the PD client can reroute the packet back to the current I/O path for processing. This allows PD to continue to process the packets that it has context for and not waste cycles on control traffic.

Important There can be one PD provider and one PD client per net adapter. Therefore, there can be multiple PD clients and PD providers on a single system.

The PD client has control over the resources that are allocated to PD in the system. In cases of high network traffic, the PD client is responsible for minimizing its workload so that the OS can be responsive to other workloads.

The PacketDirect platform implemented by Windows maps the client interface to the provider interface. The platform controls buffer management and ability to re-inject packets received via PD to the current NDIS receive path. It also handles the interaction with PD clients for satisfying the NDIS control path requirements such as NIC disabling, going into low-power, system shutdown, and surprise removal in a fashion that does NOT hamper the PD data path performance.

I am not an NDIS developer, but I am fascinated with the goals of WinTUN. The fact that the developers looked at both OpenVPN and SoftEther is a good thing (as i was originally going to suggest SoftEther) and find it interesting that the "model" used as they describe as somewhat outdated and somewhat "heavy".

Something to follow and see where this goes.