Sep 8, 202114 min read

How to: mining Helium over a cellular connection

An in-depth, step-by-step guide to setting up your Helium miner with a mobile data hotspot

Why cellular over at-home wifi?

With the surge of new hotspots on the Helium network, many folks are getting creative about how they deploy their miners in order to get the most bang for their buck. Creating setups that allow their miners to be placed anywhere without having to connect to an outlet or an at-home internet connection opens up a lot of new earning possibilities. While there are quite a few resources and even online retailers that will help you get set up with outdoor enclosures and solar power for your miners, it’s difficult to come by quality info on how to set up Helium miners over a cellular connection. This article is meant to fill that hole.

Most of the outdoor miner setups that you see in the #enclosures-and-offgrid channel in the Helium Discord make use of cellular data hotspots in order to connect their Helium miner to the internet. As you probably already know if you’ve been through setting up a Helium miner on your home network, getting your miner to communicate effectively with the internet can be a pain. Unfortunately, it can be especially challenging on mobile carrier networks.

A quick networking background

(Feel free to skip ahead to “🖥 The Guide: deploying a VPS for your mobile hotspot” if you’re familiar with NATs and GCNATs already…)

Photo by Omar Flores on Unsplash

You’ve probably heard the word NAT thrown around. It stands for Network Address Translator. For a typical at-home setup, your router plays this “translator” role. It’s main job as a “translator” is to take requests to it’s “public” IP address (assigned by your internet service provider), and forward them along to local IP addresses that it automatically assigns to your home devices (192.168.1.*):

When you “open ports” or “port forward” to your Helium miner, you are giving your router instructions to “forward” requests over port 44158 to a device’s private IP (192.168.1.4 for the miner in this case):

Your router will also occasionally change the local IP addresses it assigns to individual devices, which can make any port forwarding rules outdated and non-functional. However, it is usually possible to tell your router to never change the assigned IP of a device on your network (ie to give it a static DHCP lease). It’s important to do this when port forwarding, otherwise the forwarding rules you create will not apply to the new IP address that your router gives the device that you meant to port forward to. Having the ability to tell your router to give devices static IPs on your home network is a luxury we unfortunately don’t get when using cellular hotspots. This is due to how mobile carriers set up their own version of your home NAT called a CGNAT.

CGNAT vs. regular ol’ NAT’s

Carriers use what is called a CGNAT (Carrier-grade Network Address Translator) to manage the massive number of devices connected to their network simultaneously. Though this is likely a huge simplification, it’s basically like a NAT, but a CGNAT forwards requests made to it to multiple users’ devices on the entire network, as opposed to local devices in your home.

Why are Hotspots harder on cellular carrier networks? If you were to try to “port forward” from a CGNAT’s IP address, there would be no way for the carrier to know which specific user/device combination to send the request it received on. This is because they all belong to different users, and are constantly being reassigned IPs by the CGNAT:

With no public static IP for your cellular hotspot, it’s impossible for the CGNAT to map all requests to on port 44158 to just your device’s IP out of everyone else’s hotspot and home IPs on the network. Then all those other people on the carriers CGNAT wouldn’t be able to forward 44158 to their devices as well!

So what do now??

At this point, you have two options in order to allow you to do proper port forwarding to your Helium miner while using a cellular hotspot:

Get a static public IP address from your carrier for your SIM card. With a lot of handwaving, this basically means your carrier gives your hotspot a public IP address that wont change. Unfortunately, most carriers in the U.S. will only give you a static IP address if you sign up for a business plan with them (which of course, requires that you already own a business). Having a static IP would allow you to simply set up port forwarding in your cellular hotspot and call it a day.
Set up a VPS (Virtual Private Server) with a static public IP, and configure it to forward traffic to your cellular router.

NOTE: you may be one of the lucky few that actually does have a Static IP address without having to purchase one, since some carriers out there (probably not in the U.S.) still do not put their connected devices behind a CGNAT. Before going any further, you can check if you’re SIM’s IP address is behind a CGNAT or not by visiting this link and typing in your IP address (you can find out your IP here). If it says “IPv4 address block not managed by the RIPE NCC,” then you don’t have a static public IP. Thanks to molano#4878 in the Helium Discord for this tip!

Option 1 was just not feasible for me, since I didn’t own a business and didn’t really want to go through the hassle of setting one up for the few outdoor miners I’d be deploying.

Since Option 1 is relatively simple technically speaking, this article is going to discuss in detail how to setup Option 2.

The Guide: deploying a VPS for your mobile hotspot

Photo by Florian Krumm on Unsplash

At a high level there are three main steps to this guide, with a few details in between:

Deploy a server to the cloud (VPS)
Setup a VPN on that server
Configure you’re cellular hotspot / router to work with said VPN

