Remote Access Without Port Forwarding

For Those Who Can’t Control Their Router

Before we get started, some assumptions:

  1. Your “Homelab” is already setup (but not necessarily the remote access portion).
  2. You’re comfortable with entering *nix commands.

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” ssh or 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

To get this running, you’ll have to setup your own Virtual Network. Tools I’ve used in the past are AlgoVPN, TincVPN, and ZeroTier.

Before digging into these options, let’s enumerate some desired features:

  1. Automatic provisioning of clients.
  2. Automatic scaling of the Virtual Network2.
  3. Passive interface3.
  4. Programmatically infer network peers.
AlgoVPNTincVPNZeroTier
Automatic Provisioning
Automatic Scaling
Passive Interface
Infer 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 tuntaposx package, 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 *nix devices.

If you run into any hiccups along the way, I recommend consulting the ZeroTier Knowledge Base along with their Community (requires a ZeroTier account).

Arch Wiki TL;DR:

  1. Install ZeroTier One for whatever platforms you need.

  2. 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
    
  3. 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.)

Updating /etc/hosts to Allow for Name-based Lookups

Things you’ll need:

Downloading query-zt-update-hosts.py

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


  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. ↩︎

  2. Provisioning and scaling differ here, deliberately. Some of the services discussed can add new clients, easily, but require the credentials to be manually distributed. ↩︎

  3. 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. ↩︎

  4. As of writing (26 Jul 2020). ↩︎

  5. I actually wrote-up a simple script that can be used. You can find it here. ↩︎

Edit this page

Related