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.
You may add another layer of cryptographic protection to your VPN with the
PreSharedKey option. Its usage is optional, and adds a layer of symmetric-key cryptography to the traffic between specific peers.
Such a key can be generated with the
$ wg genpsk
And then used in a
[Peer] section, like this:
PublicKey = ....
Endpoint = ....
AllowedIPs = ....
PresharedKey = vxlX6eMMin8uhxbKEhe/iOxi8ru+q1qWzCdjESXoFZY=
Both sides need to have the same
PresharedKey in their respective
Preventing accidental leakage of the 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 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:
ListenPort = 51000
Address = 10.10.11.3/24
PostUp = wg set %i private-key /etc/wireguard/%i.key
PublicKey = <contents-of-router-public.key>
Endpoint = 10.48.132.39:51000
AllowedIPs = 10.10.11.0/24,10.10.10.0/24
%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
There are some other advantages to this method, and perhaps one disadvantage.
- 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 mixups with keys and peers when setting up WireGuard.
- You cannot directly use the
qrcodetool to convert this image to a qrcode and use it to configure the mobile version of WireGuard, because that tool won’t go after the private key in that separate file.