DietPi-Software | WireGuard: Install fine tuning

[MichaIng]

Status: Ready

• Changelog

Testing:

• Jessie install
• Jessie reinstall
• Stretch install
• Stretch reinstall
• Buster install
• Buster reinstall

Print QR code to console to scan with mobile client: qrencode -t ansiutf8 < /etc/wireguard/wg0-client.conf

Commit list/description:

• DietPi-Software | WireGuard: Unmasking kernel packages is not required, since overridden by apt-get install. As well it fails and breaks install (G_RUN_CMD), if one package is not yet installed.
• DietPi-Software | WireGuard: Do not force reboot after kernel updates, instead inform user via prompt, if no automated reboot is triggered.
• DietPi-Software | WireGuard: Do not reinstall wireguard-dkms to rebuild the kernel module, instead use dpkg-reconfigure, and, only if it was no fresh install.
• DietPi-Software | WireGuard: Estimate required reboot by checking modprobe exit code; Enable IP forwarding and start service for current session only, if WireGuard module has been successfully enabled
• DietPi-Software | WireGuard: Do not overwrite any existing keys or configs
• DietPi-Software | WireGuard: Enable IPv6 tunnel and forwarding
• DietPi-Software | WireGuard: Add comments to default client config about how to tunnel local network or server access only, DNS server choice and multiple clients
• DietPi-Software | WireGuard: Allow choice between server and client setup. In case of client setup, skip all config steps, instead inform user to follow VPN provider instructions. Add VPN (auto)start info as well, in case the VPN provider does not include it.
• CHANGELOG | WireGuard VPN is now available for installation.

[Fourdee]

Thanks @MichaIng

Looking good, nice one 👍

Please merge when ready.

[MichaIng]

@Fourdee
Actually reboot after kernel package upgrade of course is the safer method, but leads to doubled install steps and end user effort, that I am not happy with. And as said during my tests, the APT package installer quite intelligent build the module again current and newest kernel, where headers are available, to this should work reliable.

If indeed we find users/devices where it somehow doesn't (e.g. also during Beta phase), we can still revert and it's at least very easy to fix manually as well.

---

Just two quick questions, maybe you have some deeper insight about it:

