DietPi-Software | WireGuard: Enhanced way to add multiple clients

[MichaIng]

Ref: https://github.com/Fourdee/DietPi/issues/2491#issuecomment-462419860

This is mainly an online docs task, but also check back our configs and comments.

---

Testing current situation

• Using a single [Peer] section with single key and 10.9.0.0/24 IP range.
• Using 10.9.0.2 on first client and 10.9.0.3 on second, everything else identical, using the same key pair.
• 🈯️ Non-parallel connection of both clients work fine, tested via apt update on clients and wg on server to track handshake times.
• 🈺 Concurrent connections work as well, but the second client will wait for the first to finish it's connection, before apt update starts. Where apt update handles this waiting time well, other software might not and fail, if initial connection hangs.
• 🈺 Tested with PersistentKeepalive = 25. At least 25 second ticks do not block the other client completely, might only add a tiny delay (for the tick itself) to other client connections, if performed bad timing.

---

Test with two [Peer] entries, same key for simplicity

[Peer]
PublicKey = XXXX
AllowedIPs = 10.8.0.2/32

[Peer]
PublicKey = XXXX
AllowedIPs = 10.8.0.3/32

• 🈴 Two peers with same key override each other. 10.8.0.3 can connect 10.8.0.2 not, server only lists one peer entry:

root@VM-Stretch:/etc/wireguard# wg
interface: wg0
  public key: ZZZZ
  private key: (hidden)
  listening port: 51820

peer: XXXX
  endpoint: 192.168.178.30:42953
  allowed ips: 10.8.0.3/32
  latest handshake: 6 seconds ago
  transfer: 5.72 KiB received, 17.44 KiB sent

---

Two peers with different keys

root@VM-Stretch:/etc/wireguard# wg
interface: wg0
  public key: ZZZZ
  private key: (hidden)
  listening port: 51820

peer: XXXX
  endpoint: 192.168.178.30:42953
  allowed ips: 10.8.0.3/32
  latest handshake: 55 seconds ago
  transfer: 12.13 KiB received, 33.74 KiB sent

peer: YYYY
  endpoint: 192.168.178.28:36957
  allowed ips: 10.8.0.2/32
  latest handshake: 1 minute, 6 seconds ago
  transfer: 41.52 KiB received, 321.70 KiB sent

• 🈯️ Works perfectly well, no hanging/waiting of clients for each other, authentication (handshake) tracked for each client separately.
• The PersistentKeepalive = 25 btw. prevents the need to renew the handshake on every connection. Without this, on every apt update a new handshake is one, while with the setting uncommented, I can do multiple tests without any handshake. Works well as intended, 25 seconds tick as well seem a reasonable default.

[MichaIng]

@Fourdee
How actually does the client authenticate against the server on OpenVPN? Client cert is at start only present on the client, which again only has the ca.cert to verify the server. But how does the server decide which client to allow and which not? Or are by default all clients allowed??

But our install matches/is derived from official docs: https://openvpn.net/community-resources/how-to/#setting-up-your-own-certificate-authority-ca-and-generating-certificates-and-keys-for-an-openvpn-server-and-multiple-clients

[MichaIng]

Implemented above results into: https://github.com/Fourdee/DietPi/pull/2526

• Update online docs: https://dietpi.com/phpbb/viewtopic.php?p=16308#p16308

[Joulinar]

Well done guys, nice online docs. Now I'm able to print QR code in smaller size to my screen 👍 . Relay nice, appreciate all your hard work.

[jvteleco]

Love DietPi and how easy is to install and setup things.
I noticed on the Wireguard notes, I think there is a typo with the IP of client example (instead of 10.9.0.3 should be 10.8.0.3 ?)
I had a little play to try to make this more automated based on your template. I am not an expert, so feel free to improve. I basically created a variable to store the client IP (WireGuard Client_IP) and then made easier adding the info to the wg0.conf:

WGC_IP="10.8.0.3"
cp -a wg0-client.conf wg0-client2.conf
G_CONFIG_INJECT 'Address = ' "Address =  $WGC_IP" wg0-client2.conf
G_CONFIG_INJECT 'PrivateKey = ' "PrivateKey = $(<client2_private.key)" wg0-client2.conf

echo -e "\n\n[Peer]"  >> /etc/wireguard/wg0.conf
echo -e "PublicKey = $(<client2_public.key)" >> /etc/wireguard/wg0.conf
echo -e "AllowedIPs = $WGC_IP/32\n"  >> /etc/wireguard/wg0.conf
WGC_IP="0"

[Joulinar]

@jvteleco 10.9.0.x should be correct. Guys changed it to avoid conflicts with NordVPN

[MichaIng]

@jvteleco @Joulinar
On current v6.21 it is still 10.8.0.X which is fine if you don't use OpenVPN (which DietPi-NordVPN is based on) concurrently.

To achieve concurrent OpenVPN compatibility we switch to 10.9.0.X with v6.22. However this does not affect existing installs, as we do not want to touch existing configs, which we assume run as they are and you configured your clients accordingly already. So 10.8.0.3 is correct if the WireGuard server IP is 10.8.0.1.

Ah yeah online docs have already been updated to new IP scheme, however I guess you guys figure it out, if your existing server/client IPs are 10.8.0.X 😉.

---

I had a little play to try to make this more automated based on your template.

Jep some automation makes sense here.
Actually by times I have the idea to create a simply GUI to add/remove client configs and configure the server and clients to your needs. It would then scan the server config for 10.9.0.$i (respectively the IP range based on server IP) entries, where $i counts up from 2 until no matching entry in wg0.conf was found. This first free IP will then be used for a new client.

[Joulinar]

Ah yeah that's how I meant my comment. You will change it in 6.22. Sorry for being that inaccurate in my comment before.

Your idea with the automation sound good. Will be happy to test it once ready.

[MichaIng]

Where we could learn a bid from: https://github.com/burghardt/easy-wg-quick

[Joulinar]

that looks straightforward. Also good idea to give a name to the config files, to have them identified later on :)

[MichaIng]

@Joulinar
Jep, I have the idea to add a simple GUI to add/remove/configure client configs. I would have done it just numbers, e.g. wg-client1.conf wg-client2.conf ... but why not giving them individual names.

So far our implementation works fine, but by times I will check out the additional iptable rules and stuff from that script.

[Joulinar]

Yes for me it's working very well as you have implemented it. And quite stable.
Personally I changed the names of the client configs already, just to know who is who. Like:

S8_client.conf
TabS3_client.conf