The previous article, we created a dynamic DNS name and a machine on vultr.com, which will be our wireguard VPN host. This is the machine all the clients will connect to and can if we should desire run NginX as a reverse proxy that opens up those clients to the public world through that proxy. (we don't need the NginX reverse proxy if we don't want to expose the machines to the public. This will keep things completely private, but I wanted to mention it as another route if we need it.)

Installing ddclient on Ubuntu.

The first application we need is ddclient. This is what updates namescheap with our ip address. It is available in ubuntu's repository so we can simply run the "apt" commands. Before we can do that we need to get access to the terminal on our server. We have a few options, but I like to use something like "putty" to ssh into our server's ip address. You can find the server's ip address and the password from my.vultr.com, and click on the machine you want to view. There is a place that you can reveal the password for the root account. Assuming you did that let's run the commands to install and configure ddclient...

apt install ddclient 

Now we can run the next command to edit the config file...

nano /etc/ddclient.conf

In the ddclient.conf file we need it to look like the following:

# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf

protocol=namecheap \
use=if, if=enp1s0 \
login=xyz123.net \
password='1asdfasdfsa2ef1234daf345dsg768' \
wireguard, test1

###########################################

NOTE: I left "test1" in there to show you what you can do if you wanted more sub domains... you can keep appending more on as you wish. For now remove that "test1" as it probably doesn't exist and could cause some issues trying to update a subdomain that doesn't exist. The worst case is you could get error logs. It's also important to point out the "use=if" tells the software you want to use the network interface to get the ip address, and "if=enp1s0" specifies which interface you are getting the ip address of. In this VM we only have one, so this is where users will try to connect through.

Installing Wireguard VPN on Ubuntu

I really don't want to go through all of the steps and details to setting this up on the server. Especially since there exists other sites that go through it already. If you want to get a better understanding of how to do this, please check out how-to-set-up-wireguard-on-ubuntu-20-04

In this article I'm going to keep it very simple and just show the main steps...

The first one is to install the software...

apt install wireguard resolvconf

The DNS resolver isn't necessary for what we are doing, but it is needed if we want to route all of our traffic through the VPN, so we'll use it anyways.

resolvectl dns enp1s0

We need to generate the server's private and public keys. The private key doesn't leave the server. The public key is ok to send to anyone in the world. Being public key cryptography, it doesn't matter who has the public part. It is more complicated than I need to get into, but what the software does is encrypt some data with the public key, but only the private key can undo that encryption. This means it's important to keep your private key safe!

To make the keys, as the article linked to above says... you can run:

wg genkey |  tee /etc/wireguard/private.key

chmod go= /etc/wireguard/private.key

cat /etc/wireguard/private.key | wg pubkey |  tee /etc/wireguard/public.key

