WireGuard VPN Walkthrough
This article was last updated: March 29th 2018. See follow-up article: Routing Select Docker Containers through Wireguard VPN
With the rise of privacy consciousness, people are looking to solutions like a hosted VPN (I hear one should never use a free service), or self hosted like streisand and algo. How does a VPN (a remote access VPN – not a site-to-site VPN for the pedantic) help maintain privacy?
In the scenario of maintaining privacy or getting around geographic content blocking, the VPN connects you to a server, oftentimes in a different country, where it forwards all your traffic to the intended recipient. The recipient responds to the server, which dutifully forwards back to you. So, if you live in the US, but are VPNed into a German server and request content from India, India will think you’re in Germany (this assuming countries have thoughts
I’m going to show how to self host WireGuard, which bills itself as easier to configure than IPSec and OpenVPN, while being faster and more powerful. WireGuard is a component feature of of streisand, but since we’re going to be dealing with only a linux client and server setup we cut out the streisand middleman and just use WireGuard. Theoretically, this cuts down on the bloat and attack surfaces that are inherent with the wide array of software that streisand installs (streisand is planning on supporting modular install in the future).
It should be noted:
WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change.
This demonstration will be on a DigitalOcean Ubuntu 16.04 box, but it should be easily adaptable for other platforms (as long as they are linux based).
The following script is to be executed on one’s server. This script will be subsequently broken down.
Simple enough, how does this work?
Sysctl allow modifying kernel parameters at runtime, so here we’re allowing the kernel to forward packets from one network interface to another. We need this, as wireguard works by creating the VPN on another network interface (commonly called wg0 or wgnet0). This interface, by itself, does not have internet access, but with ip forwarding we can foward traffic from the VPN to the interface that can communicate with the internet.
Forwarding is only important for the server because once connected to the VPN the default client interface won’t be used anymore.
sysctl -w is only for changing kernel parameters at runtime. To persist these settings, edit the relevant line in
These commands fetches the latest wireguard version and installs it. Since WireGuard hooks into the kernel, it attempts to automatically detect the correct kernel to hook into. This should work flawlessly.
The one problem I’ve had is that for DigitalOcean controls the kernel through their web interface (one can use a custom kernel but that is outside of the scope of this post). Anyways, if you had tried to install a custom kernel ontop of the one in DigitalOcean, wireguard will skip the correct kernel as it believes it’s chrooted. Sorry for the tangent, but since I experienced this problem, I figured I should document it for others.
Both the client and server need to generate a pair of keys. The server does not need to know the client’s private key and vice versa; however they do need to know each other’s public key to permit only authorized use of the VPN (else anyone who knew your VPN server’s address could use your VPN).
When clients connect to the server, they can communicate directly with by using the
10.192.122.1. We know that
10.192.122.1 can’t possibly be an internet facing box because it falls under a private network. The
/24 is a CIDR subnet mask that states that this VPN will is capable of housing 254 clients. WireGuard then listens on port 51820 for interested clients.
Probably the most convulted section of the config, yet this step must not be skipped. This is how those lines configure the firewall.
When the VPN is created:
- We accept packets from our VPN interface for packets being routed through the box
- Then whenever a new connection is created (eg. our client wants to access google.com, so the server needs to connect to google.com now), the outgoing packets are altered to have the server IP address so google.com responds to the server, which relays it back to the client.
Then when the VPN is destroyed everything in our firewall is deleted.
If you forget those lines, when you go to connect as a client your requests will blackhole and it may appear as if you lost internet connection.
The peer section is for client information. The client that connects with the given client public key is assigned
10.192.122.2 for their IP address.
The server is all setup so what does the client configuration look like?
Breaking down the config:
10.192.122.2/32 matches the same address as the server.
We set the client’s DNS server to that of the VPN server. This is not needed, but I recommend it, as you want to communicate with servers (eg. google.com) that are closest to your VPN server to minimize latency. For instance, if you live in the US, VPNed into Singapore, and wanted google.com, you’d want to talk to Singapore Google server (and not the one’s in the US) so that packets travel the least distance.
It is actually possible to create and destroy VPN boxes on demand for next level privacy. Here is how one would do this:
- Create DigitalOcean box by hand using the previous instructions.
- Verify that the VPN works (
wg-quick up wgnet0on both client and server).
- Take snapshot.
- Using the DigitalOcean cli one can create a new server from our snapshot (so the server will have the same public and private key, it’ll just have a new ip address)
- Update your client config to reference server’s new IP address
And just like that you can create and destory VPNs all around the world in under a minute.