Learn WireGuard - Interface & Key Management

#Introduction

In episode 3 you successfully brought up your first wg0 interface. Now it is time to understand every part you have been writing: the keys that underpin WireGuard and the meaning of each field in [Interface] and [Peer]. This is the foundation for correct and secure configuration.

Episode 4 dissects three areas: key management (including pre-shared keys), the [Interface] section that controls the interface's identity and behavior, and the [Peer] section that governs each inbound and outbound connection. By the end of the episode, your two VMs will connect to each other for the first time.

#Key Management

#Private and Public Keys

The private key is the source of an interface's identity, and the public key is derived from it. Always generate both at the same time and store the private key file with strict permissions:

umask 077
wg genkey | tee privatekey | wg pubkey > publickey

umask 077 ensures the key file is not readable by other users. The private key lives in the privatekey file, and the public key to share lives in publickey. Distribute your public key to all peers you will talk to.

#Pre-Shared Key

WireGuard can add an extra layer of security called a pre-shared key per peer. Its function is to strengthen the session key against scenarios where the private key leaks, at the cost of both ends having to share the same secret:

wg genpsk

Paste the result into PresharedKey in the [Peer] section on both sides. Note: this pre-shared key is per peer pair, not per interface.

#Key Rotation

Rotation is done by changing the interface's private key and updating the public key on the peer side. The following command swaps the private key live without taking the interface down:

sudo wg set wg0 private-key /etc/wireguard/privatekey

Full rotation along with a graceful rotation strategy will be covered thoroughly in episode 12.

#The [Interface] Section

Each WireGuard interface is defined in the [Interface] section. The most common fields:

• Address: the tunnel address assigned to the interface when wg-quick up runs.
• ListenPort: the UDP port used for listening. wg-quick defaults to 51820.
• PrivateKey: the contents of the interface's private key file.
• PostUp / PostDown: commands executed after the interface comes up and before it goes down.
• Table: controls which routing table wg-quick uses; Table = off disables automatic route addition.

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = pS9S6eGJY8tVb3DkG5XwS9zHpN9lQfBcE5S6o+3Qn5k=
Table = auto
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

The PostUp above is used to enable NAT masquerading as soon as the interface comes up, a pattern we will reuse many times in episodes 10 and 14.

#The [Peer] Section

#Available Fields

Each connection is defined in a [Peer] section:

• PublicKey: the public key of the destination peer.
• AllowedIPs: the addresses routed to this peer (the heart of cryptokey routing).
• Endpoint: the public IP address and UDP port where the peer can be reached.
• PersistentKeepalive: the heartbeat interval in seconds for traversing NAT.
• PresharedKey: an optional shared secret that adds strength to the session key.

#Connecting Two VMs

Time to connect the server and client. On the server, add the client peer; on the client, add the server peer:

sudo wg set wg0 peer <PUBLIK_CLIENT> allowed-ips 10.0.0.2/32

On the client, the configuration is built from the same fields:

[Interface]
Address = 10.0.0.2/24
PrivateKey = <kunci privat client>
 
[Peer]
PublicKey = <kunci publik server>
AllowedIPs = 10.0.0.0/24
Endpoint = 203.0.113.5:51820

AllowedIPs = 10.0.0.0/24 on the client side means all addresses in the tunnel subnet belong to the server. Once both sides have each other as peers, test the connection:

ping -c 3 10.0.0.1
sudo wg show

If wg show shows the handshake column populated, your two VMs are officially connected over WireGuard.

#Closing

Episode 4 completed key management and interface and peer configuration. You can now generate keys, add a pre-shared key, understand every field in [Interface] and [Peer], and successfully connect two VMs.

Key takeaways:

• wg genkey generates a private key; wg pubkey derives the public key.
• wg genpsk creates an optional pre-shared key per peer pair.
• [Interface] controls the identity, port, and up/down hooks of the interface.
• [Peer] controls the destination public key, AllowedIPs, endpoint, and keepalive.
• Both sides must know each other's public keys for the handshake to succeed.

In episode 5 we dissect handshake and lifecycle — how Noise IKpsk2 progresses from handshake initiation to flowing encrypted data, the anti-DoS cookie mechanism, automatic rekeying, and the session lifecycle from empty to data-received.