Now edit the /etc/wireguard/wg0.conf file (or create it if doesn't exist)

nano /etc/wireguard/wg0.conf

make it look like the following, but fill in the values you need:

################################################

[Interface]
Address = 192.168.51.1/24
DNS = 1.1.1.1
DNS = 8.8.8.8
SaveConfig = true
PostUp = ufw route allow in on wg0 out on enp1s0
PostUp = ufw route allow in on wg0 out on wg0
PostUp = iptables -t nat -I POSTROUTING -o enp1s0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on enp1s0
PreDown = ufw route delete allow in on wg0 out on wg0
PreDown = iptables -t nat -D POSTROUTING -o enp1s0 -j MASQUERADE
ListenPort = 51825
PrivateKey =

################################################

A few things to note:

the commands that say "PostUp" and "PreDown" are issued when the wireguard application starts up and shutsdown. Specifically we use it to set firewall rules to have while the VPN is connected and when it ends. The "UFW route allow on wg0 out on enp1s0" tells the UFW firewall to allow the data from the wg0 interface (our VPN) to go our the network card. If you want your machines to be able to go out to the internet we need that. If you want your machines to talk to each other you need the line with "ufw route allow in on wg0 out on wg0" this allows machines on the wg0 to cross over to other machines on the wg0 interface.

The "Address" is the IP address we want this machine to have on the VPN. I made sure to keep it with a .1 at the end. This is what routers will use. For example if you buy a home router it defaults to 192.168.1.1.

The listen port I have in bold because you can change that too. I changed the default to make it slightly less obvious. You can set this port to 8080 or whatever you want. Just make sure it's not a port of any services you may want to publicly expose if you are going to run a reverse proxy like NginX.

Now that we have that out of the way we need to make sure to configure it to start at boot.

sudo systemctl enable [email protected]

sudo systemctl start [email protected]

sudo systemctl status [email protected]

sudo wg-quick up wg0

We need to also open our firewall's ports with:

sudo ufw allow 51825/udp
sudo ufw allow OpenSSH

At this point we have a running wireguard VPN server we can connect to, but there are no clients allowed. Kind of useless, so let's get a client on...

Setting up a wiregaurd client.

This part depends a lot on the operating system and software we are using. If you are using linux the install process and creating the keys is the same as you did on the server. If you are using windows there is an app that can create the public and private keys for you. The important thing is that you have the right config file settings in the wg0.conf on the client. For the clients the "peer" it talks to is the server. Here is my example:

############################################

[Interface]
PrivateKey =
Address = 192.168.51.10/32

[Peer]
PublicKey =
Endpoint = wireguard.xyz123.net:51825
AllowedIPs = 192.168.51.0/24

PersistentKeepalive=25

############################################

For the "Address" in the "[interface]" section you would use the address the server is set to allow you to use. This is where wireguard isn't a very good at privacy, but we aren't using it for that. These IP addresses are set and the server also needs to allow that public key to use that ip address. I am using "192.168.51.x/32" because it is very unusual. I doubt a person will ever run another VPN or service in that range. instead of .51 you can choose 24,25,26 or 27...whatever you want as long as it is between 1 and 254. The reason for this is if you chose 192.168.1.1 that is the default address of your home router, so your local router will see that and thing the packets are for it. In other words they won't make it to the right place. 

The "Persistent Keep Alive" in the peer section is what is supposed to keep the connection active. If your client is a server that others should connect to I highly recommend having this in there to keep the connection going. If your client is simply a device using other services I'd remove the line completely. Don't need to send our unecessary data to keep a connection. It will be active when you try using it.

For the "[Peer]" section we need to specify the server's information. In the "Allowed IPs" field we specify the ip addresses that go over to the peer. In other words, if we specified 0.0.0.0 we would say all traffic goes over the VPN. This is good if you want to use it to hide your web traffic out to the cloud provider. In this case, I specify all traffic to the IP network goes over the VPN. This means that if I visit a site like 192.168.51.1 it will send it through the VPN same as if I visit 192.168.51.22 would also be sent out to the VPN. (they don't have to really exist the machine will still send it through there) and your traffic to places like 192.168.1.1 will not be routed over the vpn. This let's you use local machines not on the VPN at the same time as you access the VPN machines. If this doesn't make sense that's ok... just keep the ips I have in the example and you'll be fine. IP addresses are a bit complicated and best left to "network engineers"

Now we have the client's config set up we can't really start it yet since it won't work... 

Adding the client to the VPN Server

Let's hop back to the VPN server's terminal and run the following command to add the client to the VPN:

wg set wg0 peer allowed-ips 192.168.51.10/32

Each client will need their own IP Address, so make sure they aren't all using 192.168.51.10. As soon as the above line is executed on the server, we can tell the client to connect.

If all is good the client and server should be able to talk. To test this ping the other's VPN ip address. One the server you should be able to run

ping 192.168.51.10

and the client should be able to run

ping 192.168.51.1

If this doesn't work then your problem has to do with network traffic. That means the server might not be allowing traffic through the VPN or the IP addresses weren't configured properly... and good luck figuring it out. You will have to double check all of your settings and maybe doing some web searching. There are too many possiblilities to have in this article.

Now we have a client and a server we can keep adding new clients to the mix and they can all talk to eachother. I have noticed sometimes clients will disconnect randomly. I think this is due to unstable issues at the client's ISP.

Configuring a VPN watchdog

