What are the options for stopping and starting?

What are the options for stopping and starting?

[Whit Blauvelt]

Hi,

Great design on this project. If I can understand some of the things the
docs don't cover yet, I'll try to write them up.

The first thing I'm tripping over is the relationship of a configuration
file, say wg0.conf, to the wg kernel module. I can follow the documented
examples to get a connection set up; but once it's going I'm vague on how to
reset it to other values -- perhaps another port, or different allowed IPs
.... There are some cases where hand-editing of the conf file gets
overwritten by some automated process. Does that have something to do with
the "SaveConfig" flag? What's the theory there?

More centrally, how does one apply changes through the conf file? Most of
use are used to user-space daemons, where restarting the daemon or having it
reload its prefs is standard. Or for kernel stuff, we're used to using
sysctl.d. Working with settings of a kernel module set through a conf file
like this is not such a regular thing. What should the standard methods be
here?

Thanks,
Whit

Re: What are the options for stopping and starting?

[Jason A. Donenfeld]

Hi Whit,

See the man page of wg(8):

$ man 8 wg

For your convenience it can be found online here:
https://git.zx2c4.com/WireGuard/about/src/tools/wg.8

Regards,
Jason

Re: What are the options for stopping and starting?

[Whit Blauvelt]

Hi Jason,

Thanks for the quick response. I've read through that man page several
times. Questions remain. 

So "setconf <interface> <configuration-filename>" is the basic equivalent of
"service reload" or the like. Okay. 

Is there a preferred way to take WireGuard fully down? We could unload the
wireguard (and ip6_udp_tunnel and udp_tunnel?) modules. But that seems a
crude method. What's perferred? I see we can "set <interface> remove", but
is there a simple command to take them all down? (One could obviously be
scripted; just wondering if I'm missing that one's already there.)

Also, what's "SaveConfig" about? I see I got that from wg-quick:
https://git.zx2c4.com/WireGuard/about/src/tools/wg-quick.8. I see now in
testing that that line's not accepted by wg once it's in the conf file --
nor is the Address line that shows up with wg-quick. I don't see where the
docs are clear that wg-quick and wg can't work from the same conf files.

I'm not complaining. Just trying to help get clarity for myself and others.
Your man pages are well written. But I'm sure you know there's much more to
say. My impression so far is that wg-quick probably shouldn't be used at all
outside of a specific road-warrior situation. Is that correct?

I'm also trying to fully understand the "kill switch" discussion in the
wg-quick man page. Is it the case, given standard use of wg (without
wg-quick), that its wg interfaces are available for unencyrpted traffic just
if wg itself isn't actively sitting on them? Or is this vulnerabilty
specific to wg-quick usage?

Best,
Whit

On Mon, Dec 04, 2017 at 05:14:01PM +0100, Jason A. Donenfeld wrote:
> Hi Whit,
> 
> See the man page of wg(8):
> 
> $ man 8 wg
> 
> For your convenience it can be found online here:
> https://git.zx2c4.com/WireGuard/about/src/tools/wg.8
> 
> Regards,
> Jason

Re: What are the options for stopping and starting?

