Investigating Tunnelling

Published: Last updated:
  • #log

At $WORK we need to implement some form of tunnelling solution to give users the ability to remotely manage a service running on an RPi CM4.

This has lead me to investigate 'tunnelling' and the various ways of implementing it. One helpful resource I've found is this repository containing a big list of different projects that provide tunnelling solutions:

What is tunnelling?

According to CloudFlare,

... in networking, tunnels are a method for transporting data across a network using protocols that are not supported by that network. Tunneling works by encapsulating packets: wrapping packets inside of other packets.

More specifically I'm interested in (what I'm calling) reverse tunnelling, where we have a device behind potential firewalls and/or NAT and we want to be able to communicate with it without configuring port forwarding or static IP addresses -> meaning the device must reach out to a publicly accessible server in order to set up the tunnel that can then be used by users over HTTPS. Sort of like a relay.

Common outer protocols

I'm defining this to mean the protocol or transport mechanism
which you encapsulate the data you really want to send inside of.

Common methods include SSH and WebSockets. Based on my research both CloudFlare and AWS IoT Core use Websockets as their main transport mechanism for creating tunnels.

From what I can gather SSH may have been preferred in the past but modern corporate firewalls have a higher chance of being configured to drop outgoing SSH connections. In contrast HTTPS on port 443 is very unlikely to be blocked thus it's a very common choice.

A VPN could also be used as a tunnel. A Wireguard VPN with a TCP keepalive from client (RPi) to server would also give remote access but I'm unsure if this would be harder to configure and secure on the server-side.

Load-balancing is also something that will probably come into play.

Catch ya later, Omni