Before we get started, you’re going to need a few things…

Prerequisites

To do this setup, you will need:

Around $5 a month to spend on hosting a VPS
An account with a PaaS like DigitalOcean or Linode to deploy the server you will install the VPS on (don’t worry, it’s not as scary as it sounds). In this example I will use Linode. If you use this referral link for Linode, you will get $100 free credit, which is almost worth two years of free VPN hosting
A cellular router that is compatible with the open source WireGuard VPN. In this example, I used Teltonika’s Rut240 3g/4g Router, which is available on Amazon. There are other routers in the more affordable price range (~$70–$120) that work with WireGuard like the Cudy LT400 or Cudy AC1200 (thanks to Raúl Sal for this tip). I haven’t specifically tested this setup, but it seems reasonable that it would work just as well with the same VPS I walk through here.
A little bit of experience with SSH and working in the terminal (I’ll try to guide you through this even if you haven’t used SSH before)

️

Step 1: Setting up a Virtual Private Server

With your newly created Linode account, we’re going to deploy a Debian 11 server.

From the Linode dashboard:

1. Select “Create” > “Linode”

2. Fill out your server details. I chose Debian 11, deployed in the Newark, NJ region (since I live in NYC, it was the closest one), and selected “Nanode 1GB,” the lowest tier option for $5/month.

3. Add an SSH key so that you can remotely access your server.

If you don’t already have an SSH key on your computer, you can follow this guide to generate one. You can check if you already have an SSH key generated on your computer by running

cat ~/.ssh/id_rsa.pub | pbcopy

If you don’t get an error like this after running that:

/.ssh/id_rsa.pub No such file or directory

You will have the contents of your key copied into your clipboard, ready to be entered into Linode. If you had to manually generate a key using the link above, copy the contents of the id_rsa.pub file you generate into the “SSH Public Key” field, give it a label, and hit “Add Key.”

4. Hit “Deploy node”

5. Get excited! Also maybe grab a coffee while your server deploys (should take less than 5 minutes)

Step 2: Install WireGuard on your newly deployed server

This is probably the more complicated bit of the guide, so strap in (don’t worry, I’ve got you covered) Once your Linode’s status says “Running”, you’re ready to SSH into the server to install WireGuard

Click on your Linode’s label to be taken to its details page. Under “Access”, Click on the clipboard next to the “SSH Access” line:

Open a terminal on your computer (I’m on a mac and prefer to use iTerm2), and paste the command you copied. It should look something like

ssh root@<ip address of your linode server>

If all goes well, you should see the following prompt

Linux localhost 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Aug 21 20:00:37 2021 from 107.107.57.230
root@localhost:~#

If this didn’t work try running ssh-add ~/.ssh/id_rsa from your computers terminal. If that didn’t work, double check your steps from generating a new key!

Great, you’re inside your newly deployed server. If this didn’t work, it’s likely that you did not configure your SSH key correctly (did you make sure to copy/paste the public and not the private one into Linode’s set up page?).

Now, time to install WireGuard. You will run the following set of commands:

root@localhost:~# apt update
root@localhost:~# apt upgrade
root@localhost:~# apt install iptables
root@localhost:~# apt install wireguard

Hit “y” to. continue.

Now that WireGuard is installed, we need to set up a private/public key pair for the WireGuard VPN to use.

root@localhost:~# cd /etc/wireguard/
root@localhost:~# wg genkey | tee privatekey | wg pubkey > publickey

This last command will generate two files, privatekey and publickey. Inspect their contents with this value.

root@localhost:~# cat privatekey
<some long string of numbers and letters>
root@localhost:~# cat publickey
<some long string of numbers and letters>

Copy these values somewhere to use for later (but don’t leave either around after you’re done with em’). You will need to paste one of them into the configuration file for Wireguard in the next step.

Time to setup the config for Wireguard. You will need to open/edit a file, so basic familiarity with an editor like vim or nano will help you…

root@localhost:~# vim /etc/wireguard/wg0.conf

This will open a file editor view for the Wireguard config file. If there’s anything there, delete it and paste in the following:

[Interface]
ListenPort = 51820
PrivateKey = <REPLACEME with contents of privatekey>
Address = 10.0.1.1/24
MTU = 1420

PostUp = iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1240
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = iptables -A FORWARD -i eth0 -o wg0 -p tcp --syn --dport 44158 -m conntrack --ctstate NEW -j ACCEPT
PostUp = iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
PostUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 44158 -j DNAT --to-destination 10.0.1.2

PostDown = iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1240
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i eth0 -o wg0 -p tcp --syn --dport 44158 -m conntrack --ctstate NEW -j ACCEPT
PostDown = iptables -D FORWARD -i eth0 -o wg0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 44158 -j DNAT --to-destination 10.0.1.2

