Using qbee to access other remote devices (ssh port forwarding)

How to access closed edge devices in a remote network?

This tutorial shows how it is possible to use qbee as a gateway on any embedded Linux device on the edge. Through qbee other connections over any port (such as http or https) can be routed to your local desktop. Across firewalls and the internet. This is very handy if you have closed edge devices such as some SCADA systems in your remote network but you want to be able to do remote maintenance or generally access and configure these devices.

A general problem for industrial IoT applications is that some parameters need to be configured or they contain interesting information but the device they are running on is shielded 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 and authentification or none at all. Therefore these devices are isolated from the outside. But there is a technique called ssh port forwarding that in conjunction with qbee-connect and the qbee VPN will allow to relay data from the other devices as well. In this case the device running qbee acts as a remote gateway taking care of all VPN functionality out of the box. If you want to do that with UDP please follow this example.

What is ssh port forwarding?

SSH port forwarding is a mechanism for tunneling application ports from the remote machine to a localhost port on your local machine running qbee-connect. So a secure or non-secure port (80 or 443) can be tunneled through the secure VPN. Then on the local machine ssh is used to make it accessible. Please see how a system diagram looks in the drawing below.


In this example we have a device in a remote location that for example runs an HVAC application on port 1880. In the same network a device running qbee is used for something else. Now the qbee device can be used to relay the port 1880 through ssh port forwarding to a laptop being anywhere in the world. So how does this work?

First we need to start qbee-connect on our local machine and connect port 22 of the qbee device in the remote network. This gives the mapped port number for ssh. Now we can use the VPN tunnel to ssh into the remote network throiugh the qbee gateway and tunnel through the firewall:


Establishing the ssh port forwarding

The following information is needed:

  • the mapped port for qbee (received from the qbee-connect tool): 54580
  • the ip address of the device that we want to connect to:
  • 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:

ssh -p 54580 -L 8080: pi@localhost
When this is established the web application from the local device is now available on the local machine running qbee-connect. This machine can be anywhere in the world. The mapped web application will appear on localhost:8080 as specified above:


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 through a qbee device.

In order to work the web application needs to use relative URLs

This concept works as long as the web application has relative URLs. This is the most common way to implement it, but for debugging this can be helpful information. SSH port forwarding only works with 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 If this was a qbee device (which does not make sense because then you could access this directly through its own VPN) a simple firewall rule like this would make it much more secure: