Security tips for WireGuard VPN
Note:
This documentation has moved to a new home! Please update your bookmarks to the new URL for the up-to-date version of this page.
Here are some security tips for your WireGuard deployment.
Traffic goes both ways
Remember that the VPN traffic goes both ways. Once you are connected to the remote network, it means any device on that network can connect back to you! That is, unless you create specific firewall rules for this VPN network.
Since WireGuard is “just” an interface, you can create normal firewall rules for its traffic, and control the access to the network resources as usual. This is done more easily if you have a dedicated network for the VPN clients.
Using PreSharedKey
You can add another layer of cryptographic protection to your VPN with the PreSharedKey option. Its use is optional, and adds a layer of symmetric-key cryptography to the traffic between specific peers.
Such a key can be generated with the genpsk command:
$ wg genpsk
vxlX6eMMin8uhxbKEhe/iOxi8ru+q1qWzCdjESXoFZY=
And then used in a [Peer] section, like this:
[Peer]
PublicKey = ....
Endpoint = ....
AllowedIPs = ....
PresharedKey = vxlX6eMMin8uhxbKEhe/iOxi8ru+q1qWzCdjESXoFZY=
Note:
Both sides need to have the samePresharedKeyin their respective[Peer]sections.
Preventing accidental leakage of private keys
When troubleshooting WireGuard, it’s common to post the contents of the interface configuration file somewhere for others to help, like in a mailing list, or internet forum. Since the private key is listed in that file, one has to remember to strip or obfuscate it before sharing, or else the secret is leaked.
To avoid such mistakes, we can remove the private key from the configuration file and leave it in its own file. This can be done via a PostUp`` hook. For example, let's update the home0.conf` file to use such a hook:
[Interface]
ListenPort = 51000
Address = 10.10.11.3/24
PostUp = wg set %i private-key /etc/wireguard/%i.key
[Peer]
PublicKey = <contents-of-router-public.key>
Endpoint = 10.48.132.39:51000
AllowedIPs = 10.10.11.0/24,10.10.10.0/24
The %i macro is replaced by the WireGuard interface name (home0 in this case). When the interface comes up, the PostUp shell commands will be executed with that substitution in place, and the private key for this interface will be set with the contents of the /etc/wireguard/home0.key file.
There are some other advantages to this method, and perhaps one disadvantage.
Pros:
- The configuration file can now safely be stored in version control, like a git repository, without fear of leaking the private key (unless you also use the
PreSharedKeyoption, which is also a secret). - Since the key is now stored in a file, you can give that file a meaningful name, which helps to avoid mix-ups with keys and peers when setting up WireGuard.
Cons:
- You cannot directly use the
qrcodetool to convert this image to a QR code and use it to configure the mobile version of WireGuard, because that tool won’t go after the private key in that separate file.