So I started to play around with the idea of a private VPN solution a while ago… The idea was to have a better sense of privacy when roaming between different networks. Having collected little experience with existing solutions, just using some commercial applications for business use over the last decades, I invested into a bit of research first. To identify the solution that suits my personal needs best.
I was looking for a simple solution, simple in the sense of an easy and transparent setup, also easy to use in daily life. So a robust solution. The target was to have all network traffic of my mobile devices routed through a personal system by means of a VPN tunnel. If possible, network performance should not be impacted such that it prevented me from using the solution.
I quickly settled on „wireguard“ as a newcomer in the field. Albeit an interesting newcomer for all I could tell. And since research and reading does not really provide a solution I quickly decided to give it a try in my personal network topology I setup over the last years. Although the solution is not yet mainstream (it only got accepted into the mainstream Linux kernel a few days ago…) there are packages provided for all major Linux distributions and you obviously can also build it yourself with little effort.
The actual installation was straight forward, as expected. I chose to use a virtual private server as the routing node and setup notebooks and android mobiles as peers. The android app from the playstore was a bit awkward to configure. Not so much the settings dialog itself, but the way that the runtime control is split into two completely separate parts which is kind of confusing. This might be caused by the android system however, its idea of integrating a VPN solution.
Unfortunately as easy as the installation was the actual setup turned out to be quite a challenge. Which surprised me quite a bit, since the few guides I found on the internet looked pretty straight forward. Not exactly trivial, since they consist of three steps. But certainly doable…
You probably can imagine my frustration as I failed to find a working setup. I returned to the unfinished business three times. Always with the same result: accepted setup, everything looking fine to me. Only that the clients were unable to channel their traffic through the node. Which, of course, is the only thing that matters in the end …
After maybe two weeks of trying around I finally found a working setup. Experimented with it a bit, since I did not really trust it. But to my surprise it appears to be usable and stable. Why did it surprise me? Because it is against all I could read in those setup guides I followed. In my personal experience they all are wrong, as if the authors copied from each other without actually testing their setup…
Certainly it might as well be that my setup is complete nonsense and only tricks me into believing that everything is finally working. So far however all my checks turned out positive. Which is why I decided to share my findings here:
The issue is the address patterns used in the peer configuration. I fail to understand why, but there is an aspect I had to change to get things working compared to what is suggested in all guides:
I had to use a different network mask than suggested in all guides I read. Things work fine when using a specific networking address for each peer, but not when working with the common network mask of 32 bits (IPV4) or 128 bits (IPV6). I fail to understand the actual reason for it, but trial and error convinced me that this is indeed the case.
So without further ado here is my working setup:
[Interface] Name = service Address = 10.66.66.1/24 Address = fd42:66.66::1/64 SaveConfig = true PostUp = <documented iptables rules adapter to my network> PostDown = <documented iptables rules adapter to my network> ListenPort = 51280 PrivateKey = <some key> [Peer] Name = yotun PublicKey = <some key> AllowedIPs = 10.66.66.2/32, fd42:66.66::2/128 [Peer] Name = arther PublicKey = <some key> AllowedIPs = 10.66.66.3/32, fd42:66.66::3/128 [Peer] Name = yuri PublicKey = <some key> AllowedIPs = 10.66.66.4/32, fd42:66.66::4/128
As you can see I stuck to the network mask on the client side, it does not really matter there. This setup seems to work reliably for all my clients (8 so far …). Disconnecting the tunnel blocks network usage on those devices (as expected), sniffing network traffic with a connected tunnel shows all packages to get routed through the VPN gateway (as desired).