[Aaron Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/12/17 17:29, Whit Blauvelt wrote:
> Is there a preferred way to take WireGuard fully down? We could
> unload the wireguard (and ip6_udp_tunnel and udp_tunnel?) modules.
> But that seems a crude method. What's perferred? I see we can "set
> <interface> remove", but is there a simple command to take them all
> down? (One could obviously be scripted; just wondering if I'm
> missing that one's already there.)

# ip link del dev wg0

Regards,
Aaron Jones

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJaJYZ0AAoJEIrwc3SIqzASUeEQAJ1E1n6x7ytRQofgyph+FlJe
rRFBhilGwT0t6MPCj44rJTPoGbUWXWZm9EaO+2RXBcpaZpedKpBoyX2kAh92dzYo
TsyHba0uIgSjgZGxxAbDORd2lH0ayIMx+INk0TZFDgAVHLK1e0+rW8DhSwBw3HvY
DZ9q2DqzBZ3Fos1LGxc41u0asFS1tDR4f0lBOvY0m32kXVb/U/2jTJ0VpaaZjlS6
5GwZZQGnfokbE48ge+xydF1CxWhr1/TAF6VqUIGFwBCJL7xYJt3hbVcis2ynraZ+
T5pqlgIEwwIvKvVtUf7OTHm/5qj6zayAlTUdeZnWAcKaCB95+Vuxqdex8Szk832N
B6e3rfJLs8/5BXhKfZ0Pwty8SRzo8KhSVpERSla7p6Ti4eGOFX5rbJzJ4+Hgme+M
KdH4OKoLY3/6+9xjfrzpoFQDkk53Py7B+C2K273Mz206ctziLcGmX1zHD3gKoOZz
CLdKoCrhTUchRfnbWtGH9owyn/JsSwvR/1Slyzoz2U/fbj/MOqiUzoE4F3Cw/3iy
H37OuM2dZzDCxqNx6AQGdXCbFpOhdDAcA2gBPDMMl1uF/cgDhoK+O4oiuFEpXuGQ
4u+mnoLe+WI9PmxRsEgfnqtA1dk/8OT3/YoOSTFdHt0Cunz9F/tC9KA0EmRHzk7Z
O52oPQUlQVRYqnn2wC3y
=RyV9
-----END PGP SIGNATURE-----

Re: What are the options for stopping and starting?

[Whit Blauvelt]

Hi Aaron,

Yes, removing the link should disable it. But that's overkill. Assuming I
want to leave the device in place, and the IP assignments there for
subsequent use by WireGuard, is there a simple way to shut WireGuard off,
without tearing down more than required?

If I'm running a VPN on a tun or tap device, for instance, I don't have to
remove the device to turn the VPN software off. I'm looking for the minimal,
not maximal, way to do that with WireGuard -- the equivalent to shutting
down a daemon in user space.

Thanks,
Whit

On Mon, Dec 04, 2017 at 05:31:35PM +0000, Aaron Jones wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 04/12/17 17:29, Whit Blauvelt wrote:
> > Is there a preferred way to take WireGuard fully down? We could
> > unload the wireguard (and ip6_udp_tunnel and udp_tunnel?) modules.
> > But that seems a crude method. What's perferred? I see we can "set
> > <interface> remove", but is there a simple command to take them all
> > down? (One could obviously be scripted; just wondering if I'm
> > missing that one's already there.)
> 
> # ip link del dev wg0
> 
> Regards,
> Aaron Jones

Re: What are the options for stopping and starting?

[Jason A. Donenfeld]

On Mon, Dec 4, 2017 at 7:37 PM, Whit Blauvelt <whit@transpect.com> wrote:
> Yes, removing the link should disable it. But that's overkill. Assuming I
> want to leave the device in place, and the IP assignments there for
> subsequent use by WireGuard, is there a simple way to shut WireGuard off,
> without tearing down more than required?

Answered earlier: `ip link set wg0 down`.

Come on into #wireguard and we can give you a hand with your
particular configuration needs.

Jason

Re: What are the options for stopping and starting?

[Jason A. Donenfeld]

Hi Whit,

> Also, what's "SaveConfig" about?

I understand more the nature of your inquiry now. If you're talking
about "SaveConfig", then you're referring to the use of wg-quick(8),
which is just a dumb wrapper around wg(8) and ip(8). In this case, the
commands you want to use are `wg-quick up` and `wg-quick down`.
SaveConfig=true means that the existing state of the device is saved
to the config file on `wg-quick down`. You can also do it manually via
`wg-quick save`. So, if you want to add peers or change things at
runtime, use wg(8) to do that, and then save those changes back to the
configuration file via `wg-quick save`.

If you're not using wg-quick(8), then you're already running commands
like `ip link add wg0 type wireguard` to add a new interface, after
which you likely configure it using wg(8). To remove it, the command
is then `ip link del wg0 type wireguard`. The quickstart documentation
on the website should show this.

> say. My impression so far is that wg-quick probably shouldn't be used at all
> outside of a specific road-warrior situation. Is that correct?

wg-quick(8) is useful for all sorts of things. Use it while it's
useful. If you find yourself wanting to do something that doesn't seem
obvious via wg-quick(8), don't use it, and roll your own trivial bash
script instead. WireGuard is meant to be easy to script. wg-quick(8)
is mostly just the bash script I wrote for my own usage - YMMV.

> So "setconf <interface> <configuration-filename>" is the basic equivalent of
> "service reload" or the like. Okay.

Sort of but not quite. You're thinking about this all wrong though and
you're going to get into trouble. There aren't services or daemons.
You can add and remove interfaces (ip link add/ip link del). You can
assign ip addresses to those interfaces (ip addr add/ip addr del). You
can assign routes that point to those interfaces (ip route add ... dev
wg0/ip route del ... dev wg0. You can set the link up or bring it down
(ip link set up/ip link set down). You can assign private keys and
peers and other wireguard-specific atrributes to the interface (wg
set/wg setconf/wg addconf). At no point is there a daemon. You make
interfaces. You configure them. You remove them.

> Is there a preferred way to take WireGuard fully down?

ip link set wg0 down, just like you would take down any other
interface. To remove an interface, the command would be ip link del
wg0. Same as the rest of Linux networking.

> I'm not complaining. Just trying to help get clarity for myself and others.

You can head into #wireguard on Freenode, if you'd like additional
help. You can send "others" there too. There are lots of knowledgeable
people there.

> I'm also trying to fully understand the "kill switch" discussion in the
> wg-quick man page. Is it the case, given standard use of wg (without
> wg-quick), that its wg interfaces are available for unencyrpted traffic just
> if wg itself isn't actively sitting on them? Or is this vulnerabilty
> specific to wg-quick usage?

There's not a vulnerability either way with a properly configured
setup. Those example iptables lines in the man page are to prevent
leaks in case you're additionally doing various stupid things.

Jason

Re: What are the options for stopping and starting?

[Whit Blauvelt]

On Mon, Dec 04, 2017 at 07:06:27PM +0100, Jason A. Donenfeld wrote:

> Sort of but not quite. You're thinking about this all wrong though and
> you're going to get into trouble. There aren't services or daemons.

Hi Jason,

Thanks for the quick, detailed answers.

While it's obvious wg-quick is a special purpose script, the precise niche
it's good for is underspecified; as is the incompatibility of the resulting
extra lines in the conf files. So if you were going to expand the docs to
avoid confusing average sysadmins like me, those would be nice things to
add.

I hope I was clear that I understand this is not about services or daemons
in userspace (although wg-quick has some daemonic properties). Yet in a way
it's normal to think of a VPN as a service, even if with WireGuard the
service is provided by the kernal rather than a user-space daemon. Yeah,
it's not the technical use of "service," but it's regular English, like
"telephone service" or "postal service."

It's natural in that metaphor of "service" to ask how to "turn it on" and
"turn it off." Okay, so "ip link set wg0 down" is the off switch; and "wg
setconf wg0 wg0.conf" is the on switch?

If so, it's just a bit unusual to have the off switch be outside of the
product (wg), while the on switch is inside it. Each command makes sense;
having them be so far apart is an unusual placement. I respect you're
adherence to KISS here. Yet an additional option like "wg setconf wg0
standby" (to set the link down while perserving the options if possible), or
"wg setconf wg0 off" (to turn it off and lose option settings) would fulfil
the user's expectation of the on switch and the off switch being found in
the same place. In a way it simplifies the interface to have features where
people most naturally look for them.

Now that I understand it, I've got no problem with it. I'm just pointing out
that for the next new user, unless the docs further explain this, the same
confusion could occur. 

Best,
Whit

Re: What are the options for stopping and starting?

[Jason A. Donenfeld]

On Mon, Dec 4, 2017 at 8:27 PM, Whit Blauvelt <whit@transpect.com> wrote:
> While it's obvious wg-quick is a special purpose script, the precise niche
> it's good for is underspecified; as is the incompatibility of the resulting
> extra lines in the conf files. So if you were going to expand the docs to
> avoid confusing average sysadmins like me, those would be nice things to
> add.

Patches and documentation contributions welcome.

> although wg-quick has some daemonic properties

No, it has exactly zero "daemonic properties". All calls to fork(2)
are quickly followed by either an exec(3) or an _exit(2), and every
child terminates prior to its parent. The parent itself never becomes
a session leader or detaches from its own parent. In other words,
wg-quick is a normal boring bash script.

> It's natural in that metaphor of "service" to ask how to "turn it on" and
> "turn it off." Okay, so "ip link set wg0 down" is the off switch; and "wg
> setconf wg0 wg0.conf" is the on switch?

No. As mentioned before, the reverse of `ip link set wg0 down` is `ip
link set wg0 up`.

> If so, it's just a bit unusual to have the off switch be outside of the
> product (wg), while the on switch is inside it. Each command makes sense;
> having them be so far apart is an unusual placement.

The linux kernel networking stack uses ip(8) and the iproute2 set of
commands as the standard way of configuring the networking state of
the system. The place to complain about this would probably be the
netdev sublist of LKML, but I sincerely doubt you're going to convince
them to change two decades of userspace APIs.

> I respect you're
> adherence to KISS here. Yet an additional option like "wg setconf wg0
> standby" (to set the link down while perserving the options if possible), or
> "wg setconf wg0 off" (to turn it off and lose option settings) would fulfil
> the user's expectation of the on switch and the off switch being found in
> the same place. In a way it simplifies the interface to have features where
> people most naturally look for them.

As has been written prior, `ip link set wg0 up` and `ip link set wg0
down` are what you're looking for.


> Now that I understand it, I've got no problem with it. I'm just pointing out
> that for the next new user, unless the docs further explain this, the same
> confusion could occur.

If you'd like to write an beginner's tutorial to iproute2, and then
add a section on wg(8), be my guest. Probably many people would
benefit.

As was written to you prior, please take additional inquiries to
#wireguard on Freenode where we can help you in real time.

Thanks,
Jason

Re: What are the options for stopping and starting?

[Aaron Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/12/17 16:01, Whit Blauvelt wrote:
> Hi,
> 
> Great design on this project. If I can understand some of the
> things the docs don't cover yet, I'll try to write them up.
> 
> The first thing I'm tripping over is the relationship of a
> configuration file, say wg0.conf, to the wg kernel module. I can
> follow the documented examples to get a connection set up; but once
> it's going I'm vague on how to reset it to other values -- perhaps
> another port, or different allowed IPs

wg(8) can dynamically adjust the configuration of an interface -- either
directly on the command-line, or by using 'addconf' or 'setconf' and
giving a (new) configuration file. The former won't erase any existing
configuration that doesn't exist in the new file.

> .... There are some cases where hand-editing of the conf file gets 
> overwritten by some automated process. Does that have something to
> do with the "SaveConfig" flag? What's the theory there?

Interface configuration can be persisted to the configuration file and
restored when the interface is next brought up. This is useful in the
context of dynamic configuration; some other service may have adjusted
your configuration, added or removed peers, etc, and you want this
preserved. That's what the flag you mentioned does.

> More centrally, how does one apply changes through the conf file?
> Most of use are used to user-space daemons, where restarting the
> daemon or having it reload its prefs is standard.

# wg addconf wg0 /etc/wireguard/wg0.conf

Regards,
Aaron Jones

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJaJX8VAAoJEIrwc3SIqzASvO4P/jwHINGo/WnsVO80hASlp+xL
4GQ9sQPOVBvJdLcb1YMEksIf69daWgfgcxRMbX0nL4I5aemOpfwm+bftWwdPCziE
ee25xA+petvusULAFHINbDk7dZHN1p8ugKTWQ/Pet6c4bgFZhRNp4Cs3/vjVsB4+
U+QQQPuY8b8VRChzB4jnpTQvlXvsn9lJYP/5MbsuK9Fcauvde992+YY64vMeBD/R
oi0bvbP/dQO1B+2S07kCcrzwov+UrsMN7+mc1zFoZWmvOkp5I250EqjAS2pJ8AhK
J5FUlvTfHKBUV3Zz/Totx4SgMwutir7Iu9yh+zzxn/s7O36pKJVeqMYBpOdhq+dL
eMrwwCtDoqiIyi3RQsHDCxg+4jINOvdflH3HDqM2w/sPmZe2xLJwNVPIEpAkddR3
yGLp5duZbKKNcM3kMPHeXC73u5RpzuPhIaSk4j67ZnRdkMIyx/D7ad1k4MyOPrUt
/PagvUl3E4eMQDKAc0wOcTOo8+Op/A9bgnxueWy/lTioufx7xZe1dOs9XzrChLN7
CDJbfKEr5NptWi4RdwqgdY+G1tKs/BS3Z6tqWesERgujnaVM2MrAN2Z4WSe3U/3t
PAIPaAYoxV0pc6WHIiXK+SYKL5K4/1oiGkd75QlA+8KhW9HAuu/C7W3EV/h1sAqX
+Q9OHBsc9YPg7Tj6WBKq
=XNLT
-----END PGP SIGNATURE-----