Development discussion of WireGuard
 help / color / mirror / Atom feed
* Actual plans for Windows client: PostUp/PreDown possible?
@ 2020-11-04 23:14 Stefan Puch
  2020-11-11  5:45 ` Simon Rozman
  0 siblings, 1 reply; 4+ messages in thread
From: Stefan Puch @ 2020-11-04 23:14 UTC (permalink / raw)
  To: wireguard

Hello!

I’d like to raise the question regarding an option for PostUp/PreDown with the
Windows client again, which was (to my research) first discussed here on the
mailing list at the beginning of December 2019 by Rémi and Jason A.

I thought about switching our OpenVPN setup to the modern Wireguard and started
reading if all my requirements could be fulfilled. So far I have some users with
no administrative privileges on their Windows computer when they want to connect
to a remote server in order to access some shared space (Samba filesystem).
Currently the users are using OpenVPN, which has a background service running
with admin rights (Windows service). Thus the users can simply use a shortcut on
the desktop to the OpenVPN-GUI including an appropriate config-file to connect
to the remote server. After the tunnel is established OpenVPN uses the
(optional) solution to place a batch file within the userspace
(%USERPROFILE%\OpenVPN\config) as CONFIG-NAME_up.bat / CONFIG-NAME_down.bat
where some stuff can be placed to mount a Samba filesystem after the connecting
and tunnel are established (net use z: \\10.0.0.1\data) and to unmount before
the tunnel is disconnected.

I’ve seen the concerns from Jason A. about spreading malware and the hint that
“Linux command line users can generally be trusted to check the config files
they're writing into /etc/wireguard”. From my point of view the same holds with
the solution provided from OpenVPN to use the batch files, which are optional,
can be checked by the user and have to be explicitly defined for each VPN profile.

Looking into the Windows specific todo list on the Wireguard homepage I didn’t
find any comments if this will be considered for later versions of the windows
client, if there will or won’t be a solution like this.

Maybe I have missed something, so my question would be, if someone can tell me
something about the current status or a possible implementation?

Kind regards
Stefan

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Actual plans for Windows client: PostUp/PreDown possible?
  2020-11-04 23:14 Actual plans for Windows client: PostUp/PreDown possible? Stefan Puch
@ 2020-11-11  5:45 ` Simon Rozman
  2020-11-11  9:50   ` Stefan Puch
  0 siblings, 1 reply; 4+ messages in thread
From: Simon Rozman @ 2020-11-11  5:45 UTC (permalink / raw)
  To: Stefan Puch, wireguard

Hi!

WireGuard for Windows and OpenVPN are fundamentally different. Consider WireGuard on Windows as an "always-on" VPN. Once configured by admin, it is just always there, and users don't need to explicitly connect or disconnect. Trust me, this is something your users will grow to love - no searching for a GUI to click Connect button when all you want is to quickly view a business document on Z:.

Think differently.

These are my recommendations for your use-case:

1. Configure the WireGuard tunnel at the company endpoint. Use specific port rather than random.

2. Configure WireGuard tunnel on client computers and leave it active at all times.

3. Instruct users to connect \\10.0.0.1\data as the network drive Z: and choose Reconnect on logon to make it persistent. (I am pushing a logon-script to do it in my deployment.) Why users? Because, seldomly users disconnect the network drive by accident, and it pays off they know how to reconnect it.

4. Don't add DNS line to the WireGuard tunnel config. Otherwise, WireGuard blocks all other DNS servers and users will not be able to access their home LAN by hostnames.

5. On client laptops that roam in and out of the network where your company endpoint resides, the tunnel company endpoint will auto-switch from public IP to local IP. Then you put your laptop to sleep and go home. When resuming at home, the WireGuard tunnel will still try to contact the company endpoint by local IP and the tunnel traffic will stall.

To mitigate this, I make a task in Task Scheduler to run "wg.exe set <your tunnel name> peer <company endpoint pubkey> endpoint <company endpoint public IP>:<company endpoint port>" command every 3 minutes.

This resets the tunnel endpoint to its public IP. The tunnel traffic is restored after leaving company network in no later than 3 minutes. The client endpoint roaming is handled by WireGuard.

As this scheduled task is the same for all clients, once configured and tested, it can be exported and imported on other computers (I deploy it using Group Policy).


And that's about it. Your users will always have their Z: drive there. No need for PostUp/PreDown.

Best regards,
Simon


-----Original Message-----
From: WireGuard <wireguard-bounces@lists.zx2c4.com> on behalf of Stefan Puch <s.puch@web.de>
Date: Tuesday, 10 November 2020 at 14.08
To: "wireguard@lists.zx2c4.com" <wireguard@lists.zx2c4.com>
Subject: Actual plans for Windows client: PostUp/PreDown possible?

    Hello!

    I’d like to raise the question regarding an option for PostUp/PreDown with the
    Windows client again, which was (to my research) first discussed here on the
    mailing list at the beginning of December 2019 by Rémi and Jason A.

    I thought about switching our OpenVPN setup to the modern Wireguard and started
    reading if all my requirements could be fulfilled. So far I have some users with
    no administrative privileges on their Windows computer when they want to connect
    to a remote server in order to access some shared space (Samba filesystem).
    Currently the users are using OpenVPN, which has a background service running
    with admin rights (Windows service). Thus the users can simply use a shortcut on
    the desktop to the OpenVPN-GUI including an appropriate config-file to connect
    to the remote server. After the tunnel is established OpenVPN uses the
    (optional) solution to place a batch file within the userspace
    (%USERPROFILE%\OpenVPN\config) as CONFIG-NAME_up.bat / CONFIG-NAME_down.bat
    where some stuff can be placed to mount a Samba filesystem after the connecting
    and tunnel are established (net use z: \\10.0.0.1\data) and to unmount before
    the tunnel is disconnected.

    I’ve seen the concerns from Jason A. about spreading malware and the hint that
    “Linux command line users can generally be trusted to check the config files
    they're writing into /etc/wireguard”. From my point of view the same holds with
    the solution provided from OpenVPN to use the batch files, which are optional,
    can be checked by the user and have to be explicitly defined for each VPN profile.

    Looking into the Windows specific todo list on the Wireguard homepage I didn’t
    find any comments if this will be considered for later versions of the windows
    client, if there will or won’t be a solution like this.

    Maybe I have missed something, so my question would be, if someone can tell me
    something about the current status or a possible implementation?

    Kind regards
    Stefan


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Actual plans for Windows client: PostUp/PreDown possible?
  2020-11-11  5:45 ` Simon Rozman
