Or How To Use Starlink or Mobile Hotspot For Remote Internet Access
Both the Starlink and the AT&T Mobile Hotspot have firewalls that prevent traffic from coming in from the outside world. There are two terms for this, “Double Natting” and “Carrier Grade Natting”. The end effect is there is no public i.p. that can be accessed from the outside. Port forwarding won’t work because with no public address there is no way to reach the router. (On the server end port forwarding is needed, however. ). Not to fret. There are two solutions. One is Chrome Remote Desktop (or similar remote desktop service but not Windows remote desktop). The other is Reverse SSH Tunneling. They both work the same way.
First lets define some terms. The local computer is the one on the user end and the remote computer is located at the far end behind the firewall. The username on the local computer is “email@example.com”.
The first and simplest solution is to run Google Chrome Remote Desktop on both computers. The remote computer can be reached even through a firewall because of an easy secret. The secret is, Chrome Desktop on the remote computer opens a connection automatically to another server somewhere in the outside world. All the user at the local computer has to do is connect to that same server which in turn bridges the connections. The nice part is, Chrome Remote Desktop does all that automatically with no intervention or set up needed by the user. It’s amazingly easy to use and more importantly, it bypasses the firewall. Add the Chrome Remote Desktop extension to the Chrome Browser on each computer.
A second much more elegant solution has been around for over 20 years and does not require Google. It is called Reverse SSH Tunnel and is much easier to use than it is to explain or understand. Even the figure above is way too confusing. The concept is identical to Chrome Desktop. A remote computer behind a firewall opens up a connection to another server in the outside world. A client then connects to that outside server and the connections are bridged. That connection is called a tunnel. A simpler alternative exists and that is for the client’s computer to be that outside server itself. No need for a second connection or a bridge. No need for a separate server in the middle. Explaining the name, “Reverse” means the connection is going in the reverse direction from the normal way, from the inside out rather than the outside in. “SSH” stands for secure shell. SSH is a standard that encrypts all the data so there are no security issues. “Tunnel” is the term used to describe what this connection is. Let’s take a look at how to implement Reverse SSH Tunneling.
Requirements — For Windows: OpenSSH Client and OpenSSH Server are needed on both computers. On Windows the apps are included but need to be installed. They are found in the Apps window under Optional Features. For Raspberry Pi both applications are already included.
Once installed and started at both ends open a command line window on the remote computer then enter the following instruction. This will tell the remote computer to open a tunnel to the local computer. That tunnel can then be used for traffic back from the local computer to the remote computer (in “reverse”).
> ssh -R 8888:localhost:3389 firstname.lastname@example.org@220.127.116.11
That’s it. Explanation: ssh means the arguments that follow are going to open up a tunnel
-R means the direction of the tunnel is going to be reverse.
8888 is an arbitrary port number chosen at random which will be used later by the user at the other end on the local computer.
localhost is the computer where the application will be executed, in this case the remote computer. “localhost” just means the name of whatever computer you’re currently on which in this case is the remote computer.
3389 is the port for Windows Remote Desktop. Remote Desktop Connection is the application that will be executed.
email@example.com is the username on the local computer. Replace it with your own username on the local computer.
@18.104.22.168 is the i.p. address to reach the local computer from the remote (port forwarding is used at the local computer end) Replace this address with the i.p. of your local computer or router.
When the line is entered on the remote computer the response will be to connect a tunnel from the remote computer to the local computer. A password will be asked for and that is the password for the username on the local computer. If everything worked correctly the remote computer will just sit there listening for incoming traffic on the tunnel.
On the local computer the user will open Remote Desktop Connection and enter this information in the “Computer” field:
The password will be needed for the Remote Desktop Connection for the remote computer.
Traffic to flow back down the tunnel from the local computer to the remote computer and a remote desktop screen will pop up on the local computer. Any operation that can be done on the remote computer can now be done on the local computer including operating the Flexradio and all the peripherals.
How to keep the tunnel up when not in use? That’s a challenge and it has a name—persistence. Persistence is quite easy with Linux systems. One would use autossh instead of ssh. Autossh has built-in tools for keeping the tunnel alive when not in use. Windows does not have those tools and autossh does not run in the Windows operating system. Several 3rd party apps exist but they look like unworkable kluges. This challenge is a work in progress. So far the tunnel is being established when needed and it times out a few hours after it’s no longer being used.