• If not forwarding incoming VPN requests, the client will only see the servers VPN interface IP, right? So in our case 10.8.0.1 and it's not possible to access it via it's eth0/wlan0 interface IP (from outside local network)?
  So the iptables forwarding is required, even if one only wants to access to the server machine itself (or it's DNS server, e.g. Pi-hole) by it's local network IP?
• And I am still thinking that it should be possible to achieve this routing via iproute2 commands, isn't it? This would allow to skip iptables install/requirement. At least a firewall effectively can be achieved via iproute2 commands and I couldn't find some hint that iptables has some advantages, besides it's purpose is a firewall, while the routing tables initial purpose is, yeah routing of course... We did the same for our fail2ban install, switching from iptables based blocking to route.

---

Ah and would be great to have some hints about how to configure WireGuard as client. Although, usually the provider should serve a config file. Perhaps we can add a simple script, instructions or additional whiptail based prompt, to enable a given client config (and skip the server config part).

[HiDef888]

@Michalng
I may have a script from Mullvad that may help with client config. It’s on my home PC. I’ll pastebin it when I get home. Pretty sure I do anyway!

[Fourdee]

@MichaIng

Just two quick questions

VPN is point to point tunnel at a basic level. Additional routing can be setup on the server as required (eg: external routing + internet access).

In example of NordVPN, you effectively use the internet from the VPN server. New external IP address is then visible.
Local IP provided by the VPN side is accessable by VPN client and server only, unless server has setup routing for incoming eg: 89.238.191.202 > 10.8.8.192

Your Public IPv4 is: 89.238.191.202
Your Local IP is: 10.8.8.192

[MichaIng]

@Fourdee
Thanks for the info. Okay, then I think, regardless whether one requires internet access through VPN, local network access or single server access only, we should leave the iptables forwarding inside, so users can access it via it's local network IP (e.g. 192.168.0.100). Otherwise one would need to "remember" the VPN interface IP as well (10.8.0.1).

Do you know how to achieve this using iproute2 (route table) instead?

[HiDef888]

https://pastebin.com/XpcCXp0G
@MichaIng

Here is how Mullvad runs their wireguard client script FYI
I dont know if this helps you or not.

[MichaIng]

@HiDef888
Thanks for this.

Okay the script creates a key pair locally and sends the public key to the Mullvad server API to receive the config file (entries). This then looks pretty much the same as our client config:

        [Interface]
        PrivateKey = $PRIVATE_KEY
        Address = $ADDRESS
        DNS = $DNS
 
        [Peer]
        PublicKey = ${SERVER_PUBLIC_KEYS["$CODE"]}
        Endpoint = ${SERVER_ENDPOINTS["$CODE"]}
        AllowedIPs = 0.0.0.0/0, ::/0

So I guess we can expect all VPN providers (supporting WireGuard) will either have such an config script/installer, a prepared config file or documentation about how (with which entries) to create one. The key pair creation high likely is always included in this, since the VPN server of course needs to know/allow the clients public key.

• So it should be then sufficient to allow a server/client setup choice and in case client is chosen, skip the whole configuration steps and instead inform user to follow the VPN providers instructions and/or install the client configuration provided by the other DietPi WireGuard server.

Only question is:

• How do we handle the systemd unit/VPN auto start. The Mullvad script does not include any interface init part, so one needs to manually do this via systemd unit, systemd-networkd or ifupdown triggers. Surely there will be some instructions.
• Hmm I think we can simply add the info to, if no auto start has been implemented, check /etc/wireguard for the created config file <iface>.conf and use

systemctl start wg-quick@<iface>
systemctl enable wg-quick@<iface>

to start and enable it.

EDIT: finished!

[HiDef888]

* How do we handle the systemd unit/VPN auto start. The Mullvad script does not include any interface init part, so one needs to manually do this via systemd unit, systemd-networkd or ifupdown triggers. Surely there will be some instructions.

* Hmm I think we can simply add the info to, if no auto start has been implemented, check `/etc/wireguard` for the created config file `<iface>.conf` and use

systemctl start wg-quick@<iface>
systemctl enable wg-quick@<iface>

to start and enable it.

https://mullvad.net/en/guides/wireguard-and-mullvad-vpn/

FAQ on mullvad has some interesting features listed that may be worthwhile

Q: How do I enable a kill switch?
A: You can add the following lines under the [Interface] section of the WireGuard configuration files found in /etc/wireguard/ :

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

Issue man wg-quick for more information.

Q: How do I make WireGuard start automatically on boot ?
A: systemctl enable wg-quick@mullvad-se4 (replace mullvad-se4 with the WireGuard server you wish to use)

It appears you're spot on with the systemd enable to get it to autostart. Additionally the inclusion of a killswitch would be fantastic which they address in their FAQ. I do expect as more VPNs include WG that they will probably use this script from mullvad. This particular script was written by the WG creator.

I have been running a modified script from one of our fellow forum users that uses openvpn along with Monit and it works amazingly well to monitor the Interface (tun0) and reup the connection if it happens to fail. This would also be applicable to a (wg0) interface with a little modification.

https://dietpi.com/phpbb/viewtopic.php?f=15&t=3074

If you need me to help with that I may be able to do so. I am not a programmer by trade however I can do some basic bash work. I think it would be neat to see something like this in a whiptail menu to setup a VPN client. It always seems to be a big hurdle to not only help people setup a VPN but to do it correctly. I think WG goes a long way in simplification of that process vs OpenVPN.

[MichaIng]

@HiDef888
Thanks for this. Perfectly matches our way and fit's well to the client setup prompt I just implemented 😃.

About the kill switch:

• The issue with implementing this automatically (after user prompt) is, that we cannot predict the interface config file name, where to add the kill switch to, especially, since users most likely install WireGuard via dietpi-software first and run the VPN providers installer/instructions afterwards.
• So, AFAIK, the best we can do is adding this info to our online docs. I can also add it to the client setup prompt, implemented as above, but perhaps it would grow a bid too large, so not all info is on screen in many cases without scrolling?

[MichaIng]

Okay passed retest with client and server choice. Will merge.

For now I think we will add the kill switch info to our online docs, also because this requires copy&paste which cannot be done well from the prompt. I added this as info to the beta ToDo: https://github.com/Fourdee/DietPi/issues/2415