I've been running a WireGuard setup for a couple of years now, and have been and continue to be very satisfied with it.
- WireGuard server running on my FreeBSD VPS. Always on.
- WireGuard client running on my MacBook Pro M1 laptop (and prior to that, on the MacBook Air that I had before this computer). I activate this one when I need to connect to my server or to some other device on the VPN.
- WireGuard client running on my iPhone X. Like with my laptop, I activate it when I need to connect to the server or to another device on the VPN.
- WireGuard client running on my grandfather's Mac Pro desktop computer. Always on. This allows me to remote into his computer via the macOS-builtin VNC server on his computer, to help him out when he is stuck at something. I use the macOS-builtin VNC client on my MBP or a third-party VNC client on my iPhone. In either case the connection is tunneled over the WireGuard VPN. I also have the builtin SSH server running on his computer that I connect to over WG VPN to transfer files or run commands through.
- WireGuard client running on my desktop computer which runs KDE Neon Linux. Always on.
WireGuard has been almost trivially simple to set up across all of these systems; FreeBSD, macOS, iOS, Linux. And I am sure it is equally simple to set up on many other systems as well.
WireGuard has been very stable and reliable too for all of the time that I have been using it.
Some months ago I changed the WireGuard configuration on my server to run on port 443 UDP instead of the UDP port that WireGuard server would run on by default. This has allowed me to connect to my VPN even when using some public hotspots that were very restrictive on what traffic they allowed through and where previously I could not connect to my WireGuard VPN. Deep packet inspection would still block the traffic I assume, but in all cases with regular public hotspots in my country I have been able to connect to my VPN after I made this change of what port I am using. I live in Norway.
I highly recommend anyone that wants to run their own VPN to use WireGuard.
I personally use my WireGuard VPN for connectivity between these hosts only, not for tunneling traffic that is routed out onto the wider Internet. (That is, my tunnel runs over the Internet but I only use it for traffic that is destined to the machines that are member of the VPN). So I cannot really comment on the use-case of tunneling Internet traffic, but from the experience with connecting the hosts in my VPN I can only assume that tunneling Internet traffic would work out equally well.
I'm renting a couple of VPSes from Vultr that I run FreeBSD on. Very low cost, and decent for my current use which include self-hosting email, hosting a couple of websites that receive little traffic, as well as to host the mentioned VPN, and for testing of some backend services that I am developing.
I hope to afford racks of beefy bare-metal servers one day that can sit in colocation data centers and that I can host backend services for others on. But for the time being I do not have the funds for that so a couple of small VPSes for my own use it is :)
Yes, his computer is on my VPN and has a static IPv4 address inside of the VPN, 10.42.42.4, as well as a static IPv6 address inside of the VPN, fc42:4242:4242:4242::4.
I updated my comment above to note that I use my VPN for connectivity between hosts only, but across the Internet. So I can connect to any host in the VPN from anywhere in the world, but all of the hosts still send all of their other traffic via the same interface that they would if they were not part of the VPN.
So when he browses the Internet, his traffic is routed by his ISP directly and the VPN is not involved, and the same goes for my own computers and other devices.
Can you point me to some docs on how to accomplish this? I'm currently using Slack Nebula to achieve similar goals but every time I looked up WireGuard tutorials, it was to tunnel traffic through a VPS, which I didn't want to do.
wg genkey | tee server.private | wg pubkey > server.public
wg genkey | tee iphone.private | wg pubkey > iphone.public
wg genkey | tee stuegris.private | wg pubkey > stuegris.public
wg genkey | tee nova.private | wg pubkey > nova.public
wg genkey | tee schumberry.private | wg pubkey > schumberry.public
And then I printed the values of each of the files to the terminal simply by cat'ing them to the terminal and copying the values into the respective places. For the server, only the private key is used in the config and the server config likewise contains only the public keys for the clients. For each of the clients, as we will see below, the config contains the private key of the client in question and the public key of the server.
The names "server.private", "server.public", "iphone.private", "iphone.public", "stuegris.private", "stuegris.public", etc are just corresponding to the different hosts and devices. Likewise I have comments in the config file corresponding to which host or device each entry is for.
All of theses files "server.private", "server.public", "iphone.private", "iphone.public", and so on are just temporary. After you've created the config files for the server (above) and the clients (below) you can delete these files.
In /etc/rc.conf on the same FreeBSD server I have added
wireguard_enable="YES"
wireguard_interfaces="wg0"
If your server is running Linux then the setup will be different in terms of how to enable the service. For example if your server is running a disto that uses systemd, then you'd typically create a WireGuard config similar to mine but place it at /etc/wireguard/wg0.conf and then you'd run
sudo systemctl enable --now wg-quick@wg0
On each of the clients I have corresponding configurations.
Here is what the configuration of WireGuard client for my MacBook Pro M1 looks like:
And I do similarily for the other client hosts and devices.
Obviously I've replaced all of the PrivateKey and PublicKey values with other values here. Other than that this is exactly how the setup is like.
Likewise, where it says "wg.example.com:443" you put the actual DNS name and UDP port (still UDP port 443 if you follow my setup) of the host that runs WireGuard server. Alternatively you could put an IP address instead of a DNS name. But in either case it needs to resolve to a static IP address, and the UDP port needs to be open to incoming traffic from the internet. In many cases you can open ports in your router if you want to host the server on your home computer. But I found it simpler to run my WireGuard server on a VPS for several reasons; VPS can be rebooted remotely, IP address is static, and also I don't need to make any changes to my setup even when moving houses and changing ISP because the server is not running from my home but from a VPS provider.
On my MacBook Pro M1 I am using Wireguard with GUI, which has a tray icon. Installed via App Store.
On my grandfather's desktop I am using Wireguard installed via Homebrew with no GUI, and with a custom launchd config file to have it connect and run always and as soon as the computer is booted. I will omit this file for brevity and clarity but can post the contents of that file as well if you would like me to do so.
On iOS I am using the WireGuard app installed via App Store.
On KDE Neon Linux I am using wireguard installed via apt from the default repositories of KDE Neon Linux.
In the above text I have omitted parts of the setup. Let me know if the details that I have included above are sufficient or if you would like to see a full writeup about the whole thing from start to finish. Note however that I do not have time to make a fully detailed writeup about it at present time so in that case it will need to be something that I write at a later point.
- WireGuard server running on my FreeBSD VPS. Always on.
- WireGuard client running on my MacBook Pro M1 laptop (and prior to that, on the MacBook Air that I had before this computer). I activate this one when I need to connect to my server or to some other device on the VPN.
- WireGuard client running on my iPhone X. Like with my laptop, I activate it when I need to connect to the server or to another device on the VPN.
- WireGuard client running on my grandfather's Mac Pro desktop computer. Always on. This allows me to remote into his computer via the macOS-builtin VNC server on his computer, to help him out when he is stuck at something. I use the macOS-builtin VNC client on my MBP or a third-party VNC client on my iPhone. In either case the connection is tunneled over the WireGuard VPN. I also have the builtin SSH server running on his computer that I connect to over WG VPN to transfer files or run commands through.
- WireGuard client running on my desktop computer which runs KDE Neon Linux. Always on.
WireGuard has been almost trivially simple to set up across all of these systems; FreeBSD, macOS, iOS, Linux. And I am sure it is equally simple to set up on many other systems as well.
WireGuard has been very stable and reliable too for all of the time that I have been using it.
Some months ago I changed the WireGuard configuration on my server to run on port 443 UDP instead of the UDP port that WireGuard server would run on by default. This has allowed me to connect to my VPN even when using some public hotspots that were very restrictive on what traffic they allowed through and where previously I could not connect to my WireGuard VPN. Deep packet inspection would still block the traffic I assume, but in all cases with regular public hotspots in my country I have been able to connect to my VPN after I made this change of what port I am using. I live in Norway.
I highly recommend anyone that wants to run their own VPN to use WireGuard.
I personally use my WireGuard VPN for connectivity between these hosts only, not for tunneling traffic that is routed out onto the wider Internet. (That is, my tunnel runs over the Internet but I only use it for traffic that is destined to the machines that are member of the VPN). So I cannot really comment on the use-case of tunneling Internet traffic, but from the experience with connecting the hosts in my VPN I can only assume that tunneling Internet traffic would work out equally well.