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
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.
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=
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
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).
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.
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.
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
the WireGuard peer external address is
203.0.113.25 the entry would look
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
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.