Ssh port forwarding for remote device access behind firewall

Often web server access to remote devices behind a firewall is needed (Wifi router, smart home). This is how you can solve this securely.

Ssh port forwarding for remote device access behind firewall

Categories: Intermediate

Using ssh port forwarding to remotely connect to a closed device running a web server behind a firewall

Background:

Many industrial IoT applications have parameters that need to be configured or they contain interesting information but the device they are running on is not accessible in terms of OS (operating system) and it is protected from external access through firewalls. Often that makes sense as they operate an open web server on port 80 (http) or they have a low security web application setup with only basic login. Therefore these devices are isolated from the outside by firewall and NAT.

This also applies to hobbyist applications such as a Node-Red instance, your Wifi router or a
pi-hole
installation in your local network that you might want to have access to from anywhere. But these applications also run behind your router firewall.

ssh port forwarding through VPN:

But there is a technique called ssh port forwarding that can resolve this. The idea is to have another device in the local network that can be accessed through a virtual private network with ssh. Then an ssh port forwarding is created that forwards the original device’s service on the specific port to the second device and this is accessed with the virtual private network and another mapped port.

What is ssh port forwarding through VPN?
SSH port forwarding is a mechanism for tunnelling application ports from a remote machine that we do not have access to via a local device with external ssh access in the same remote network. This device usually needs to provide a VPN to be reachable from the outside. So any secure or non-secure port (80, 443 or any port) can be tunnelled through the secure VPN of the second device. Then on the local desktop machine ssh is used to make the specific port accessible. Please see how a system diagram looks in the drawing below. There we use qbee to provide the on device VPN, the tunnel and qbee-connect to abstract it to a desktop device outside the firewall.

Block diagram of the setup

For this tutorial we use a software called
qbee.io
to show the concept because the VPN is already included and configured in the agent. There is a free 30 day trial available.

But the same concept can be implemented with any other open source software as well.

First a VPN into the local network needs to be created. We install the qbee agent on any Raspberry Pi, odroid, BeagleBoard or other Linux device that we have OS access to and bootstrap it to the qbee cloud platform. The agent provides full secure VPN access out of the box.

Then the device running the qbee agent in the local network, in conjunction with qbee-connect (a desktop tool available for Windows, macOS and Linux) and the integrated qbee VPN will allow to relay data via ssh port forwarding from the other devices as well. Any port can be forwarded (VNC (port 5900), http (port 80), https (port 443), Node-Red (port 1880) or even the Minecraft server port 25565). qbee-connect simply bridges a virtual private network from device to cloud and again from cloud to desktop.

Our example with an HVAC control build on Node-Red

In this example we have a device in a remote location that for example runs an HVAC application build on Node-Red on port 1880 (it is called Machine 1 in the diagram above and the port number is 80 instead of 1880). So it could just as well be your closed Wifi router on port 80. In the same network a device running qbee is located. Now this device can be used to relay the port 1880 through ssh port forwarding to a machine being anywhere in the world through the VPN that is established between the device and the user desktop machine.

So how does this work?

First we need to start qbee-connect on our desktop machine and securely connect to port 22 of the qbee device in the remote network. This gives the mapped port number for ssh access via terminal (in this case the random port number 54580). Now we can use the VPN tunnel to ssh into the remote network and tunnel through the firewall:

qbee-connect desktop tool interface

Establishing the ssh port forwarding

The following information is needed:

  • the random mapped port for qbee (received from the qbee-connect tool): 54580
  • the ip address of the device that we want to connect to: 192.168.100.22
  • the port number of the application that is running: 1880
  • the user that has ssh access on the qbee device: in this case user "pi"
  • the port we want to connect the other device to: 8080

This allows to construct the command that maps the HVAC application on the device to port 8080 on localhost. This needs to be run in the terminal on the desktop machine outside the firewall:

ssh -p 54580 -L 8080:192.168.100.22:1880 pi@localhost

When this is established the web application from the remote local device 192.168.100.22:1880 is now available on the remote local qbee machine with ip 192.168.100.25. This is mapped via the qbee-connect VPN to your local machine. (Again you can use other open source VPN solutions just as well, I am just trying to explain the concept). This is in a way a port mapping on a port mapping through a virtual private network. This desktop machine for final access can be anywhere in the world. The mapped web application will appear on localhost:8080 (as specified above) on the desktop machine in any browser (please see the URL in the screenshot):

The remote Node-Red UI being shown on localhost:8080

This can be done with any application on one or many devices. A simple example could be accessing a wifi router in a home network.

In order for ssh port forwarding to work for web applications the web application needs to use relative URLs.

Some additional thoughts around this concept:

If possible the device from which the web application is originating should be as secure as possible. Obviously it needs to have the port 1880 exposed, otherwise the qbee device will not be able to connect to it. But it is recommended to set the firewall such that only the source IP of the relay device can access the device. In this case it is 192.168.100.25.

A simple firewall rule like the one below applied to the originating device would make it much more secure.

If you have access to the original device (like you usually would have for a Node-Red tool or pi-hole) you can use the qbee agent directly on that device and use qbee-connect to directly connect to it. Again there are other open source tools that can do this as well. So the concept described here is addressing the case that your Wifi router is not accessible from the outside or you have a legacy HVAC that prevents system access so you cannot put any software onto it.

Proposed firewall setting of the remote device with Node-Red

Comments are not currently available for this post.