Valid Generic HTML

Installing WireGuard

James F. Carter <jimc@jfcarter.net>, 2021-10-07, finished 2024-11-16

Some info about WireGuard, a new VPN:

About My Existing VPNs

I have just (2021) gone through yet another audit of my VPNs, making sure that they work for all relevant clients and that the vpn-tester program can competently report if they are or aren't working. Programs and versions installed as of 2024-11-01:

StrongS/WAN and OpenVPN work well when properly configured, but they have a number of less than wonderful features:

Introduction to WireGuard

Responding to shortcomings in existing VPN software, Jason A. Donenfeld in 2015 began to develop WireGuard, a new VPN. The project website describes these features; whether they're scored as good or bad depends on the user's goals.

Some details of the Edwards Curve Diffie-Hellman key establishment procedure are interesting. See this Wikipedia article about ECDH, which I've summarized. See also the EdDSA (Edwards Curve Digital Signature Algorithm) article, the section on ED25519.

My Goals for the VPNs

What are my goals for the VPNs, and how much hassle will it be to make WireGuard deliver what I need, so I can add it to my collection?

WireGuard VPN Design, Version 4

The network design went through a lot of changes. Here are some highlights of the transformations.

Teamwork: Bringing Function to All Hosts

Here is the network design that finally worked out:

Supporting Roaming Clients

Testing wild side connections is easy: on Selen (cellphone) just switch off Wi-Fi and let it use cellular data. On Xena (laptop), turn on Selen's hotspot and have Xena connect to it.

Pretty early, Selen and Xena on the wild side could initiate WireGuard communication to the server Jacinth, and could communicate with all other CouchNet hosts (including Surya) plus wild-side hosts, the same as if they were on Wi-Fi, i.e. were on the LAN and not roaming. When on cellular data the roaming clients could also initiate WireGuard communication to Surya and could communicate with more and more hosts as I fixed typos in addresses and dumb choices of routes. But for clients on Wi-Fi doing WireGuard to Surya, I started out only able to get service from Surya itself. This was a big advance because it will be the major use case during the relocation when Jacinth will be in its packing crate.

The major problem was that the server knows the client's (WireGuard) address but can't figure out a route to it. A packet from a potentially roaming client, e.g. Selen, when it's actually on Wi-Fi but doing WireGuard to Surya, started out going through this baroque path:

Items that Need Work

Tidbits

How to import a WireGuard conf file to Android (Selen) using a QR code:

Ideas for WireGuard Evolution

Official Multi-Client Support

Jacinth's role on OpenVPN and IPSec is as a generic server: potentially a variety of clients could connect at the same time, authenticating with an X.509 certificate with an acceptable trust chain. This isn't going to fly with WireGuard, since the server has to know the client's public key before it can accept a connection from the client.

Brainwave:

Anubis, Your Guide to the Underworld

The StrongS/WAN IPSec suite includes a daemon called Charon, formerly Pluto. The initiator starts a VPN-type connection by signalling their own Charon to establish a Security Association with the peer's Charon (authentication credential required) and to send to the peer connection parameters like which address ranges should go over the tunnel. In OpenVPN the connection setup module isn't a separate daemon but it performs similar functions, including selecting affected traffic (its equivalent of AllowedIPs is called an iroute).

WireGuard needs a similar gatekeeper which, following the underworld theme, I'm calling Anubis. Its functions are just about one to one equivalent to Charon's, but WireGuard has advantages in simplicity. Here are the basic design points:

Explicit Exit Notify

WireGuard needs the equivalent of OpenVPN's explicit-exit-notify. When the kernel module detects that a connection is going down (e.g. ip link del dev wg0) it should notify the peer. The rekey timeout seems to be short, about 2 minutes, but the rekey attempt only occurs if the non-dead peer sends a packet, and it's not clear how much state it's keeping for the dead peer and how significant that is. It just seems neater to notify the surviving peer if you're closing the connection.

Dealing With a Compromised Crypto Algorithm

Cryptographic algorithms can't be relied on to last forever, although Rijndael (AES) has lasted with only minimally effective attacks up to 2021 since 1997 (inception, or 2001, anointment in FIPS pub. 197), and ChaCha20 has been widely deployed from 2008 to 2021. It would be a very smart move to add algo negotiation, with the needed info in the dummy payload in the initial handshake packet.