hpr-knowledge-base/hpr_transcripts/hpr3645.txt

Episode: 3645
Title: HPR3645: How to set up a small Linux Wireguard VPN
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3645/hpr3645.mp3
Transcribed: 2025-10-25 02:45:32

---

This is Hacker Public Radio Episode 3,645 for Friday the 22nd of July 2022.
Today's show is entitled, How to Set Up a Small Linux Wireboard VPN.
It is part of the series networking.
It is hosted by Jaron Baton.
It carries a clean flag.
The summary is I set up a small VPN and wrote a blog post about it.
This is just an audio recording of that.
Hello people from HBR, this is Jaron Baton.
Again, the second podcast I'm recording since a long, long time.
And this one is about setting up a VPN.
And probably, the solutions that are available, open VPN, it's famous, it's been here
a very long time, there's a lot that you can do with it.
It's stable, it's mature, it's fancy and it's well probably complicated.
And that's where I started to hesitate because most IT guys I like to automate stuff because
I'm lazy.
So drilling it down basically, I'm lazy.
But I did have the need for VPN.
Why?
Because I live in the Netherlands and I have recently acquired a very small farm in rural
France.
And there I put the Raspberry Pi in there to the GPO port, the thermometer, thermal sensor.
And I'm monitoring the in-house temperature with my Zebix instance.
And that all worked.
I used the Zebix Proxy on one of my cloud servers.
But from time to time, you like to be able to log in directly on the remote Pi located
in France when you're not there.
So people kept on telling me, I kept on reading that WireGuard is so easy, I thought, well,
let's give it a try.
So what are my needs?
Well I have two remote systems and I want to be able to connect to them both.
Other systems are behind the standard Net Firewall, you know, like a home router.
And I want to be able to copy files between them easily.
I'm not a VPN or network with, but know my way around IP addresses.
I know that besides WireGuard there are more options like OpenVPN, but they prefer an
easy setup with enough security.
So I got hacking the other day and I found a few small pitfalls in WireGuard and I like
to explain them to you.
So to help others, setting this up, I decided to write a small, the complete guide to setting
up a multi-PRI WireGuard VPN network and it's on my blog.
So the link is in the show now, it's of course.
And basically I'm lazy so I'm reading my own blog.
But you know, maybe you don't have the time to read the blog and maybe you're in your
car and want to listen to a HPR podcast.
So I thought, well, let's convert this text into audio.
So basically I'm a very heavy and old text to speech synthesizer.
So anyway, getting started is the easy part.
There are enough guides on the internet by now on how to get some initial setup.
The thing is, after following those directions, you are probably only halfway there.
There are two pitfalls that I will discuss.
Anyway, let's get started.
First you take a piece of paper and you draw the network you want to set up, draw all
the hosts and assign them all a unique IP address in a new network that you are not already
using.
So in my case, I chose 10.10.1.0 slash 24.
That means that my network is 10.10.1 and the last digit is for each systems IP address.
Since both systems are beyond a firewall, this means I cannot access them from the outside
world.
That's my security decision.
This also means I need to have at least one system in my network that is accessible from
the outside world.
For this I chose to instantiate a very cheap cloud virtual machine at some supplier.
This will be my VPN-router-vm system.
So my VPN router system.
And let's call it like that.
All it will do is route all traffic within my 10.10.1.0 slash 24 VPN network.
Of course, it has a public IP address that is visible to the outside world.
Now that I have decided on all the above, I can assign IP addresses to my two systems.
It makes common sense to assign 10.10.1.1 to my VPN-router-vm.
And this also means my other nodes will be 10.10.1.2 and 10.10.1.3.
I instantiate the VPN-router-vm and chose Ubuntu 24 for the US.
I do an update and upgrade to make sure I am using the latest patches.
I install the UFW firewall tool and make it only accessible over SSH from my home server
IP address.
No need for scriptkitties to do dictionary attacks, right?
And I am too lazy to set up fill-to-band because, well, why would I?
If anything ever goes wrong, the VPN has a terminal access in my management console.
So that one works as well.
So I do an app to install UFW, I just do a default deny incoming, a default allow outgoing
and allow from my home IP address to any port 22, 22 proto, TCP and even write a comment
SSH access from home.
Since this VPN-router-vm needs to be accessible from the outside world, the default port for
WireGuard is 4194 and one of my systems does not have a fixed IP address, I need to allow
all WireGuard traffic.
So I say UFW allow 4194 slash UDP, mark to yourself WireGuard does it's traffic over UDP.
Anyway, now all on all our systems we are going to do exactly the same commands to install
WireGuard, make a configuration directory generate a private key and based on this private
key, make a public key, so any system that connects with a public key is checked whether
or not this publicly is based on our hidden private key before it is allowed access.
So I do app install WireGuard, it also makes a directory slash ETC slash WireGuard, if
it doesn't, make one, put the rights to 0700 and you do WG, that's the WireGuard command,
WG, GenKey, Pipe, T, PrivateKey, Pipe, WG, PIPKey, larger than sign, public key, then you
can do a cat of the private key and a cat of the public key, then you have two keys on
one system, so you do this on all your systems.
Now all our systems will get a new network interface with the name WG 0, that's the default
you can also make another interface, but that's the WireGuard default for your first VPN,
so I'm just going with that.
So we need to create a WG 0.com file in every ETC WireGuard directory.
We will start with a skeleton configuration, yeah, he will add stuff to this later and
for good reason, for our VPN router VM system, note that in our interface definition we
just list 24, because we define our VPN network here, so there's a config file that defines
the interface of the private IP address of the VPN router VM, it defines the ported
list zone, list import is equals 4114, it defines the private key, that's a string, and
then you enter your first peer section, and you say public key of that peer is, and you
give the public key of one of your peers, and you say also, next line to the public key
for that peer is allowed IPs, oh, no, I'm wrong, the peer section is, okay, that's my
public key on the VPN router VM, and then I say allowed IPs, 10.10.1.2, list 23, that's
what I do on my first remote note, no, that's not right, that's what I do on my VPN
router VM, yeah, okay, so on my first remote note, I also create a WG0.com file, but
it's slightly different contents, so I define the interface, the private key of that system,
the address that that system should have in the VPN network, a peer definition with
the public key, I set the allowed IPs to 10.10.10.1.0, list 24, and I say the endpoint is the
public IP address of my VPN router VM ported 41194, and I also say all my peer persistent
key per life is 15, so that means that every system that's behind a net firewall will
periodically send out a message to the router VM, look, I'm still alive, just so that you
note. Now, one thing to note in the text above is the last line, since this is a misbeyond
a net firewall, like I just explained, it's not accessible from the outside world, I like
it that way out of security reasons, but it also means that this note has to ping the
VPN server from time to time, okay, all that is left now is to start while I got on the
VPN router VM and on my first peer, so I do a system control enable, we WG-Quick at WG0.
I do a system control start, WG-Quick at WG0, and I do a system control status, WG-Quick
at WG0, and the status then should, well, you know, probably say, okay, I'm active, and
there is a little bit of logging that says, yeah, the connection is up. Now, assuming they
are active and working properly on both systems, you should now be able to ping one another,
yeah, that works, so that's nice. Unfortunately, you're not nearly done yet, sorry. To add a second
system to your router VPN setup, by adding another peer section to the WG0.conf file on the VPN
router VM, and configure the second remote system like you did before, taking care, of course, of the
other's peer-sprivate key. If all goes according to plan, then that service capable of pinging your
VPN router VM, again, we're happy. Now, try to ping one of the remote systems from the other
remote system. I'm guessing it doesn't work. That's a bummer, but can easily be fixed. The thing
is that usually a default Linux system does not automatically do forward of IP packets, so to enable
IP forwarding, you need two commands. You can do a cat of slash proc slash sys slash net slash
IPv4 slash IP underscore forward. I'm basing my network on IPv4 network. Okay, assuming should be
six, of course, by now, but like I said earlier, I'm lazy. System control dash w net dot IPv4 dot IP
underscore forward equals one, and that stores the setting and the startup conf file, and I also do an
echo of one, the larger than, larger than side slash proc slash sys slash net slash IPv4 slash IP
underscore forward. So it also is immediately active on my running system. So can you now ping the
remote system from the other remote system? Yes, you can. Again, we're happy. So surely, you can
now also SSH into our remote system from the other remote systems. And again, bummer, you can't.
Something is prohibiting access to the SSH port from the remote system. What can it be? Well,
the firewall on the VPN route of the M system, of course. So you add a few lines to the wg0.conf
on the VPN, VPN route of M to enable traffic to all ports in the VPN network.
All credits of this to a user DDDMA on Reddit, by the way, I didn't think of this myself.
Your wg0.conf file on the VPN route of M will now look like the following. And you have
extra lines post up equals IP tables, dash A, etc, etc, etc. I'm not going to tell you because
you can't remember it if I'm done. And the same goes for a post down command. So every connection
then it makes a hole in the firewall. And if the connection goes down, it stops it.
So that's basically what it does. I don't forget to do a system control restart wg-quick
at wg0 when you change a config file. Anyway, that's it. You're done. Enjoy. I hope you enjoy this
complete guide to setting up a multiplayer wg0.vpn network. No likes needed. Have a nice day. Bye bye.
You have been listening to Hacker Public Radio at Hacker Public Radio does work. Today's show was
contributed by a HBR listener like yourself. If you ever thought of recording podcasts,
you click on our contribute link to find out how easy it really is. Hosting for HBR has been
kindly provided by an honesthost.com, the internet archive, and our syncs.net. On the Satellite
Stated, today's show is released under Creative Commons Attribution 4.0 International License.