In this latest article in our Dispelling Myths series, we are addressing the common misconception that WireGuard requires static or fixed IP addresses to function. This configuration is indefinitely saved on the server and incompatible with no-logs VPN services. This is not the case at all, let’s go into more depth about how WireGuard functions in this regard.
WireGuard’s IP requirements are like any other VPN protocol
WireGuard does not require any static or fixed IP address. Nor do the IP addresses associated with WireGuard have to stick on the server for a while. Like any other VPN protocol, it is all about your configuration, and we take that seriously to get the most out of what all VPN protocols have to offer.
WireGuard is certainly no different. It is true that WireGuard can be set up in a more simple and inflexible manner using static IP addresses on servers, but this isn’t the most efficient or best way to deploy WireGuard.
WireGuard configuration and privacy implications explained
WireGuard kernel module does not save information in a sense that it logs it or something like that. However, the tools that WireGuard ships with do save information in configuration files. The point of using those tools (especially wg-quick) is to set up WireGuard tunnels quickly and without much effort, hence simplifying the deployment. One of the key reasons behind the WireGuard’s success and adoption is the ease of management. Those high-level tools and scripts are the management engine, which made WireGuard’s popularity soar.
With WireGuard the identities (public keys) need to be related to the local (in-tunnel) IP addresses. Those relations can be set up by higher level tools, which save them in a configuration file or by low-level tools which manipulate WireGuard’s peer list directly. The benefits of using high-level tools come at an obvious cost, privacy.
However, WireGuard does not have to be configured with high-level and user-friendly tools. The low-level and a much more powerful “wg” tool doesn’t require any saved information or any configuration file. Peers, their public keys and local addresses may be added or removed anytime. This is the dynamic form of WireGuard management. It is more complex though.
Hide.me ‘s privacy-friendly implementation
Hide.me is managing WireGuard tunnels as close to the kernel as possible. To manage IP addresses, public keys and the mappings, our system uses the wgctrl-go library which speaks directly to the Linux WireGuard module through the kernel’s netlink facility.
When a customer of ours tries to connect to our WireGuard service our apps generate a new private/public key pair. The app issues a connect request to our WireGuard RESTful service. The connect request includes only the public part of the keypair. Once the request gets authenticated, our system generates an additional shared key, a random local IP address for the customer and installs the WireGuard peer by directly communicating with the in-kernel WireGuard module.
The tunnel is up then and the VPN session starts. If and when the VPN session breaks, our system immediately erases the WireGuard peer definition from the kernel. In such a way any information about the session that just ended got permanently lost and cannot be recovered in any way.This method of dynamic management of WireGuard peers by direct interaction with the kernel module makes sure that the customer’s privacy gets preserved. There’s no logging or storage of any kind of information involved when taking this approach.
We love bringing you this content and hope it helps keep you safe and secure online. Feel free to share it with your friends, too.
Here at hide.me we are all about internet freedom, and we are happy to be in a position to bring that to everyone. That is why we give you a 30-day money-back guarantee on our Premium plan. No questions asked and no logs recorded.
If you have any questions, please feel to contact our 24/7 support team either at support@hide.me or via live chat.
Avery Davis 
Harriet Wainwright