A simple way to keep the vpn alive is to add a watchdog script to all of your servers. Each server will be a little different, but I do have some examples for TrueNAS and UnRAID. The differences is the paths to use for the wq-quick command. In TrueNAS you have to point to the executable, but Unraid it has it in the path, so you don't have to worry about it... 

To have these watchdog scripts execute, you will need to setup crontab on a linux machine. On windows or android these scripts probably won't work and the clients may already do this. For my NAS boxes that run linux I use cron jobs... can find more information about cron jobs at https://www.freecodecamp.org/news/cron-jobs-in-linux/

Here is my TrueNAS script:

###############################################

#!/bin/bash

if ! ping -c1 192.168.51.1 > /dev/null 2>&1

then

echo “Wireguard VPN is down… trying to restart”

/usr/local/etc/rc.d/wireguard stop

/usr/local/etc/rc.d/wireguard start

ping -c1 192.168.51.1 > /dev/null 2>&1

fi

###############################################

Here is my Unraid/Linux Script:

##############################################

#!/bin/bash

if ! ping -c1 192.168.51.1 > /dev/null 2>&1

then

echo “Wireguard VPN is down… trying to restart”

wg-quick down wg0

wg-quick up wg0

ping -c1 192.168.51.1 > /dev/null 2>&1

fi

##############################################

What I need to point out is we are pinging the wireguard VPN server's IP address on the VPN. If this ping works we know we are connected to the vpn otherwise it will fail, which is when we need to try the commands to restart the wg0 interface. You can run this using a cron job as mentioned above. You can set it to run */1 minutes (every 1 minute) or */5 minutes (for every 5 minutes) just a little tidbit...

Now you should have a bunch of machines on the VPN and they all can talk to each other securely. In future articles I'll talk more about setting up reverse proxies. Reverse proxies would allow the public to access resources in the VPN. We would run the reverse proxy on the wireguard VPN host then it would direct traffic to specific IP addresses within the VPN. This is helpful if you want to run nextcloud on say Unraid and expose it to the public. If you don't want to publicly expose anything then don't worry about a reverse proxy.

There are lots of reasons why one should have their services running over a publicly facing wireguard VPN server running on a cloud provider. I found that for the small price of $5/month it offers a lot of flexibility. It allows machines to communicate with eachother no matter where they are in the world. It adds a layer of encryption to those machines. Put a NginX reverse proxy on the public facing wireguard VPN server and you can have it route requests to the machines on the VPN. We can easily use this to create our own and private dropbox like service with Nextcloud, gitlab for our git repository, rocket chat for a private chat service, or even a jitsi server for voice communications. This sounds a bit confusing, so we need to take a look at what I'm talking about...

In the image above each machine is at a different location. One might be in Texas while another could be in Washington. The "Wireguard VPN" is the only one that we can directly talk to on the internet. In other words, it's the only one exposed publically. This machine is running on a cloud provider such as vultr.com or you can run it on amazon's cloud too. Vultr has machines with 1GB ram down to around $5, so I've been using them.

Another advantage to having that VPN server in the cloud is that we don't have to open any ports to our machines at home. This can be more complicated than people want to deal with, it exposes our home network, and some ISPs have strange setups making it hard or impossible to host services at your home. With the above image we can host services on the cloud, but the machines are really at home.

If we are talking about privacy, it's important to keep in mind at each location they have an ISP. This ISP can see the public facing VPN server and that it's a VPN, but can't see the packets going over it. You can use this same setup as a VPN for your web traffic, but in that case you'd set your clients to route all traffic through. In this article, we are only routing the IP traffic for the machines on the VPN.

If the VPN is configured to allow clients to talk with each other, we can have "Mike's NAS" ssh into "Liz's NAS" to do a file transfer with say rsync. This allows us to do remote backups. The catch here is that we need to make sure the cloud provided machine has enough data transfer limits for us to work within. Sometimes you'll see 1 TB/month other times it could be 2TB or more. If you need more space it's always possible to upgrade later, so don't worry too much about it.

Create the Domain Names