@ 2020-11-11  9:50   ` Stefan Puch
  2020-11-11 13:23     ` Simon Rozman
  0 siblings, 1 reply; 4+ messages in thread
From: Stefan Puch @ 2020-11-11  9:50 UTC (permalink / raw)
  To: Simon Rozman, wireguard

Hi, thanks for stepping in.

While I like your suggested "always-on" solution for fixed desktop PCs I don't
like the "work-around" for client laptops. A Task Scheduler which is trying
every 3 minute to set a wiregurad tunnel when you are sitting in a train using a
mobile connecting is nothing I'd like to see. I think there are also other
scenarios where you just want to "click Connect button" on demand. E.g. when
your company has multiple locations and you don't want (or cannot) use multiple
VPN connections a the same time you will always have the "somewhat broken"
network drives in the windows explorer too, since they weren't disconnected
within a PreDown script.

Another problem (which I skipped so far) is related in point 4. of your
suggestion and as I see this a also discussed within another thread here on the
mailinglist. While a simple network drive can of cause be setp to a fixed IP
adress to drive z: using fixed adresse is IMHO not a good solution.
Like Yves Goergen pointed out in the thread "Add local DNS forwarder to Windows
client" I'd like an option to add the remote DNS server to the serach list so
that that I don't have to keep IP adresses in mind. But I think this discussion
should be shifted to the other thread.

Kind regards
Stefan

