Tailscale removes all wintun adapters on service restart, not just its own

[jozz-zzz]

What is the issue?

Whenever tailscale service is started on Windows, it removes all wintun adapters not just the one it creates for itself.

This breaks other connections e.g. openvpn using wintun & means there are no persistent wintun adapters across reboots.

Possibly related to https://github.com/tailscale/tailscale/issues/2591

I'm currently using tailscale 1.38.4, but observed this behaviour on previous version too.

Steps to reproduce

Install openvpn 2.6 client, enabled "windows-driver wintun" in profile Optionally create additional wintun adapters: "C:\Program Files\OpenVPN\bin\tapctl.exe" create --hwid wintun Stop tailscale, observe the 'Tailscale' adapter is removed Start tailscale, observe all other wintun adapters are disabled & removed (even if in use by OpenVPN). A single new wintun adapter is created for tailscale.

Are there any recent changes that introduced the issue?

No response

OS

Windows

OS version

Windows 10 22H2

Tailscale version

1.38.4

Other software

OpenVPN 2.6

Bug report

BUG-26aea5f80af8dff03c21d42cf658cb71b34f354928b82b5c14508c9f7e267191-20230421000203Z-25c570fd33013467

[oXydus]

Tailscale version 1.44.0 OpenVPN 2.5 and 2.6 Step to reproduce. Install OpenVPN with Wintun interface. Start Tailscale. Wintun interface from OpenVPN is removed.

[savely-krasovsky]

We have this issue with our own wintun interface, not just OpenVPN one. It's nonsense. Could someone from Tailscale team look at this?

[svargh]

tailscale Windows Version: 1.6.0 OpenVPN v2.6.0

Having also this problem. My WinTun OpenVPN adapters get removed on these events:

• tailscaled service restart
• Since ugprading to 1.6.0 even after putting computer to sleep.

Very disturbing. I have to manually call multiple times "Add a new Wintun virtual network adapter" from Open VPN Utilities folder to restore all my wintun adapters Please do not touch my OpenVPN Wintun adapters.

[savely-krasovsky]

@bradfitz could someone from your team look at this issue please? There are so many VPN clients which also using Wintun and they are all suffer from the behavior of Tailscale. Most of VPN clients create device at installation stage and then use it by finding it by interface LUID. Tailscale currently reinstalls Wintun driver entirely which leads to all Wintun-related interfaces to disappear. After that you need to reinstall all related apps, but Tailscale will do it after reboot again.

I see you are using WiX Bootstrap Bundle, so you are probably using MSM and MSI to install everything needed. You have two options basically:

1. Update to Wintun 0.14.1 which creates interface on demand and works entirely different (you will need to rewrite TUN-related stuff a bit).
2. Look at OpenVPN approach. MSI supports custom actions which implement simple interface. You can call them in the right order using the power of WiX.

Personally I think the second option is simpler in your case: [1] -- this is the code of DLL they call during installation. [2] -- this is an example of WiX configuration itself.

In your case you don't use tap-windows6 and ovpn-dco-win, so there will be even less code.

[nickkhyl]

Hi @L11R. Tailscale uses the most recent version of WinTun, which is currently 0.14.1. You can confirm this yourself by checking the version of the wintun.dll file at C:\Program Files\Tailscale\wintun.dll, or by checking the driver version of the Tailscale Tunnel adapter in Device Manager (it will indicate 0.14.0, though, because 0.14.1 included only API changes, and the actual driver embedded in the DLL remained at 0.14.0).

We are aware of third-party VPN solutions that are still using older versions of the driver. For example, the last time I checked, OpenVPN client was still using WinTun 0.8. Unfortunately, only one version of the driver can be installed at a time, and the WinTun DLL removes adapters created with older versions when updating the driver, and we're not planning on supporting WinTun versions older than 0.14.1.

However, I'm happy to investigate any compatibility issues with VPN clients that also use the 0.14.1 WinTun version.

[savely-krasovsky]

@nickkhyl sorry then! I definitely missed that fact. I thought for some reason, that Tailscale still uses v0.8.1 and just reinstalls driver every boot, probably because you have a fork of old Wintun. Well, yeah, than this is much a larger problem, unrelated to Tailscale probably. VPN solutions I use, still use v0.8.1 (probably because they are using OpenVPN stack). To be honest I thought Wintun v0.14.1 works a little bit different. They changed distribution model, now it's DLL which creates interface on-demand, isn't it? How does newer version driver install? I guess you probably has an option to build and sign own version of Wintun (I am not sure LICENSE permits that)? But for sure it shouldn't be your problem, I am just thinking of other options...

[nickkhyl]

The wintun.dll contains both the driver binary (wintun.sys) and the API surface that software vendors can use to install and use the driver. Building and distributing custom versions of the Wintun driver (or the DLL wrapper) is not allowed.

When wintun.dll creates a new adapter on behalf of Tailscale or other VPN clients that use it, it checks the currently installed driver version and updates it if necessary, ensuring that the driver version is never older than the API version. If a Wintun driver update is necessary, it results in the removal of any existing Wintun adapters.

Applications can detect this and re-create their own adapters if necessary. However, they shouldn't downgrade the installed Wintun driver. As a general rule, VPN clients that utilize the wintun.dll API should be compatible with each other, as the API guarantees that even if different VPN clients are using different versions of the DLL, they all use the most recent version of the driver.

[savely-krasovsky]

Thanks for the detailed explanation! I guess they only way to properly fix it is to move OpenVPN from old Wintun version (which is out of your scope for sure).