[Peer]
PublicKey = <REPLACEME later with public key generated for the cell router>
AllowedIPs = 10.0.1.2/32
Endpoint = 0.0.0.0:51820

Copy the above text, and replace the content within <> brackets on the line with PrivateKey = <REPLACEME…> with the contents of the privatekey file you copied previously. Don’t worry about the other PublicKey line at the bottom for now…

To break down this file a bit:

The first part of the file under [Interface] is specifying network config for the Wireguard server itself.
The lines after that starting with PostUp specify instructions for Wireguard after the server starts up. iptablesis a complicated tool that can do a lot of different things, but in this case, we are using it to map the port 44158 to an IP address 10.0.1.2 , which will be the IP that were going to have our Wireguard VPN give to our cellular router. This is similar to how you would configure your at-home router to port forward 44158 to your helium hotspot’s IP, were just doing it for the VPN instead!
Under [Peer], we specify details for a "peer" to the VPN, which in this case is our mobile hotspot. (In Wireguard, all connected devices are considered peers, as opposed to it being a typical VPN server/client relationship — ie the hotspot is a peer to the VPS, and the VPS is a peer to the hotspot)

To save the changes to the config file you were editing (/etc/wireguard/wg0.conf ), type :wq. You should now be back in the terminal on your VPS if all went well.

Generate a key pair for the rut240 router

We’re going to need to generate one more public/private key pair for the one peer that this VPN will have (your mobile hotspot). You will use the same command as before, but will different file names

root@localhost:~# wg genkey | tee hotspot-privatekey | wg pubkey > hotspot-publickey
root@localhost:~# cat hotspot-privatekey
<some long string of numbers and letters>
root@localhost:~# cat hotspot-publickey
<some long string of numbers and letters>

Again, take note and copy the values of these private/public keys somewhere that you’ll be able to reference them later. You will need to copy the value of hotspot-publickey and add it to your Wireguard config under the [Peer] section.

root@localhost:~# vim /etc/wireguard/wg0.conf

Which should open your config file again (abbreviated for space)

[Interface]
ListenPort = 51820

...[Peer]
PublicKey = <REPLACEME with contents of hotspot-publickey>
AllowedIPs = 10.0.1.2/32
Endpoint = 0.0.0.0:51820

Once you’ve added the public key we generated for your mobile hotspot, you’ve finished dealing with this file! Go ahead and save it (:wq, you remembered right?)

Now, we need to add one configuration option to another file. You can do that with a quick one liner from the terminal:

root@localhost:~# echo net.ipv4.ip_forward=1 >> /etc/sysctl.conf

This line enables port forwarding on your VPS. Now run the following to persist the configuration change:

root@localhost:~# sysctl -p

Just a few more steps now… But first, SELF CARE. Come traveler, take a breather 😌

Check out this adorable birb. Grab a snack. Whisper some reassuring sweet nothings to yourself in the mirror. Ok… now you’re ready…

*Cracks knuckles, stretches fingers* here we go.

Let’s enable Wireguard to run whenever the server boots up:

root@localhost:~# systemctl enable wg-quick@wg0

And now, we can finally start the Wireguard server up!

root@localhost:~# systemctl start wg-quick@wg0

Now, if you run

root@localhost:~# systemctl status wg-quick@wg0.service

You should see something like this (note the active status):

And with that, you’ve finished setting up your VPS! (for now — you might have to come back here in a bit to do one or two more things, so maybe leave this terminal window open for now)

Step 3: Configure your mobile hotspot router

As a reminder, in this walkthrough, we’re using a Rut240 router. I’m not 100% certain how to configure other mobile routers as WireGuard clients, but I’m sure many routers have this option! The hardest part is definitely setting up the VPS itself…

So first, insert the SIM card you got from your carrier into the back of the rut240. Make sure you also installed all the necessary antennas it came with before powering on!

Ok, plug it in. Now, after a minute or so, it should show up in your computer’s Wifi list.

Connect to it.

