What are the options for stopping and starting?
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
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
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
Quoted 11 lines · Jason A. Donenfeld
Hi Whit,
See the man page of wg(8):
$ man 8 wgFor your convenience it can be found online here:
https://git.zx2c4.com/WireGuard/about/src/tools/wg.8Regards,
Jason
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Quoted 6 lines · Whit Blauvelt
Is there a preferred way to take WireGuard fully down? We could unload the wireguard (and
ip6_udp_tunnelandudp_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-----
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
Quoted 15 lines · Aaron Jones
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256Quoted 6 lines · Whit Blauvelt
Is there a preferred way to take WireGuard fully down? We could unload the wireguard (and
ip6_udp_tunnelandudp_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 wg0Regards,
Aaron Jones
Quoted 4 lines · Whit Blauvelt
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
Hi Whit,
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 1 line
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.
Quoted 5 lines
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
Quoted 2 lines · Jason A. Donenfeld
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
Quoted 5 lines · Whit Blauvelt
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.
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 3 lines
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Quoted 10 lines · 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
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.
Quoted 3 lines
.... 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.
Quoted 3 lines
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-----