WireGuard for Windows tunnel deactivation after prolonged resolution failure during startup

[Joshua Sjoding]

Someone could power the laptop up but wait hours before they connect
it to their hotspot. For scenarios like that the current algorithm
seems insufficient.

My preference would be to listen for network changes while in a failed
state, then re-run the existing algorithm whenever a network
connect/disconnect occurs. This wouldn't cover cases where the
upstream ISP is having trouble, but it would probably be a big
improvement for us.

The best way to detect network changes on Windows is open for debate.
We've had great success with scheduled tasks that listen for events
10000 (connect) and 10001 (disconnect) in the
"Microsoft-Windows-NetworkProfile/Operational log" event log:

<QueryList><Query Id='1'><Select
Path='Microsoft-Windows-NetworkProfile/Operational'>*[System[(EventID=10000
or EventID=10001)]]</Select></Query></QueryList>

I don't know if that's helpful. There probably are better ways to
detect network changes, that's just what I've got off the cuff.

Joshua Sjoding
SCJ Alliance
IT Specialist
www.scjalliance.com


Joshua Sjoding
SCJ Alliance
IT Specialist
o. 360.352.1465, ext. 134
www.scjalliance.com

This communication may contain privileged or other confidential
information. If you have received it in error, please advise the
sender by reply email and immediately delete the message and any
attachments without copying or disclosing the contents. Thank you.


On Thu, Jan 28, 2021 at 4:39 PM Mike O'Connor <mike at pineview.net> wrote:
>
> Hi Jason
>
> I'm not a windows users so can not test, but it seems to me that
> Microsoft have API's to indicate the network status.
>
> This to indicate if there is a connection
> https://docs.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetgetconnectedstate
> This to indicate if there is route-able service. It seem this is
> deprecated for windows 10.
> https://docs.microsoft.com/en-us/windows/win32/api/wininet/nf-wininet-internetcheckconnectiona
> There is reference to a win10 version, in the notes.
>
> Not sure if this helps
>
> Cheers
> Mike
>
>
> On 29/1/21 10:53 am, Jason A. Donenfeld wrote:
> > Hi Joshua,
> >
> > Thanks for the bug report. Windows is usually all about heuristics.
> > Here's the current algorithm:
> >
> > - If the system has booted within the last 4 minutes, it retries 40
> > times. Otherwise it retries 10 times.
> > - If the resolution fails with a temporary error, or if it fails with
> > a permanent error but there's no available internet connection, then
> > we sleep for 4 seconds and try again.
> > - If we try the 40 or 10 times over the 160 or 40 seconds and don't
> > succeed, then we fail and shut down the service.
> >
> > It sounds like that set of heuristics isn't working out so great for
> > your use case. How long do those computers usually take to obtain an
> > Internet connection? If you could run some estimates on that, and come
> > up with some reasonable length of time ("not more than 3 minutes" for
> > example) then maybe we could just double that and make it the new
> > timeout? Or maybe you have a different idea?
> >
> > Jason
>
>