Access to Gateways behind Firewalls

Often, IoT devices are naturally used as servers. For example, the standard GATT REST API of the Bluetooth SIG treats a Bluetooth Smart gateway as an HTTP server (while being a Bluetooth Smart client "on the other side"). In many cases, it even makes sense to treat a device as both an HTTP server and client. For example, in our Limmat Beacon API a gateway device is an HTTP server for letting a subscriber register a Webhook, and a client for pushing beacon events to Web services.

This means that a gateway must not only be able to act as a client (i.e., opening "outgoing" connections to the other endpoint, sending requests, and receiving responses) but also as a server (i.e., accepting "incoming" connections from the other endpoint, receiving requests, sending responses).

In general, it is not possible to open a connection from anywhere on the Internet to a gateway via 3G, as firewalls of mobile network operators typically only allow outgoing connections from their networks (see figure below). Network address translation (NAT) adds further obstacles to the use of incoming connections. It is often possible to buy private access points, where the firewall rules are relaxed, but this can be expensive and a major hassle, in particular if you have to do it individually for several operators, in multiple countries.

While this is an artifact of how mobile operators work today, it seems unlikely to change anytime soon (even in spite of IPv6). Moreover, there are good arguments why low-end gateways in general should never open any incoming ports: handling incoming connection requests consumes memory and processor cycles, which makes such devices prone to denial-of-service-attacks. It is safer to only open outgoing ports and leave the handling of attacks to far more powerful servers, and to organizations that are able to detect and react to such attacks.

So from a security perspective, the limitation to outgoing connections is not a bug, but a feature!

One way to overcome the problem that gateways as servers are desirable, is to separate connection establishment from the direction in which requests are sent. While a gateway physically remains a client, it should be able to logically act as an ordinary server as well. This can be achieved e.g. through a reverse HTTP protocol: the gateway automatically establishes an outgoing connection to a well-known relay service, in our case to Yaler. Incoming requests are addressed to some URL on the relay service and forwarded from there in the "wrong" direction to the gateway (see Figure below). The relay service thus acts as a reverse proxy.

Yaler is available as a highly reliable hosted service, on shared or dedicated relay clusters, in data centers around the world. Other relay services are Microsoft's Azure Service Bus, PageKite and Applied Informatics.

Note that the need for a relay service, which provides a well-managed, secure and scalable façade in front of the gateways and their sensors, is similar to the need for brokers when using MQTT, AMQP or XMPP.

Relay services (as reverse proxies) allow even small devices in edge networks to act as servers. Relay services (as normal proxies) can also allow the devices to act as clients. Both in a secure and manageable way. Relay services don't need to persistently store any data, and as they simply forward bytes they can be used with encrypted data, which simplifies end-to-end security scenarios.

Cuno Pfister, Oberon microsystems AG

Disclaimer:

Yaler GmbH is spin-off company of Oberon microsystems. We developed the Yaler relay server (note that Yaler is relaY spelt backwards) because we hit the need for such a service in several customer projects. While it is not difficult to implement a reverse HTTP protocol, it is difficult to implement it at scale, in a way that is high performance (on single servers), clusterable, fault tolerant and easy to manage.