Remote Access Without Port Forwarding
For Those Who Can’t Control Their Router
Before we get started, some assumptions:
- Your “Homelab” is already setup (but not necessarily the remote access portion).
- You’re comfortable with entering
The Problem: You Need Remote Access to Your Homelab
Unless your Homelab is hosted on “in the cloud,” it’s unlikely you already have remote access, at least without doing some “fancy”
vnc tricks. Today we’ll look at how to setup remote access without having administrative access to your network’s router.
This is particularly useful if you live in an apartment or dorms with managed networks that prevent/ban you from remotely access your devices outside of your room. (This was actually my original use case.)
Typically, the suggested approach is to enable Port Forwarding, but I tend to dislike this approach1, so we’ll be discussing another: Mesh Networking.
I explain more about Port Forwarding, here1.
A Solution: Mesh Networks
I prefer this method because it means you don’t need administrative access to your network’s router(s). This route also means you just need an active network connection and everything’s ready to run – whereas Port Forwarding requires configuring your network router (unless you brought your own).
Briefly and informally defining some ideas:
- Mesh Networks Informally, Mesh Networks are networks that maximize connection between devices.
- Virtual Networks Informally, Virtual Networks are akin to LANs (Local [Area] Networks) over the public internet (though Virtual Networks are normally encrypted).
Enumerating Some Options
Before digging into these options, let’s enumerate some desired features:
- Automatic provisioning of clients.
- Automatic scaling of the Virtual Network2.
- Passive interface3.
- Programmatically infer network peers.
- AlgoVPN: is great, but requires an “Active Interface” to facilitate connections, like a traditionally VPN. When active, all of your traffic is routed through the server you’ve setup.
- TincVPN: is a solid Mesh Network, but it’s quite manual and poorly documented. Additionally, MacOS clients can no longer make use of the
tuntaposxpackage, whcnh appears to be unmaintained, anyway.4
- ZeroTier: combines the automation of AlgoVPN and passivity of TincVPN, plus they have a great REST API that enables peer discovery with a bit of programming.5
As a result, let’s focus on using ZeroTier. Once we have ZeroTier setup, I’ll walk you through getting that traffic to tunnel to your Homelab.
To be clear, ZeroTier won’t replace any VPN service(s) you might use. It simply establishes an encrypted peer-to-peer network allowing you to access all your devices (via command-line) easily.
Setting Up ZeroTier
Ensure you’ve installed ZeroTier One on all the devices you want in your Mesh Network. ZeroTier One is available on Windows, Android, iOS, most major Linux distributions and MacOS (I recommend using
brew cask install zerotier-one).
Once installed, I recommend following the Arch Wiki’s Configuration guide to get your ZeroTier Network up and running on all your
Arch Wiki TL;DR:
Install ZeroTier One for whatever platforms you need.
Join your ZeroTier Network by using the 16-digit hexidecimal listed on your network’s page on My ZeroTier. The specific command for this:
# Note: You shouldn't need `sudo` on MacOS $ [sudo] zerotier-cli join <network-id> 200 join OK
Rinse-and-repeat for every device.
Be sure that each of your devices can see each other by running
ping -c2 <ip-addr> on
each, using the
<ip-addr> of each peer. (Keeping My ZeroTier open on the network would
be useful, here.)
/etc/hosts to Allow for Name-based Lookups
Things you’ll need:
- An API Access Token from ZeroTier. You can request one here. Store this token in a safe, preferably encrypted, place.
- A VPS (cloud-base server). I use Vultr because it’s cheap.
If you head over to this GitHub Gist, you’ll be able to download my script that updates your
/etc/hosts with ZeroTier Peers. If you’re on a server and want to download it with
curl, here’s the command:
$ curl -fsSL \ -o query-zt.zip \ https://gist.github.com/ionlights/d5827467ab025b7a2accdf3ab516a3e8/archive/master.zip $ unzip query-zt.zip
You’ll need to run the script with
sudo. If you’d like to see a dry-run of what we’re modifying, feel free to run
./query-zt-update-hosts.py -h to learn how to do that.
You can find a swath of Port Forwarding tutorials online, but it effectively boils down to using your network’s router to open up ports 80/443/etc. and forwarding them to the correct device on your network. So I won’t be covering that here.1
If you prefer Port Forwarding, I strongly advise against using the “DMZ” setting. This tells your router to forward all incoming traffic to your Homelab, which requires you to ensure that it’s hardened against malicious web crawlers, attackers, and the like. ↩︎
Provisioning and scaling differ here, deliberately. Some of the services discussed can add new clients, easily, but require the credentials to be manually distributed. ↩︎
Traditional VPNs funnel all traffic through their network interface. While this is typically desired behavior, we’re not looking for a service to mask our internet traffic but rather, a service that connects devices together. Passive Interfaces allow us to continue using whatever network interface we like, but whenever we address a device on our Virtual Network, traffic is passed through this Passive Interface. ↩︎
As of writing (26 Jul 2020). ↩︎