Am 11.11.2020 um 06:45 schrieb Simon Rozman:
> Hi!
>
> WireGuard for Windows and OpenVPN are fundamentally different. Consider WireGuard on Windows as an "always-on" VPN. Once configured by admin, it is just always there, and users don't need to explicitly connect or disconnect. Trust me, this is something your users will grow to love - no searching for a GUI to click Connect button when all you want is to quickly view a business document on Z:.
>
> Think differently.
>
> These are my recommendations for your use-case:
>
> 1. Configure the WireGuard tunnel at the company endpoint. Use specific port rather than random.
>
> 2. Configure WireGuard tunnel on client computers and leave it active at all times.
>
> 3. Instruct users to connect \\10.0.0.1\data as the network drive Z: and choose Reconnect on logon to make it persistent. (I am pushing a logon-script to do it in my deployment.) Why users? Because, seldomly users disconnect the network drive by accident, and it pays off they know how to reconnect it.
>
> 4. Don't add DNS line to the WireGuard tunnel config. Otherwise, WireGuard blocks all other DNS servers and users will not be able to access their home LAN by hostnames.
>
> 5. On client laptops that roam in and out of the network where your company endpoint resides, the tunnel company endpoint will auto-switch from public IP to local IP. Then you put your laptop to sleep and go home. When resuming at home, the WireGuard tunnel will still try to contact the company endpoint by local IP and the tunnel traffic will stall.
>
> To mitigate this, I make a task in Task Scheduler to run "wg.exe set <your tunnel name> peer <company endpoint pubkey> endpoint <company endpoint public IP>:<company endpoint port>" command every 3 minutes.
>
> This resets the tunnel endpoint to its public IP. The tunnel traffic is restored after leaving company network in no later than 3 minutes. The client endpoint roaming is handled by WireGuard.
>
> As this scheduled task is the same for all clients, once configured and tested, it can be exported and imported on other computers (I deploy it using Group Policy).
>
>
> And that's about it. Your users will always have their Z: drive there. No need for PostUp/PreDown.
>
> Best regards,
> Simon

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: Actual plans for Windows client: PostUp/PreDown possible?
  2020-11-11  9:50   ` Stefan Puch
@ 2020-11-11 13:23     ` Simon Rozman
  0 siblings, 0 replies; 4+ messages in thread
From: Simon Rozman @ 2020-11-11 13:23 UTC (permalink / raw)
  To: Stefan Puch, wireguard

Hi,

Stefan, your feedback is greatly appreciated.

> While I like your suggested "always-on" solution for fixed desktop PCs I
> don't like the "work-around" for client laptops. A Task Scheduler which
> is trying every 3 minute to set a wiregurad tunnel when you are sitting
> in a train using a mobile connecting is nothing I'd like to see.

The "wg set peer endpoint" is very lightweight and makes no network requests. Nor it burns CPU/battery. It merely resets an IP address (4 bytes for IPv4, 16 for IPv6) inside the WireGuard tunnel peer list. Would have been even nicer if Task Scheduler could have a trigger "network connection changed". 

> I think
> there are also other scenarios where you just want to "click Connect
> button" on demand. E.g. when your company has multiple locations and you
> don't want (or cannot) use multiple VPN connections a the same time you
> will always have the "somewhat broken"
> network drives in the windows explorer too, since they weren't
> disconnected within a PreDown script.

Each WireGuard tunnel supports multiple peers (i.e. multiple company endpoints). 10.0.0.0/16 is office A, 10.1.0.0/16 is office B, etc. Just list them all in your tunnel config and your laptop should reach all those networks.

Maybe "tunnel" is not the best word to describe it. Imagine it as a "network", or a "mesh".

> Another problem (which I skipped so far) is related in point 4. of your
> suggestion and as I see this a also discussed within another thread here
> on the mailinglist. While a simple network drive can of cause be setp to
> a fixed IP adress to drive z: using fixed adresse is IMHO not a good
> solution.
> Like Yves Goergen pointed out in the thread "Add local DNS forwarder to
> Windows client" I'd like an option to add the remote DNS server to the
> serach list so that that I don't have to keep IP adresses in mind. But I
> think this discussion should be shifted to the other thread.

You may. But once you do add DNS line to your tunnel config, your client will exclusively use that DNS. All local and others are blocked. If your company DNS server does the forwarding too, this shouldn't be a problem. The down side is, you cannot access local LAN resources by name. But that is discussed in another thread, indeed.

Regards,
Simon


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-11-11 13:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-04 23:14 Actual plans for Windows client: PostUp/PreDown possible? Stefan Puch
2020-11-11  5:45 ` Simon Rozman
2020-11-11  9:50   ` Stefan Puch
2020-11-11 13:23     ` Simon Rozman

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).