For example, a sample WireGuard configuration looks like this:
```
[Interface]
ListenPort = <listenport>
PrivateKey = <privkey>
Address = <linklocal>/64
Table = off
[Peer]
PublicKey = <pubkey>
PresharedKey = <psk>
Endpoint = <endpoint>
AllowedIPs = ::/0
```
It is good practice to create a separate WireGuard tunnel for each peer. In this tutorial, `wg-quick` is used to manage the WireGaurd tunnels.
`<listen port>` is the local port to which the peer connects. This must be opened in the firewall using the UDP protocol. The only requirement for the port is that it is not already in use.
`<privkey>` is the private key. This should never be shared.
`<link local>` is link-local IPv6 address. It does not matter which one is used, because it is only valid for this interface. The only requirement is that the peer uses a different link-local IPv6 address.
`Table = off` prevents the creation of a default route for the `AllowedIPs`.
`<pubkey>` is the public key of the peer.
`<psk>` In addition to asymmetric keys, a symmetric pre-shared key can be used. This must be agreed in advance between the peers via a secure channel. A PSK is optional, but is recommended.
`<endpoint>` is the remote station, i.e. the peer. This is usually the host name or the IP address and the port. For example, `example.com:40006` or `peer1.crxn.de:20002`
`AllowedIPs` specifies the IP addresses that may be transported via the interface. `::/0` stands for any IPv6 address. If this is used, it is recommended to use firewall rules to avoid that peers can enter the clearnet via you.
## wg-quick
On Debian systems you store the configuration in `/etc/wireguard` with the file extension `.conf`. This may differ depending on the system. The name of the file also becomes the name of the interfaces. For example, you can save the file as `crxn_<peername>.conf`. The name of the interface then becomes `crxn_<peername>`.
The tunnel can be enabled with `wg-quick up <name>` and disabled with `wg-quick down <name>`. If can also control the tunnel with systemd:
```
$ sudo systemctl start wg-quick@<name>
$ sudo systemctl stop wg-quick@<name>
```
Furthermore you can autostart the tunnel with systemd:
```
$ sudo systemctl enable wg-quick@<name>
$ sudo systemctl disable wg-quick@<name>
```
## Key generation
With the command `wg genkey` you can create a key:
```
$ wg genkey
4HMlCI/Oz+sVmlM90c5YLpFR0/NaoMGv1uFT28qx1Gg=
```
To calculate the public key that you share with your peer, you can use the `wg pubkey` command. For this you can type `wg pubkey`, insert the private key and press CTRL+D. Alternatively, you can pipe the private key.
```
$ wg pubkey
4HMlCI/Oz+sVmlM90c5YLpFR0/NaoMGv1uFT28qx1Gg=
RmK5OX34MLbEwJTRNl8i9ghrAS4SkKDsr24NIK2bWSY=
```
```
$ echo 4HMlCI/Oz+sVmlM90c5YLpFR0/NaoMGv1uFT28qx1Gg= | wg pubkey
RmK5OX34MLbEwJTRNl8i9ghrAS4SkKDsr24NIK2bWSY=
```
(This method is not secure because it stores the private key in the command history).
## Tunnel status
The command `wg` shows all tunnels. The command `wg show <name>` shows only one specific tunnel.
```
# wg show <name>
interface: <name>
public key: <mypubkey>
private key: (hidden)
listening port: <listenport>
peer: <pubkey>
preshared key: (hidden)
endpoint: <endpoint>
allowed ips: ::/0
latest handshake: 1 minute, 30 seconds ago
transfer: 30.79 MiB received, 37.33 MiB sent
```
A WireGuard tunnel only becomes active and performs a handshake when it is used. If a tunnel is not used, there will be no handshake. The tunnel can be activated with a ping on the peers inner tunnel address, for example. Whether the tunnel is working can be seen by `latest handshake`. If this line is present, the handshake was successful.
```
$ ping fe80::2%<name>
```
## Non-public peer
If only one peer has a public IP address and the other does not, for example because it is behind a NAT, WireGuard will also work. In this case, you do not specify an endpoint for the public peer. For the peer that is not public, omit the `ListenPort` and add an extra line. This causes the peer to send a kind of "ping" every `<sec>` seconds to maintain the tunnel.
The interval may be different depending on NAT and firewall. 20 to 60 seconds is recommended. Often used values are `20` or `25`.
## Dynamic IP addresses
It may happen that one peer has a dynamic IP address. Often a DNS name is then specified. However, WireGuard only resolves the DNS once at the start of the connection and therefore does not know of the new IP address. Therefore, you must manually tell WireGuard to resolve the new IP address:
```
wg set <name> peer "<pubkey>" endpoint "<endpoint>"
```
This can then be executed as a cronjob every 30 minutes, for example:
So if the Clearnet connection has an MTU of 1500, the tunnel MTU when tunneling over IPv4 is 1440 and for IPv6 it is 1420. This has been taken into account in WireGuard, so the default MTU of WireGuard is 1420. This means that WireGuard can be tunneled over IPv4 or IPv6 without worry. However, if you are sure that you want to tunnel over IPv4 and you want a higher packet size, you can set the MTU to 1440. On the other hand, if the Clearnet interface has a lower MTU than 1500, you should lower the WireGuard MTU to avoid bugs and IP fragmentation.
When using wg-quick, you can adjust the MTU with the following statement under `[Interface]` in the configuration file:
```
MTU = <mtu>
```
`<mtu>` is replaced by the desired MTU.
## Debugging
WireGuard configuration errors are normally somewhat difficult to detect. However, it is possible to enable logging. With the following command, you can enable logging:
- [How to see debug logs for WireGuard (e.g. to see authentication attempts)?](https://serverfault.com/questions/1020279/how-to-see-debug-logs-for-wireguard-e-g-to-see-authentication-attempts)
- [Mailling list: Header / MTU sizes for Wireguard](https://lists.zx2c4.com/pipermail/wireguard/2017-December/002201.html)
