1-3: Wireguard Configuration
Note
This section involves code in the Git repository for this course. If you haven’t already, download it/clone it to a computer with the required software installed.
A Wireguard connection is defined by a configuration file. Wireguard uses these files, written in INI format, to create a network interface to handle Wireguard traffic. Let’s look at a simple Wireguard config to understand its structure.
# This section defines the local Wireguard interface
[Interface]
# The configuration doesn't actually need the PublicKey, but we keep it here
# for convenience
#PublicKey = mowyK+B79BzJDSvMOcKI7NpZZ/db8n6SnHhootGXdgk=
PrivateKey = 2BPdFaSlX15arFSnAcfw9RcjlkqoR2GQZ+/QEnZBZV0=
Address = 172.16.100.1/24
ListenPort = 51820
# This is where we define peers we connect to, or who
# connect to us
[Peer]
# This key must be provided to us
PublicKey = 4OgoXDOzpacd+DGY2SNFSkcax8lsaiYxIISsKQvVV3I=
# Pay attention to the CIDR notaton!
AllowedIPs = 172.16.100.2/32
The [Interface]
The first section of a Wireguard config file contains definitions for the local Wireguard interface. There are additional optional settings, but you need the PrivateKey and the Address at the very least. I also like to define ListenPort so any firewall rules are predictable. This is all Wireguard needs to bring up an interface (we’ll discuss how that works shortly), but we need additional information to connect to Peers.
The [Peer]s
For each Peer in our Wireguard network, we’ll need a unique [Peer] entry. Each of these requires at least a PublicKey and an AllowedIPs definition. That’s it!
Well, sorta. That’s it if the Peer you’re configuring with this file will be receiving initial Wireguard connections. I’m being careful here to not call such a Peer a “server,” but functionally that’s what it is. When the network is brought up, somebody has to receive initial handshakes. If you’re the recipient, then advertising your interface and defining Peer keys/allowed source addresses is sufficient.
On the other hand, if you’re the one initiating a connection, you need an additional definition for the Peer to which you’re connecting:
[Peer]
# This key must be provided to us
PublicKey = 4OgoXDOzpacd+DGY2SNFSkcax8lsaiYxIISsKQvVV3I=
AllowedIPs = 172.16.100.2/32
# The accessible Host:Port where the remote Wireguard
# interface is listening. Can be a hostname, FQDN, or IP.
Endpoint = remote.test.com:51820
Endpoint tells Wireguard where to look to initiate the handshake.
And then, one more thing. Wireguard is lazy. It will shut down inactive connections, which means you might find Peers unavailable after a long period of inactivity. To prevent this, we add a PersistentKeepalive entry with a number of seconds between which to send heartbeat packets to keep the session up.
So altogether, a Peer entry for an outgoing connection looks like:
[Peer]
# This key must be provided to us
PublicKey = 4OgoXDOzpacd+DGY2SNFSkcax8lsaiYxIISsKQvVV3I=
AllowedIPs = 172.16.100.2/32
# The accessible Host:Port where the remote Wireguard
# interface is listening. Can be a hostname, FQDN, or IP.
Endpoint = remote.test.com:51820
PersistentKeepalive = 25
Let’s fire this up in the lab to see how it all works.
Check For Understanding
- What is the difference between
[Interface]and[Peer]sections of a Wireguard configuration? - Why is
PersistentKeepaliveimportant?