Netmaker/Wireguard for the home LAN part 3 - Personal VPN Tunnel

engin akyurt via unsplash

In the third part of this series on Netmaker/Wireguard for the home LAN, (part 1, part 2) let’s set up another wireguard network, featuring our external vps server which we’re going to use to browse the web from a different IP address to dodge ISP filtering, much as one might via a commerical VPN provider.

Setup Instructions

In the netmaker web UI, click Create Network on the left, name it vpn and assign a new private subnet, eg. 10.10.10.0/24
Go to Access Keys and add an access key for the vpn network.
Now, we need to install netclient on our vps.
- First, make sure wireguard is installed.
- Next, install netclient. We can run it using docker, as detailed in the docker-compose file above. If you wish to install it directly on the host system, the curl oneliner shown when you generate the access key currently has a bug whereby the node name, autogenerated from the machines hostname, cannot have a dot in it. As such we must amend it like so:
```
curl -sfL https://raw.githubusercontent.com/gravitl/netmaker/develop/scripts/netclient-install.sh | VERSION=0.8.5 NAME=mynode KEY=<ACCESS_KEY>= sudo -E sh -
```
  Additionally, note that we have inserted sudo -E before the sh call. The script must be run as root, but if you naively put sudo at the front of the line before curl, only the curl call will be elevated, not the sh that actually executes the script. The -E ensures that the preceeding variables are not stripped by sudo.
  
  Upon success, we should see something like this:

checking dependencies...
wireguard
    wireguard is installed
OS Version = Linux
Netclient Version = v0.8.5
Binary = netclient
Downloading netclient latest
2021-11-09 13:12:53 URL:https://objects.githubusercontent.com/github-production-release-asset-2e65be/351486934/80a8af5c-c812-427a-8246-c70a2e053c49?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20211109%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20211109T131251Z&X-Amz-Expires=300&X-Amz-Signature=12c51211f87705a11bd2fa5d70f9a2c148c2aeda986d4eaf48c5d9dbd451aa77&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=351486934&response-content-disposition=attachment%3B%20filename%3Dnetclient&response-content-type=application%2Foctet-stream [15128045/15128045] -> "netclient" [1]
2021/11/09 13:12:53 [netclient] joining vpn at <EXTERNAL_IP>:4444
2021/11/09 13:12:55 [netclient] node created on remote server...updating configs
2021/11/09 13:12:56 [netclient] retrieving peers
2021/11/09 13:12:56 [netclient] starting wireguard
2021/11/09 13:12:57 [netclient] joined vpn

Alternatively, if you don’t like the idea of using a script like this, you can download the binary directly and feed it the access key. It will set itself up as a systemd service automatically.
Back in the GUI, you should see the vps added as a HEALTHY client.
Now we need to set it up as an egress gateway to the rest of the internet, as well as an ingress gateway for external clients. We are doing exactly the same thing as we did before for the home server node, except in a sense in reverse: traffic is going to be routed out from the node to the internet at large, as opposed to the LAN.

Click on the egress icon as before:
In address ranges, one might think one would specify 0.0.0.0/0 for all IPs. On desktop clients, the routes are prioritised such that LAN subnets will still be routable. This means, for example, that you will still be able to connect to your NAS box when connected to your VPN. However, this doesn’t work on the android wireguard client for whatever reason. The workaround is to instead specify an explicit list of all non private subnets, like so:
```
1.0.0.0/8, 2.0.0.0/8, 3.0.0.0/8, 4.0.0.0/6, 8.0.0.0/7, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6, 172.0.0.0/12, 172.32.0.0/11, 172.64.0.0/10, 172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4
```
For the network interface, specify the relevant device as usual, probably eth0.
Now this node also needs to be an ingress node, so click the button: and confirm the dialog.
Finally, add your external clients as before. You can verify that it works by browsing to a blocked site, or using traceroute to verify that your traffic is being routed correctly.

Additional Notes

If you want to be able to add new clients to the LAN tunnel via SSH from offsite, you will need to add the vps to the home network as well as the vpn one. Remember that netclient is already installed there, so you can add another network like so:

sudo netclient join -t <ACCESS_TOKEN> --name <NODE_NAME>

Then you’ll need to use ssh to set up a SOCKS proxy on the VPS, like so:

ssh -D your.vps.com -D1337

Then configure your browser to connect to a SOCKS proxy on localhost port 1337. You are then effectively joined to your home LAN, but only through the browser. You can then browse to http://$INTERNAL_IP:8002 and add yourself as a new client, and enjoy full highspeed systemwide routing rather than just through through the browser.

This concludes my series on netmaker. Hope you found it helpful! 😊