To create this kind of setup our first task is we need a dynamic DNS. I found namescheap to be a good option. I can't really show the details as this has lots of private information, but the idea is you use namescheap to buy your own domain name like "randomHomeServices.com" it may not even matter what name you choose if you are simply using it for your own services. You can choose "xyz123.net" We will eventuall create new "sub domains" and these subdomains allow us to have nextcloud.xyz123.net go to one address, and vpn.xyz123.net go to another. We can utilize this to allow us infinite number of urls if we need it. In this case, I only want "wireguard.zyx123.net" for our subdomain. This is the one we'll be setting up as our public facing url.

What we can see in this image is that I own the xyz123.net on my account. That's the domain I own. I can add subdomains by clicking on "Manage" then click on "Advanced DNS". When the page loads click on "Add new Record" you want to make sure you pick "A+ Dunamic DNS Record" then for host you'd put the subdomain you want like "wireguard". When you try to access it, you would go to "wireguard.xyz123.net"... btw we aren't done on this page yet. We have to make sure we enable dynamic DNS clients...

To enable dynamic DNS clients to update the IP Address in the value column, which is how machines know what the "wireguard.xyz123.net" points to. A quick note: All machines have an IP address to talk with eachother it's us humans who have a hard time remembering that ip address, so we use Domain Name Services (DNS) to make it easier for us to remember. That also means this Dynamic DNS is completely optional, but keep in mind our IP addresses can change randomly, which is another benefit to using dynamic DNS. When the IP changes it will be updated.

Any ways, scroll down the page to get to the option to enable dynamic DNS clients... we need to make sure it's turned on AND take note of that password. That password will be required for clients.

Now we have the domain name, the sub domain, and the dynamic DNS client, we can move to the next step and that is to get the server setup...

Creating the Cloud Server.

There are lots of cloud providers, but I have settled on Vultr.com. I was going to try linnode, but they wouldn't let me get an account since I use a VPN for my web traffic. Vultr offered the same services and what appears to be the same prices, so I have been quite happy with my choice.

At vultr.com, we want to create a very lightweight machine. It doesn't have to do anything other than host the wireguard VPN server, and in the future run NginX if we should desire to go that far.

In the above image, you can see I own two machines. One is for the backup network that we are setting up in this article and the other I have my cell phone and some family member's on. The wireguard vpn I use for the cell phones, I route all of the network traffic over it. This hides the traffic from the cell phone providers sending it through the cloud service.

Anyways, to create these machines (the UI has changed a bit since I first created these machines) click on the "Deploy +" then the first item is "Deploy new machine" it will bring you to a page where you can select the machine you want. Keep in mind a few limitations we have to work with. We need to look at CPU cores, RAM, and network capacity. 

For the server we want to host the cheapest option is all that is necessary, so pick the "cloud compute" server starting at $2.50/month.

You can pick if you want AMD or Intel CPUs. I picked AMD Epic, but it looks like the Intel ones are also the same price, so either works. As you scroll down you'll see more options like where you want this machine hosted. For this, ideally you would want a location that is  closest to reduce latency, but it often doesn't really matter that much. As you scroll down more you can get to the real important stuff...

When we pick the "server size" we probably want the cheapest one we can get. These options do change based on the CPU we picked. If I said "Intel" I would get different options here, so the cheapest option I could find was $5/month and it was the "Intel Regular Performance"... for $1 more we do get more bandwidth, so I am satisfied here.

I haven't mentioned it yet, but we also want to have "Ubuntu LTS" version for our operating system. You could choose other operating systems if you want, but the commands later on will be different.

Just below, the "server size" you'll notice vultr automatically enables "backups", for this kind of setup we can get rid of that. You can always make a script to push backups down to one of the clients on the VPN then restore it manually if something goes wrong. In a production setup we might want to figure out how to do restores as fast as possible, maybe using snapshots, but in our case we don't need that. If someone is not able to access the VPN for a few minutes or even days it's not a problem.

