Key Feature 2: Air-gapped on-demand mode

tnnl clients don't need to communicate directly with the internet.
Using a browser a bridge can temporarily be established on-demand between the device and the tnnl backend to enable remote maintenance on the device.

It's safer this way, because the device can be operated in a network without internet access (air-gapped) und therefore can't be attacked.

A browser that is simultaneously connected with the tnnl backend and the air-gapped network may serve as bridge.
That works via a website that is provided by the tnnl client and opened on the browser, that establishes the connection between the client and the websocket of the tnnl backend.

Key Feature 3: Bridge for unsupported devices

tnnl can make network services on a device remotely available via a bridge-client when the tnnl client can't be installed on the device itself. The bridge client can be installed as an application or it can be operated on a dedicated device.

This is

• better than VPN, because the user of the sercvice doesn't need to install any additional software
• better than port forwarding, because many internet providers only provide DSLite nowadays, which doesn't support port forwarding. tnnl also doesn't need changes on the network infrastructure, that port forwarding would entail (which may even be not possible in some cases).

Key Feature 4: Auto-provisioning for bulk-configurations

A manual configuration per device is not necessary for the device to register with the tnnl backend. You can rather provide many devices with the same firmware and have them automatically configured at first contact with the tnnl backend.

How does that work?

tnnl provides a bootstrapping API. Using this API the operator of the tnnl backend can automatically integrate new devices into tnnl.

(Where) is this getting used already?

In bigger IIoT fleets numerous devices are provisioned, login to tnnl and are then assigned to end customers by our customers. Therefore no manual configuration before shipping a devices to the end customer is needed.

Key Feature 5: Support for a wide range of platforms

The tnnl client is designed for maximum compatibility, supporting a wide range of platforms and environments.

• RaspberryPi 1/2/3/4/5/Zero/Zero2/Pico
• ESP32
• ARM
• Linux
• Docker

Key Feature 6: Everything is under your control

Access via enabling / disabling

Access to the devices can be switched on only when needed; the tnnl control panel enables fine-grained control over this.

Access authentication

tnnl can add password protection to every http(s) connection over tnnl. This can also be configured in the tnnl control panel.