in ,

Setting up a home VPN server with Wireguard, Hacker News

Friday, 1st of November, A.D. 2019

Motivation

For a moderately security conscious geek like myself, there can be a number of reasons to want to set up a home VPN server:

  1. Accessing your home computer via screen sharing without exposing it to the Internet (and thus to potential evil-doers).
  2. Accessing servers with IP white lists (common case for security hardened IT systems).
  3. Accessing county-IP-filtered things like Netflix while traveling.
  4. Browsing privately from insecure WiFi networks.
  5. Getting access to services that are blocked inside restrictive corporate networks.

I have use cases for all of those from time to time, and after a bunch of frustrated attempts at getting OpenVPN working as I want it to, I decided to tryWireguard, a fairly new VPN software that promises to cut through some of the complexities of OpenVPN or IPSec, while delivering a secure (and fast) connection. Getting it set up can be a little tricky if you (like me) don’t usually do a lot of networking stuff and don’t know all the ins and outs of it, so here’s my “Wireguard for dummies” explanation. Important clarification

To Wireguard, there are no dedicated servers or clients, there are only “peers”. For the set up described here, one side will act as a server, and the other side as a client, so I’ll use those terms to describe them for clarity.

Installing the Wireguard server

The officialWireguard installationpage has instructions for lots of different platforms. My Wireguard server is on a RaspberryPi (running Raspbian Buster), so I followed the instructions for Debian, which worked great.

The rest of these instructions should work on any other UNIX-y server (or even for running Wireguard inside a Docker container if that’s more your speed).

Once you’ve got it installed, we can proceed.

Configuring the Wireguard server, part 1

Generate a private key

Runwg genkeyon the Wireguard server, and copy it so we can use it for the server configuration file. As the name implies, the private key should be kept private to ensure the security of the VPN connection. *****

For this example, we’ll use6NJepbdEduV 97 exampleprivatekeydontusethis=– donotuse that key in your real setup, generate your own.

Server configuration file

Edit (or create) the file/ etc / wireguard / wg0.confto look something like this:

[Interface]PrivateKey=6NJepbdEduV 97   exampleprivatekeydontusethis=Address=10.  0.0 / 24ListenPort=51820PostUp=iptables -A FORWARD -i% i -j ACCEPT; iptables -A FORWARD -o% i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEPostDown=iptables -D FORWARD -i% i -j ACCEPT; iptables -D FORWARD -o% i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Here, we use10. 0.0 / 24as the “address” for the Wireguard server. The/ 24at the end means we will be using a subnet of all IP addresses from 10. 14 .1 to 10. .0. 254.

This is a separate IP network from my home LAN, and shouldnotoverlap with it. Connecting VPN clients will then use an IP inside this network, and be able to access my LAN via routing, which we’ll set up later.

Configuring Wireguard client, part 1

In my example, I’m using theWireguard client for macOS) , but the configuraiton file format is the same for all clients, so you should be able to use whichever version you prefer. There are links to clients for macOS, Android, iOS, Windows and a whole bunch of Linux and BSDs on the aforementionedWireguard installationpage.

To get started, first create a new tunnel:

            Created a new tunnel    

The macOS client fills out thePrivateKeyfield when creating a new tunnel. If your client doesn’t, you can generate one on the server with thewg genkeycommand we used above. It should not be the same as the private key used in the server configuration.

Copy the generatedpublic (key) again, the macOS client generates it automatically for us) so we can put it in to the server configuration.

Configuring the Wireguard server, part 2

On the server, edit/ etc / wireguard / wg0.confAgain.

Below the configuration we added in step 1, add this:

[Peer]PublicKey=SOMETHINGSOMETHING   clientpublickeyhere=AllowedIPs=10. 14 .0 10 / 32

Fill in the public key from theclient.

The IP address inAllowedIPsdetermines which IP address inside the subnet we set up on the server (10. 14. 0.0 / 24) the client should be allowed to use.10. 0. 10 / 32means that the client will have to use the IP10. .0. 10, and can thus only have one active connection at a time.

That is a reasonable configuration, in my opinion. If you have multiple devices you want to connect, you should use separate public / private keys and give them a different IP address.

Once you’ve added this, we’re ready to start the Wireguard server, do this by runningsudo wg-quick up wg0.

That’ll output something like this:

[#] ip link add wg0 type wireguard [#] wg setconf wg0 / dev / fd / 63 [#] ip-4 address add 10.  0.0 / 24 dev wg0 [#] ip link set mtu 1420 up dev wg0 [#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

When that is done, check the server status by runningsudo wg. That should output something like this:

interface: wg0   public key: ASDFJKASDFSERVERPublicKEyHERE=  private key: (hidden)   listening port: 51820  peer: SOMETHINGSOMETHING   clientpublickeyhere=  allowed ips: 10.  .0. 10 / 32

Copyserver’spublic key from the status info, so we can use it to configure the client.

Configuring Wireguard client, part 2

Now the server is running, we have everything we need to configure the client.

Go edit the tunnel we created earlier, and change the configuration to something like this (leaving the private key we set up earlier alone, so it matches the public key in the server config):

[Interface]PrivateKey=SOMETHINGSOMETHING   clientprivatekeyhere=Address=10. 14 .0 10 / 32DNS=10. 42 .1[Peer]PublicKey=ASDFJKASDFSERVERPublicKEyHERE=AllowedIPs=0.0.0.0/0, :: / 0Endpoint=you.example.net: 51820

There are a few important thing to keep note of here, when adopting this configuration for your own use:

  1. ThePublicKeymust be the public key of theserver. Each side has its ownprivatekey and theother (side’s) ******************** (public) key.
  2. TheAddressin the[Interface]section on theclientshould match theAllowedIPsset in the[Peer]section on the server.
  3. AllowedIPson theclientdetermines what IP addresses are routed through the VPN connection. Here we use0.0.0.0/0as a wildcard to ask thatalltraffic is sent through the VPN. That is what you need for reasons 2-5 described in the motivation section. If you just want to access your home LAN through the VPN, and use your regular network connection for everything else, fill in its network instead, e.g.192. 1.0 / 24.

    :: / 0does the same for IPv6.

  4. TheDNSentry defines the DNS server that’ll be used when trying to access the network through the VPN. In this example, it’s the IP address of the router in my home LAN.
  5. Endpointis the hostname (or IP address) plus port number where the Wireguard server can be reached. If you have the average home LAN, you’ll need to set up port forwarding in your home router to make the Wireguard server accessible from the Internet.

    How this is done, is different from router to router, so I can’t provide much more detail than that.

    If you don’t have a static IP, you’ll probably want to set up dynamic DNS, too.

Final touches

To allow clients connected to your Wireguard server to connect to your LAN (and the Internet), you’ll need to configure the server to act as a router.

On Raspbian, this is done by editing/ etc / sysctl.confand editing thenet.ipv4.ip_forwardline to saynet.ipv4.ip_forward=1. If the line is not present already, add it.

For IPv6 routing, also setnet.ipv6.conf.all.forwarding=1in the same file.

You’ll also want Wireguard to start automatically on reboot. On Raspbian, this is done by running:

sudo systemctl enable wg-quick @ wg0

Once that is done, try rebooting to see if everything loads correctly and ensure the IP forwarding we enabled is loaded correctly.

After rebooting, runningsudo wgshould give you the same output as before, indicating that the Wireguard server is running as expected.

Try it out

Once that’s all done, you should be able to connect, on macOS that can be achieved via this activate button (sensitive details redacted):

            Connection dialog, inactive    

If all goes well, you should see the information change to indicate data flowing through the VPN connection, like this:

            Connection dialog, active    

As you can see, I’ve set up multiple tunnel configs, one forwarding all traffic, and one just giving access to the home LAN.

If you connect to the server and runsudo wg, you should see something like this:

interface: wg0   public key: ASDFJKASDFSERVERPublicKEyHERE=  private key: (hidden)   listening port: 51820  peer: SOMETHINGSOMETHING   clientpublickeyhere=  Endpoint: 11. 22. 44. 88: 55393   allowed ips: 10.  .0. 10 / 32   latest handshake: 51 seconds ago   transfer: 284.  (KiB received, 421.  (KiB sent)

Acknowledgments

I wrote this after having the friendly people in the# wireguardchannel on Freenode (IRC) help me understand Wireguard better. Thanks, y’all.

This document and its illustrations are released under the terms of ofCreative Commons CC0, and are thus free for anyone to use as they wish.


Read More
Payeer

What do you think?

Leave a Reply

Your email address will not be published. Required fields are marked *

GIPHY App Key not set. Please check settings

NBC Rumor Teases Amazing Surprise for Fans of The Office, Crypto Coins News

NBC Rumor Teases Amazing Surprise for Fans of The Office, Crypto Coins News

Leaving Apple, Hacker News