RE: Wireguard Windows Service Issues

[Simon Rozman <simon@rozman.si>]

Hi,

>  From this description, it seems that there's room for improvement.
> 
> It doesn't seem reasonable for the WireGuard service to stop. Log and
> perhaps display an error, sure.  But stopping seems harsh, and would
> prevent other tunnel endpoints from working - not a good user
> experience.
> 
> It would seem better for the service to set a timer and retry failures
> periodically - many DNS issues are transient.
> 
> It also seems to me that it would be better for the default to be option
> 3 - make all tunnels dependent on DNSCache without requiring any
> user/admin action.  One could condition this on an endpoint being
> specified as a hostname, but that doesn't seem worth the effort.  Pretty
> much any use of a tunnel needs name resolution.  Even if your resolvers
> are at the other end of the tunnel, starting the client before it's up
> is harmless.
> 
> Anyone concerned about DNS snooping on name resolution of the endpoints
> can avoid it by using either of the other two options: hardcoded IP in
> the configuration, or an entry in "hosts".
> 
> "It just works" seems much more desirable than mystery service stops.  A
> UI status "waiting for hostname resolution" would be ideal.

The DNSCache service is optional on Windows 7/8/8.1/Server 2008R2/2012R2 and may be even disabled. (And the resolution would work just fine.) Since SCM treats all service dependencies as "hard" dependencies, that would render all WireGuard tunnel services fail to start. It's a fairly rare use case, but a demonstration SCM service dependencies must be authored with extreme care.

I'd rather suggest pursuing the macOS approach where services don't have any dependencies to force developers engineer their services to sleep and retry until their dependencies get available. As you suggested first. However, WireGuard for Windows already has DNS resolution retrying loop. Maybe it needs improvement? Let's wait to see what OP's log says.

Regards,
Simon