Tip
This is the documentation for the 22.06 version. Looking for the documentation of the latest version? Have a look here.
Required Information¶
Before attempting to configure a WireGuard instance, several pieces of information are required in order for both sides to build a tunnel.
At a minimum, these pieces of information should be known before attempting to configure a WireGuard.
Public keys for each peer
Endpoint IP addresses and ports for each peer
A subnet to use for communication between peers
Lists of remote networks on each peer
WireGuard Keys¶
Every WireGuard peer, including this router, needs a private and public key pair.
Each peer should generate its own keys and the private key should not leave that peer if possible.
Warning
While keeping a backup of the keys is a good idea, do not copy the private key contents unnecessarily. Other peers do not need to know the private key, they only need the public key.
To generate a key pair, use the wg
command from any system which has the
WireGuard tools installed.
$ wg genkey | tee tnsr1.prv.key | wg pubkey > tnsr1.pub.key
$ cat tnsr1.prv.key
6CdptoVJkKPG3Bc5gKLIps3LC0D+2ga8Nfxh31Bhp0o=
$ cat tnsr1.pub.key
gJHc9lDjcM3KfOO4BdRP3tZWttZld23nvZoDy8FYQlE=
Note
These tools are installed by default on TNSR. They can be installed on other
systems using the OS package manager (e.g. sudo apt install
wireguard-tools
.)
Most graphical WireGuard clients (e.g. Windows, Android, iOS) also include their own mechanism to generate keys.
Distribute the public keys to the other peers as needed via some means (e.g. e-mail).
Endpoint IP Addresses¶
Both peers must have a static endpoint address, as outlined in Design Style.
WireGuard Interface Subnet¶
Choose a subnet for the WireGuard interface itself. WireGuard will use this to
communicate between peers. For tunnels with one peer on each end, this can be a
/30
prefix for IPv4. For a setup with many peers, use a large enough subnet
to contain them all.
Within this subnet, decide which addresses will be used by each peer.
Note
Addresses must be allocated to peers manually in the configuration, WireGuard does not have any mechanism to assign them on demand.
WireGuard Tunnel Next Hop¶
The dataplane requires an additional per-peer next hop configuration for WireGuard tunnels to locate a peer adjacency. This is due to the fact that WireGuard interfaces are non-broadcast interfaces and get handled differently internally by the dataplane.
See also
Each peer must have a tunnel next hop configured pointing to the WireGuard interface and peer addresses so that the dataplane can properly find adjacencies.
For a peer interface address of 10.2.111.2
on WireGuard instance 1
where
the WireGuard peer external address is 203.0.113.25
the entry would look
like:
tnsr(config)# tunnel next-hops wg1
tnsr(config-tunnel-nh-if)# ipv4-tunnel-destination 10.2.111.2 ipv4-next-hop-address 203.0.113.25
tnsr(config-tunnel-nh-if)# exit
Remote Networks¶
TNSR must know which networks exist at each peer for two reasons:
WireGuard must have the peer network(s), including their designated interface address, defined as allowed prefixes. This configures an association between keys and addresses for cryptokey routing internal to WireGuard.
TNSR must have routes in the route table for the networks so it knows to send traffic to these networks across a specific WireGuard interface.
This can be simplified in cases where there is only one peer per instance, as all networks can be allowed from a single peer and the routes can then be managed dynamically by a routing protocol.