I'm not sure that we should named both peers as "client" "server" as the documentation will mainly talk about "peer"
- That sounds sane. It was mostly what made sense to me when learning wireguard.
- Foxboron (talk) 18:23, 29 December 2017 (UTC)
Suggest adding advice about IP forwarding
When I set up wireguard it took me a little time to realize I had to enable IP forwarding in the kernel. Once I knew, all I had to do was:
# sysctl net.ipv4.ip_forward=1
So I think that would be good to add to the troubleshooting section or the tips and tricks section. The iptables forwarding rules suggested here won't work with that turned off.
- I do not have this parameter set and wireguard works without any issues on my setup Gregosky (talk) 10:14, 7 February 2018 (UTC)
Sounds Like an Ad
Being a blurb from the project's authors is no excuse. The following, unsubstantiated claim sounds like an advertisement:
- ... it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.
wq-quick@.service already contains
After=network-online.target. Enabling the wait online service causes the whole boot process to pause while waiting for a network connection and can dramatically increase boot times.
—This unsigned comment is by Smasher816 (talk) 03:54, 3 May 2018 (UTC). Please sign your posts with ~~~~!
Until a proper NM plugin is released, weird interactions are going to occur between Wireguard and NM. Typically, if you create a tunnel and NM touches DNS for whatever reason (lease timeout, reconnection, etc.) I loose my connection.
I specifically focused on
systemd-resolved because I find the approach much saner than the resolvconf mess. It is also supported by NM and not really "broadly" documented elsewhere.
—This unsigned comment is by Gdonval (talk) 10:52, 15 September 2018 (UTC). Please sign your posts with ~~~~!