See if you can relate to any of these scenarios:
- You have been using Microbit RRC Remote Rigs for years. All of a sudden, networking stops working. You are pulling your hair out. Your Internet Service Provider has made a change which prevents your remote from operating.
- You just bought a very expensive rig (such as the Elecraft K4 with a K4/0 remote) and you cannot make the remote connection work.
- You have Kenwood or Yaesu remote software, and you cannot get your station to communicate with a remote endpoint.
- You are trying to implement RemoteHams/RCForb, but it just will not work in your scenario.
- You give up on remote operation entirely because you only have 4G LTE/5G cellular service, or you are on a non-commercial Starlink plan.
What Is Going On?
Your internet provider has implemented their network differently than you expect. For many large ISPs, they have switched to, or have always used, a technology called CGNAT: Carrier Grade NAT. This lets them expand services dramatically. It allows you as a customer to do everything you normally want to do on the internet, with one crucial exception: you cannot host software that is classified as a server.
Why? Servers require a public IPv4 address. Your IPv4 address is your unique address on the internet, similar to your house number on a street. “Public” means any other computer or device on the internet can see and reach it. With CGNAT, you have an outbound IPv4 address, but your inbound IPv4 address is not visible to the world. None of your favorite remote technologies will work, because every one of them requires the remote end to be able to reach your station directly.
Starlink and every cellular provider use CGNAT. It is the only way they can serve so many customers. IPv4 has a limited pool of addresses. IPv6 solves that (there are more IPv6 addresses than stars in the observable universe), and CGNAT technology uses IPv6 internally, translating it to IPv4 at the edge for your devices. Great for the ISP. Not so great for remote operators.
Some ISPs go even further and simply block any incoming IPv4 server traffic on their network as a policy matter.
The VPN Route — and Why It Is a Pain
Maybe you have already tried VPN solutions, setting up individual VPN connections between your station and each remote operator. Getting that working, keeping it working, and explaining it to every guest operator is a headache. What if a remote operator could connect from anywhere in the world with absolutely no VPN software on their end at all?
I am not after your lunch money. I am going to show you how to forget all of the above problems and have a reliable, rock-solid way of exposing your station to the internet which is compatible with any of the technologies above, working with any internet provider, requiring nothing special on the remote operator’s end. I have been running a two-station K3 remote setup this way for over a year. It has been totally rock solid.
No degree in software engineering required. No Linux expertise required. I will walk you through every step.
Why $11?
More precisely, it is about $10.60 per year, for a Linux Virtual Private Server (VPS) that lives at a data center on the internet.
Head over to RackNerd’s Black Friday page. Despite the name, this page is open all year and the deals are live right now. You are looking for the 1 GB RAM KVM VPS. At the time of writing it is $10.60 per year. That is not a monthly price. That is the annual price. It comes with 1 CPU core, 15 GB of SSD storage. Here is the part that matters for our use case: 2 TB of monthly traffic transfer. Even a busy multi-radio remote station will not put a dent in that. Pick a location that is close to either your station or your remote ops. It should be work well either way.
When you order, select Ubuntu 22.04 LTS or Ubuntu 24.04 LTS as the operating system. Either works. Within minutes of completing checkout, RackNerd will email you the VPS IP address, root password, and SSH port.
The key thing the VPS gives you is a fixed, permanent, public IPv4 address. That is the missing piece.
The Architecture
Here is what we are building:
Remote Operator
(anywhere on internet)
|
| connects to VPS public IP on a specific port
v
┌─────────────────────────────┐
│ RackNerd VPS │
│ - Public IPv4 address │
│ - UFW firewall │
│ - nftables port forwarding │
│ - Tailscale node │
└──────────┬──────────────────┘
│ Tailscale VPN tunnel
v
┌──────────────────────────────────┐
│ Station PC (Windows or Pi) │
│ - Tailscale installed │
│ - Advertising local LAN subnet │
└──────┬───────────────────────────┘
│ local LAN
v
Your station devices:
RemoteRig boxes, K4/0, SCU-LAN10,
RemoteHam server, etc.
The VPS sits on the public internet with a real IPv4 address. Tailscale creates a private, encrypted tunnel between the VPS and a PC at your station. That station PC advertises your local LAN over Tailscale, so the VPS can see all your station devices as if it were physically on your local network. Then, the VPS uses port forwarding to take any connection arriving on a public port and route it through the Tailscale tunnel to the correct device and port on your station LAN.
The remote operator simply connects to your VPS IP address. No VPN. No special software beyond whatever they already use to operate the radio remotely.
What You Need
- A RackNerd VPS running Ubuntu 22.04 or 24.04 ($10.60/year via the link above)
- A free Tailscale account at tailscale.com — free forever for personal/small group use
- Tailscale installed on a PC at your station (Windows or Raspberry Pi; I will cover Windows here)
- The build-remote.sh script (provided below)
- Basic comfort copying and pasting commands into a terminal
- Bitvise SSH Client (free for personal use) — your remote control tool for the VPS
- Optionally, a domain name and free DNS hosting (details in the next section)
Optional but Recommended: A Domain Name and Free DNS
Your VPS has a fixed public IP address. You could stop there and just tell people “connect to 198.51.100.42 on port 8080” and it will work fine forever. But a hostname is nicer to share, easier to remember, and means you could move to a different VPS someday without updating everyone’s software configuration.
Free DNS Hosting: dns.he.net
Hurricane Electric’s free DNS service (dns.he.net) is what I use and recommend. It is completely free with no catches, has been rock-solid for years, supports all the record types you will ever need, and has a simple web interface. Create a free account, add your domain (or even just a hostname under an HE-provided zone), point an A record at your VPS IP, and you are done. Changes propagate in minutes.
If you already have DNS hosted elsewhere (Cloudflare, your registrar, wherever), you can skip HE and just add an A record there instead. The key is simply: A record pointing your chosen hostname to your VPS IP address.
Getting a Domain Name
If you do not already own a domain, here are three registrars worth considering:
Porkbun is my current favorite for price. Many TLDs are very cheap, and their interface is clean. A .com is typically around $9-10 per year.
Namecheap has been around forever, is reliable, and frequently runs first-year promotions. Good if you want to consolidate management of multiple domains.
Cloudflare Registrar sells domains at true wholesale cost with no markup. They also offer free DNS hosting with fast propagation, so if you register here you may not even need HE. The only catch is they do not support every TLD.
You do not need anything exotic. A .com, .net, .org, or .radio domain all work perfectly. Pick something short and logical — something like w1xyz-remote.com or k3abc-station.net — and it will serve you well. If buying a domain feels like overkill, just use the IP address. The technical setup is identical either way.
Once you have your hostname set up, you can use it everywhere the instructions below say “your VPS IP address.” Your remote operators will thank you.
Getting Connected: SSH and Bitvise
Before we touch the VPS, you need to understand SSH and get the right tool for it. This section is not optional: every interaction with your VPS happens through SSH.
What Is SSH?
SSH stands for Secure Shell. It is the standard way to remotely control a Linux computer over the internet. When you SSH into your VPS, a terminal window opens on your screen, and everything you type is sent over an encrypted connection to the Linux machine in the data center. It looks like a black screen with a text prompt. That is the Linux command line, and it is all you need. The VPS has no monitor, no keyboard, no mouse. SSH is your only door in.
Think of it like a really secure, encrypted Telnet if you remember that from the BBS days. Except SSH is safe to use over the public internet.
Get Bitvise SSH Client
There are several SSH clients for Windows. PuTTY is the one everyone mentions, but I recommend Bitvise SSH Client instead. It is free for personal use, well-maintained, easy to set up, and far more capable. Notably, it includes a built-in graphical file transfer window (SFTP), so if you ever need to copy a file to or from the VPS, you can do it by dragging and dropping rather than typing commands.
Download it at bitvise.com/ssh-client. Install it like any other Windows application.
Setting Up Your First Connection
When you open Bitvise, you will see a login window. Fill it in as follows, using the details from the email RackNerd sent you after purchase:
Host: Your VPS IP address (or your hostname if you have already set up DNS)
Port: Check your RackNerd welcome email carefully. RackNerd sometimes uses port 22 (the SSH default) and sometimes assigns a non-standard port like 21098 or similar. The email will say. Use whatever it says.
Username: root
Initial method: Select password from the dropdown
Password: The root password from your RackNerd welcome email
Click Log in. The first time you connect, Bitvise will show a warning that it does not recognize this server’s host key, and ask if you want to accept and save it. This is normal and expected for a brand-new server — click Accept and Save. It will not ask again.
A black terminal window will open with a prompt that looks something like this:
root@vps-hostname:~#
You are in. You are now typing commands that run on the Linux machine in the data center. This is where you will do all the VPS-side work in the steps below.
Save your connection profile: Before doing anything else, go back to the Bitvise login window and click Save profile near the top. Give it a name like “RackNerd Remote VPS.” Next time you need to get in, just open Bitvise, load the profile, and click Log in. You will not need to type the IP address or credentials again.
Step 1: Set Up Tailscale at the Station
Download and install Tailscale for Windows from tailscale.com/download. Sign in with your Tailscale account. After it connects, you will see a Tailscale icon in your system tray showing your VPN IP address (something like 100.x.x.x).
Now the important part: you need to tell Tailscale to advertise your local LAN so that the VPS can reach your station devices. Open a Command Prompt as Administrator and run:
tailscale up --advertise-routes=192.168.1.0/24 --accept-routes
Replace 192.168.1.0/24 with your actual local network subnet. If you are not sure what yours is, open Command Prompt and type ipconfig — look for the “Default Gateway” under your active network adapter. Your subnet is likely 192.168.1.0/24 or 192.168.0.0/24.
After running that command, log into the Tailscale admin console at login.tailscale.com/admin, find your station PC in the machines list, click the three-dot menu, and select “Edit route settings.” Approve the subnet route you just advertised. This is a one-time step.
Step 2: Set Up the VPS
Open Bitvise, load your saved profile, and log in. You should be at the root@vps-hostname:~# prompt in the terminal window.
Once you are logged in, download the setup script and make it executable: (Note: bash is just the type of terminal you are in; you don’t type that.)
bash
wget http://remote.radio/build-remote.sh
chmod +x build-remote.shwget fetches the file from the internet and saves it to the current directory. chmod +x marks it as executable so Linux will allow it to run. Now launch it:
bash
sudo bash build-remote.sh
(Or you can paste the script contents directly into a file using nano build-remote.sh.)
Step 3: Run the Script
The script walks you through everything interactively. Here is what it does and what it will ask you:
First, it installs the required software — nftables (for port forwarding), UFW (the firewall), and Tailscale. You do not need to install anything manually.
Next, it authenticates Tailscale on the VPS. You will be given a choice:
- Option 1: Paste a Tailscale auth key (get one from the Tailscale admin console under Settings > Keys). This is the smoothest option.
- Option 2: Browser login. The script prints a URL; you open it on any device and log in.
After authentication, your VPS will appear in your Tailscale admin console alongside your station PC. Both devices are now on your private Tailscale network.
Then it asks for your far-LAN subnet. This is the same subnet you advertised from your station PC in Step 1 — for example, 192.168.1.0/24.
Finally, it collects your port forwards. For each device on your station LAN that you want to expose, you provide:
- The public port on the VPS that remote operators will connect to
- The destination IP of the device on your station LAN (e.g.,
192.168.1.20for a RemoteRig box) - The destination port on that device (often the same as the public port)
- The protocol — TCP, UDP, or both
For example, if your RemoteRig RRC-1258 web interface listens on port 8080 at IP 192.168.1.20, you would enter:
Public port: 8080
Destination IP: 192.168.1.20
Destination port: 8080
Protocol: tcp
You can add as many port forwards as you like. When you are done, the script:
- Opens the ports in the UFW firewall
- Configures nftables NAT rules to do the actual forwarding through the Tailscale tunnel
- Installs a systemd service that re-applies all the rules automatically every time the VPS reboots
Everything persists across reboots. You set it once and it keeps running.
At the end, the script prints a summary showing your VPS public IP, your Tailscale IP, and all your configured port forwards.
Step 4: Test It
From a completely different network (your phone on cellular is perfect for this), try connecting to your station using your normal remote software, but point it at your VPS public IP address and the port you configured, instead of your home IP address.
If your RemoteRig web interface came up at 192.168.1.20:8080 on your home LAN, it will now come up at YOUR.VPS.IP:8080 from anywhere in the world.
Adding or Changing Port Forwards Later
If you need to expose a new device, just open Bitvise, log back into the VPS, and run the script again:
sudo bash build-remote.sh
It detects your existing configuration and gives you three options: keep and re-apply, wipe and start over, or add new forwards to the existing set. Pick “add” and it will prompt you for the new device. Simple.
What the Remote Operator Needs
Nothing special. Whatever software they already use for remote operation — a RemoteRig client, Kenwood/Yaesu remote software, the K4 remote app, RCForb, whatever — just points to your VPS IP address instead of a home IP. No VPN client. No special configuration on their end.
Closing Thoughts
This setup has fundamentally changed how I think about remote operation. I no longer worry about what ISP is at my station. I no longer worry about whether my dynamic IP changed. I no longer explain VPN clients to guest operators. The VPS is always there, always reachable, always forwarding.
For $10.60 a year. Cheaper than a new coax connector.
If you get stuck at any step, feel free to reach out. 73 DE W1VE (or 7Q2T or ZF2VE, if you prefer :-)).
Next in this series: Configuring Tailscale subnet routing on a Raspberry Pi — for those who want a completely headless station setup with no Windows PC required.
