Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Simon McNair <simonmcnair@gmail.com>
To: wireguard@lists.zx2c4.com
Subject: Re: Wireguard Windows Service Issues
Date: Mon, 24 Jan 2022 18:17:58 +0000	[thread overview]
Message-ID: <154d5705-2445-6297-cade-2103738a0667@gmail.com> (raw)
In-Reply-To: <e48d98ba2ad34d2f86fb34e5c95aebaf@rozman.si>

just to insert my 2p.

Provided the service manager is installed whilst the tunnel will not 
appear in the list of tunnels you can view the logfile which will assist 
with diagnosis.

 From my perspective I set up exactly the same set-up myself at the 
weekend and it is behaving as advertised (except not on wifi).

The part of this that makes me curious though is the fact that the 
connection is via wifi so the adapter will stay visible but the 
underlying connection will drop and the ip addresses, DNS etc will 
change behind the scenes with each wireless network they connect to.  I 
would think wireguard would handle this, but the log file would 
certainly be worth of scrutiny.

Also worth thinking around powers aving and the closing of the laptop 
lid putting the adapter in to power saving and dropping the underlying 
connection.

Simon


On 17/01/2022 10:51, Simon Rozman wrote:
> Hi,
>
>> I believe there's a bug in the Windows service implementation, if this
>> issue is by design, it's problematic.
>>
>> I have non-admin users were when I initially set them up with wireguard,
>> I configured it to use the service, using the command:
>>
>> wireguard /installtunnelservice "C:\Program
>> Files\WireGuard\Data\Configurations\vpn.domain.org.conf.dpapi"
>>
>> The tunnel worked fine the first time. Then the user reboots the laptop,
>> or closes it or leaves whatever coffee shop they were at and get
>> disconnected from the wireless network they were using. When this
>> happens, for some reason, the wireguard service then gets torn down
>> never to come back again until I issue the command from my admin account
>> again.
> Can you do the wireguard /dumplog > wireguard.log and investigate.
>
>> There was an issue with some users initial configuration in that they
>> could not query hostname via DNS, so that entering the command to
>> installservice would not even create the service.
> WireGuard services start early on boot - sometimes even before the DNSCache (DNS Client). If the service can't resolve hostnames used in the config file, it will stop. But it will log this. Resolution to this problem is:
> - Use IPs rather than hostnames.
> - Add hostnames you use in your .conf file to C:\Windows\system32\drivers\etc\hosts.
> - Add DNSCache dependency to the WireGuardTunnel$<your tunnel name> service.
>
> I personally would pick one of the first two options above. Don't like the idea my laptop is asking a coffee shop's DNS what is my VPN endpoint IP address.
>
>> Here's a few notes that might help with understanding.
>> - Users must have the VPN established before they log into the active
>> directory servers on the remote network so that they can get all of
>> their GPO directives.
>> - Wireguard Service should stay up so that any time a users connects to
>> any network, the VPN is established immediately after that.
>> - The Wireguard service should also stay because non-admin users cannot
>> create a new service
> I understand. That is exactly how we use WireGuard in our company.
>
>> If this issue is how things will stay, and this is not considered a bug,
>> how would you configure windows non-admin users to tunnel to an
>> enterprise network before login via WireGuard and to continuously try to
>> establish the tunnel while the user is not connected to a network?
> Let me assure you, the behavior you are expecting is definitely pathological. Please investigate the log file why the tunnel service does not persist as it should.
>
> Best regards,
> Simon

      parent reply	other threads:[~2022-01-24 18:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05 18:47 Tony Pros
2022-01-17 10:51 ` Simon Rozman
2022-01-17 11:18   ` tlhackque
2022-01-17 12:47     ` Simon Rozman
2022-01-21 21:03   ` Tony Pros
2022-01-24 14:47     ` Simon Rozman
2022-01-24 18:17   ` Simon McNair [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=154d5705-2445-6297-cade-2103738a0667@gmail.com \
    --to=simonmcnair@gmail.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).