New Network Paradigm

Problem: When the Flex is connected to the mobile hotspot with reverse ssh tunnel the radio can be accessed just fine from a pc but not from the Maestro. When the Flex is connected to the dedicated Internet connection with a static i.p. and port forwarding the Maestro works fine but the pc experiences drop outs and packet loss.

Solution: Change the existing conventional router to a Dual WAN router. This reduces the number of LAN’s from two to one. With only one LAN the Flex is always on the same LAN as the client. The Maestro can come in on the dedicated Internet connection and reach the Flex on the LAN. The pc can come in on the reverse tunnel and reach the Flex on the LAN. With Flex’s new Multi-Flex protocol the two can come in at the same time and share the Flex.

Several models of Dual WAN routers are available in the $100 range and they are currently be evaluated. One example is the Ubiquiti EdgeRouter Lite shown above. Notice the ports are labelled eth0, eth1, and eth2 rather than WAN and LAN. The ports are configurable to be either function.

Followup: It’s never as easy as it sounds. Load balancing is the first issue. The dual wan router is now installed, configured, and working as designed but not doing what was hoped for. At issue is which WAN a client is connected to when the reverse tunnel is established. If it’s on the wrong WAN the whole concept is defeated. One available option is to specify what ports go to which WAN. A SSH tunnel is using the SSH port which is 22. Directing port 22 traffic to the higher speed WAN will be the next experiment. Ultimately the Edgerouter was pulled from service and returned to Microcenter. The whole idea of a Dual WAN really hasn’t proved out. The original one-WAN router is back in the circuit and all is working just fine. As for having just one LAN, the two NUC’s are tied together back to back, one on each LAN. The interconnect is the second ethernet port for each NUC. The hardware is a USB ethernet dongle. The two LAN have different subnets. To reach the other LAN one just enters the address for the other LAN and the NUC routes out the second ethernet port. Thus there are two LAN’s but they are routed to each other by the NUC’s. Crude but it works. Later the interconnect was removed and one NUC has a connection to both LAN’s. No conflicts have occurred. On that NUC a reverse tunnel is established and connected to from the outside world. Other resources can be reached on the other LAN from that same NUC with no issues. It appears the dual wan router was never needed. The NUC is handling any routing needs quite elegantly. There are two LAN’s but the second LAN has only one resource connected and that’s the NUC’s second ethernet port. Every other resource is connected to the main LAN including the Flex radios. It all works well so far.

How To Get Through A Firewall From The Outside World

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 “hamstation@outlook.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 hamstation@outlook.com@174.51.135.253

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.

hamstation@outlook.com is the username on the local computer. Replace it with your own username on the local computer.

@174.51.135.253 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:

localhost:8888

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.

Persistence

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.

Additional Internet Connection

A second connection to the Internet at the remote site to eliminate dropouts and choppiness is being tested. The new service is a mobile hotspot and it has been in the works for over a year. The idea is to dedicate the hotspot to the Flex equipment and leave everything else on the original Internet service. The hotspot provides faster service when it works. The challenge over the past year has been getting the hotspot reliable. It now seems like the magic has been discovered and the hotspot is ready to be put into service at least for a test. Here is the whiteboard sketch of the new layout.

The goal is to eliminate short dropouts which have plagued the existing Internet service. A hotspot might provide faster service with no dropouts. Attaining reliability has not been the only challenge. Double-NATing had to be overcome which just means a double firewall preventing remote access. Port forwarding would not work. Chrome Remote Desktop is a solution. It overcomes double-NATing by originating a connection out from the hotspot to a Chrome server. To access the Desktop remotely one just has to connect to the Chrome server. A firewall is no longer an issue and port forwarding is also eliminated.

The device is an AT&T Mobile Hotspot with unlimited data for $35 a month. Hardware is a Netgear Nighthawk mobile hotspot. Speedtests show 25 Mbps download and upload with a latency of 40 ms. Latency is much worse than the existing provider. Whether the high latency will work is one reason for the test.

Two different LAN’s are no problem as long as all the Flex equipment is on the same LAN. The peripherals, like rotator control, power control, security cameras, for example, don’t care what LAN they are on so long as they can reach the Internet and can be reached remotely.

After two days the hotspot is staying up and the service seems to have no dropouts.

The Flex cannot be reached by the Maestro with this Internet arrangement. Ooops. The connection has been restored to the original configuration and the hotspot is surplus for now.

Back to square one. Meanwhile there is something new on the horizon. No pun intended but the something new is Starlink which is a new satellite internet provider. The next Starlink satellite might be coming over the horizon at this very moment. (Get it?) What sets this satellite service apart from previous satellite companies is speed and latency. Starlink will be a huge grid of very low earth orbiting satellites linked together with laser beams. Speeds are promised faster than cable internet now. Latencies are low because the satellites are so low. The project is being done by none other than one of the world’s super entrepreneurs, Elon Musk. Based on his track record that means it will probably be successful. A thousand satellites are already in orbit and in beta test in the far north. Beta testers report speeds of 100 Mbps. Mr. Musk is launching 60 satellites per month with a goal of 10,000. This service should be perfect for W0QL.

Nerd note: A light beam in space is faster than a fiber cable because a vacuum has less propagation delay than glass. Therefore the backbone between Starlink satellites will beat the speed of a fiber backbone on Earth. Upload data from your Starlink dish in Denver. The data goes from the bird over Denver to a bird at the destination and down to ground faster than the same data can go over a fiber network on the ground to the same destination.