This is where I should point out another nice reason to use dynamic dns... the machines can be set up to keep trying to connect to that dynamic DNS address, which can be moved to another machine. In other words, if our server gets hacked or deleted somehow, all of the clients are trying to connect to the wireguard.xyz123.net. We can create a new cloud machine, configure the DNS and the wireguard server...and the clients will reconnect like nothing happened. As long as I save my configurations I can restore them to any server I want. These backups can be hosted at the vultr.com site for some extra $, or I can just save them to one of my machines. I choose to save it to my machines. I do pay for snapshots back to when I first set it up, so that is helpful if something goes wrong. They can be restored in moments.

The "Additional Features" doesn't really matter much... there is another part where we can add ssh keys to allow us to remote into the root account, but I won't configure ssh keys for this article... let's keep it simple. At the bottom of the page we name the server. This name doesn't matter at all. Users are going to use the dynamic DNS name, so the name we choose here is only how we see the machine at vultr.com on the dashboard.

When you complete the purchase, you will have a new cloud machine. It takes a few minutes to set everything up, so let's leave the configurations to the next article... 

https://crazycompute.locals.com/post/4860893/globally-available-home-network-part-2

I do a lot of software based work and very privacy contious. I have multiple machines for specific tasks. Managing the data between them all can be quite a challenge. This is where syncing is helpful. With the right design, I can share specific folders like ones that contain my password safe (keepassXC) to all machines while not sharing data related specifically to my task. For example, hosting docker containers. I wouldn't want all of my PCs to have scripts for my docker images. This took a bit to fully figure out. Through my experiences I have found some huge cons and work arounds.

To review a bit, Nextcloud is a web server that can help share data between users. It also has clients that can be installed to sync data between the server and the clients. You can share folders to other users to sync those files to those user's machine.

As of today, there are some issues with this syncing. First one is that if a user A shared their files with another user B, that user B will immediately start downloading the files whether they want them or not. There is a feature you can enable to prevent automatically downloading if the filesize is too large. This helps mitigate issues but not completely. If someone really wanted to mess with others they could create shares up to that limit and simply spam the targeted user forcing them to download a ton of files just under that limit... I think the fix to this is to default to always asking the user if they want to accept a share and what to do with it, or even simply accept it but don't auto download.

Another issue I have found is you do NOT want to share directories or files that change frequently. (I can't adjust the sync delays) For example, if you are running a portable application or docker container in a share, it is constantly modifying files this makes the client sync application freak out. If you are trying to share applications to other users it can easily corrupt those files. This means you also don't want to sync a "work directory" where you may create python environments and download nuget packages etc. What I do is create a local directory for those things then copy + paste the completed files into nextcloud. This situation is probably better handled using git and not nextcloud sync if you are writing code.

My last complaint is similar to the first, but a bit more specific. There is a situation where you share a folder for my example I'll say "Home Records" it's the top most level, so if I shared it and created a new sub folder called "Purchases" that change will be pushed to all users I have shared the HomeRecords with. I suppose this is expected, but if I loaded that Purchases with 500GB of data no matter the setting the other users have it will push those files to everyone who is holding this top most share. I honestly don't know how to handle such a situation since most cases it is expected. Ultimately, being able to reject a share could be very helpful feature.

Now we have some understanding of a few big issues, the way I was able to get around the first problem was to use multiple users to my benefit. I can't say for computer A to hold specific folders and not others. Sure, there is the option to tell the client some kind of paths to ignore much like a gitIgnore file, but it isn't the easiest thing to figure out. If I move to a new PC I'd also have to put that back in place. The better option is if I could register "devices"/computers/clients that I own and choose which folders to share between them. Since this is not possible, I created one user for me, and sub users for each machine I have. This allows me to share some folders to specific machines without sharing everything to all or dealing with really annoying client settings. The system looks like this...

The idea is that all files will be created on the Main User's account. From there, I can share the folders to the specific machines I want those files to be stored on. In the rare case I need to move files between say my laptop to my data machine I could create a folder on my laptop and share it with the data machine directly, but I tend to avoid this because it adds a lot of uneccesary complexity. 

Something to note is that no computer should never have a client logged into the main user account. That's just a central contifuration point. You can log into it using a web browser (to create the shares), but never have the installed client application syncing files from that accoune. The reason for this is because it can get messy down the road and you'll be syncing all the files from that account. The only reason I can see to do that is if you want a full backup on another machine.