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.


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
$ cat tnsr1.pub.key


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.


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

Tunnel Next Hops

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 on WireGuard instance 1 where the WireGuard peer external address is the entry would look like:

tnsr(config)# tunnel next-hops wg1
tnsr(config-tunnel-nh-if)# ipv4-tunnel-destination ipv4-next-hop-address
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.