Your submission was sent successfully! Close

Security tips

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 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 genpsk command:

$ wg genpsk
vxlX6eMMin8uhxbKEhe/iOxi8ru+q1qWzCdjESXoFZY=

And then used in a [Peer] section, like this:

[Peer]
PublicKey = ....
Endpoint = ....
AllowedIPs = ....
PresharedKey = vxlX6eMMin8uhxbKEhe/iOxi8ru+q1qWzCdjESXoFZY=

Both sides need to have the same PresharedKey in their respective [Peer] sections.

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:

[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 PreSharedKey option, 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.

Cons:

  • You cannot directly use the qrcode tool 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.

Last updated 23 days ago. Help improve this document in the forum.