(security-tips-for-wireguard-vpn)= # Security tips for WireGuard VPN 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: ```bash $ 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 same `PresharedKey` in 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 = 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 mix-ups with keys and peers when setting up WireGuard. Cons: - You cannot directly use the `qrcode` tool 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.