Login to the router’s admin tools by visiting 192.168.1.1 in a browser (you will probably not be able to use Chrome to do this. I used Safari.

Once you get past all of Safari’s warnings and hit “Continue anyway”, you will be prompted with a login screen.

Use the default admin credentials that should be on a manual somewhere in your rut240 box. It will prompt you to change credentials after logging in for the first time, so do that.

Ok cool, you’re logged in. First things first: update the firmware (to do this, you will need to have a SIM inserted, as it uses internet, and getting the rut240 setup on my wifi turned out to be a dead end. Maybe you’ll be more lucky than I was. In any case, the firmware update isn’t that large)

If there is a pending update, click upgrade! Your router will likely reboot and disconnect you from 192.168.1.1. if this happens, just reconnect to it’s wifi once it’s back up and refresh the page.

Once you’re logged back in to the router again, you will need to install the WireGuard package firmware under “System > Package Manager”

Search for “Wireguard” in the search box, and install it!

Once Wireguard is installed, go to “Services > VPN > WireGuard”

Type a name for your Wireguard configuration and hit “Add” — I called mine wg_linode, but you can name it whatever. It will be un-enabled for you, since you have yet to configure it.

It should look something like this. Go ahead and click “Edit”. You will be taken to a page where you’ll need to enter some details about the Wireguard VPN we configured in Step 2. Specifically:

toggle Enable checkbox on
For the Private key input, enter the contents of the hotspot-privatekey file you generated and copied in Step 2. You… did copy it somewhere right?
For listen port: 51820
For IP address: 10.0.1.2/32
For MTU: 1420

Now, you will need to add the Wireguard server is a peer to the cell hotspot. Under the “Peers” section, click “Add”. Now click “Edit” on the row that was added.

Fill out the details exactly like the screenshot above except for public key and endpoint host. The public key you enter here will be the verrry first public key you generated in Step 1. It is Wireguard’s public key. If you forgot to copy it, you can find it in the SSH session you left open on your VPS. The file should be called publickey

Endpoint host is going to be the IP address of the Linode server you deployed. You can find this from the Linode dashboard:

Hit Save in the router’s VPN config page.

Now go to “Network > LAN”

Under “Static Leases” section, hit “Add” and then type in the following:

Hostname: anything you want. I called mine sensecapM1 since that’s what I have

MAC Address: The ETH MAC address of your hotspot.

IP Address: Select “custom” from the drop down and type in 192.168.1.10

Now, go to “Network > Firewall > Port forwarding”

Add a “New Port Forward Rule” at the bottom, with the following details Name: Helium Protocol: TCP External port (s): 44158 Internal IP: Select “custom” from the drop down and type in 192.168.1.10 Internal port (s): 44158

Hit “Add” and then hit “Save” at the bottom right. Your new rule should look like this in the port forwarding rules table above:

Now, click “Edit” on the rule.

For the “Source zone” section, select the “wireguard” option. Hit “Save” in the bottom right.

Now…take a deep breath… because you just finished setting up your rut240!!

Validating that it all works

So, in order to make sure that your VPS is properly forwarding traffic across 44158 to your cellular router and then to your Helium miner, go ahead and plug your miner into the rut240's ethernet port (make sure you plug it into the LAN port and not the WAN port). Give your miner a minute or two to boot up.

Once you’ve done this, go to this port checking tool and enter 44158 into the port number field. Hit “Check”.

At this point, it should say that this port is open and you should be getting inbound and outbound requests to your helium miner. Woohoo!

If for whatever reason the port is still closed, try double checking your port forwarding settings on the Rut240. Also, here’s a helpful command that you can run while SSH’ed into your VPS:

tcpdump -i wg0 -n

In order to run this, you may need to install tcpdump however:

apt install tcpdump

This will monitor all traffic coming and going through the WireGuard network interface on your VPS.

You can keep this running in the terminal while fiddling with Rut240 settings as a way to validate that things are working.

Don’t forget to clean up the public/private key pairs you generated on the server.

Extra credit: An awesome way to monitor your device remotely

So, if like many of us trying to deploy their hotspots on a cellular network you don’t want have to physically run out to your deployed miner every time you need to update settings on your router… that’s possible with this setup! You shouldn’t have to do fiddle with router settings too often, but if you do, I have a solution for you:

First, if you’re connected directly to your rut240 from your computer, make sure to connect back to your home’s wifi.

Now, in a terminal on your computer, run the following:

ssh root@45.33.88.48 -L 0.0.0.0:8081:10.0.1.2:80

This command forwards requests from your local machine’s browser to your deployed VPS and finally to the rut240’s admin tools.

While leaving this command running in the terminal, open up a browser and visit localhost:8081 . If all goes well, you will see the login page for your cellular hotspot’s admin tools. Now you can manage your deployed router from the comfort of your home!

Wrapping up

If you made it this far, congratulations. You did it, friend. If you didn’t quite make it to the end because you hit unexpected turbulence on the way here, don’t worry! You can find me on the Helium discord as switz#1985 . Also, I highly advise re-reading these instructions and checking that you input all the values in your router and in the VPS correctly, typos can be the biggest enemy with these kinds of things!

Acknowledgements

I couldn’t have done this without the patience, kindness and experience of rbrtio#1507 on the Helium discord. Also want to shout out all the extremely helpful folks in the #enclosures-and-offgrid Helium discord channel. Also big kudos to Mo#3110 for being the first one to battle test this guide, and for finding (and dealing with) my fat fingered typos!

Source: Medium - Oliver Switzer

The Tech Platform