Wireguard 0.5.3 on Windows - Huge performance issue when no network connection is up

[Eric Granados]

Hi Folks,

Having this issue in corporate environments, that I can reproduce at will. The scenario is as follows:
* Wireguard installed and properly configured
* Boot the computer with NO physical network connection active
* Open an Office document stored locally on the computer : takes between 15 seconds and up to 4 minutes
* As soon as a physical network adapter comes up, even for a few seconds, the problem disappears and the same document opens in 1-2 seconds. The computer does *not* need to have internet access : "Upping" network card is enough.
* Once an adapter has been up, I can put it down again and the problem won't appear again, until next computer reboot.
* If, instead of "upping" an adapter, I unbind Tcp/Ip from the Wireguard adapter, the problem disappears; and reappears as soon as I bind again Tcp/Ip. Which is imho proof that Wireguard is causing this behaviour.

Of course I guess that the "root cause" is actually Ms-Office, probably trying to reach something it can't reach (even though the document is local...) and waiting for a timeout. That would make sense, since in a way the Wireguard interface is "always up", Office probably "believes" that there is a network available. However, I sniffed the Wireguard adapter in this scenario, and Wireshark only shows DNS requests being sent (which, of course, receive no answer).

In my case it is a big issue, because I have users who are trainers and, when they go to a customer site to give their trainings, they very often won't have any network connection provided by their customer, and in many cases are in locations where there is no mobile phone signal so they can't even share their mobile connection.

Right now, the ugly workaround I have found is the following :
* A scheduled task runs at computer startup, and disables the Wireguard Tcp/Ip binding
* Another scheduled task is triggered when the NCSI (Network Connectivity Status Indicator) event 4042 is fired, which happens when a physical network adapter comes up, that re-enables the Tcp/Ip binding.

But it is indeed an ugly workaround, so I'm posting here in the hope that :
* Someone can look into this (I am no developer so totally unable to look at the code)
* If not, at least hoping that my current workaround can be helpful to others who may encounter the same issue.

I have a gut feeling that, due to the very nature of Wireguard ("always up"), there is no "structural" solution to this, but any suggestion is welcome.

Sorry for the long post but I could not find a shorter way to describe the issue accurately !