In this article we describe how to use Mosquitto as a bridge to a central SSL-enabled MQTT broker to allow IoT devices in the last 100 metres to be securely connected to the cloud.


Connecting the Last 100 Metres to the Cloud using Mosquitto

A lot of the growth in the domain of the Internet of Things (IoT) is going to come from devices that are connected in the last 100 metres. These devices will cover a wide range of industries, such as transportation, health care, utilities, security, and many more. A majority of these devices will have limited cpu power and small amounts of memory to enable lower power consumption and cost. These characteristics make it difficult to connect them to an SSL secured MQTT Broker, since most SSL implementations demand more resources than are available. Meanwhile, the MQTT protocol itself is a desirable light-weight protocol to be able to use in these devices.

In this article we present a solution that uses a local LAN-based MQTT broker acting as a bridge to a central cloud-based MQTT Broker. The bridged connection is encrypted using SSL.

The IoT devices are connected to the LAN using either wired or wireless connections, and only the bridging broker needs to have access to the Internet (see Figure # 1).


Figure 1: Network Diagram

This article assumes that you already have an MQTT Broker running somewhere in the cloud capable of communicating using SSL, such as described in our previous article Securing MQTT on Apache ActiveMQ →. That article also provides links and information on how to obtain the necessary SSL certificates.


We are using Mosquitto to act as our bridging solution. Mosquitto is an open source (BSD licensed) message broker which implements the MQTT protocol version 3.1, and is readily available on a wide range of platforms. Please refer to → for more information.

MQTT is a publish/subscribe type of protocol, and Mosquitto allows you to define a set of topics you would like it to publish (or subscribe) to on the cloud broker.


In this instance, we are using routers with OpenWRT installed as the platform to run Mosquitto because it allows us to simplify the hardware count of sensor networks while providing all of the required network security and management functions on a single node. OpenWRT is a Linux distribution whose origins stem from when Linksys used GPL code as the operating system for their WRT54G router. It has grown since then to support a wide range of hardware platforms and has a very complete selection of installable software packages.

Please refer to → for more information.

We are using the OpenWRT OS version called Attitude Adjustment 12.09, which we compile from source in order to update it to use a more current version of Mosquitto (1.3.1 rather than 0.15).

Figure # 2 is a screenshot from an ASUS WL-500gP Wireless Router that we flashed with OpenWRT, but all of the Mosquitto information in this article is equally applicable to versions running on platforms such as PCs with Linux.


Figure 2: OpenWRT Attitude Adjustment Splash Screen

Configuring Mosquitto

All of the configuration settings required for Mosquitto are defined in a file called mosquitto.conf (usually found in /etc/mosquitto on Linux-like OSs). In our example we are assuming the same security model as that presented in our article Securing MQTT on Apache ActiveMQ →. The cloud-based MQTT broker uses SSL to encrypt the communications channel, and account names and passwords for authenticating and authorizing access. It is assumed that all of the local devices will not require any security settings to communicate with the local Mosquitto bridge.

Mosquitto allows you to force the local devices to use MQTT account names and passwords if desired, but in our model, that level of access control on the LAN is enforced by the router, so it is not shown in this example.

We will define the minimal settings that need to be changed to reflect our model.

  • Define a connection called ‘MyMQTTBridge’.
  • Set the address of the cloud-based MQTT broker to be ‘’ (in actual usage, this would be a global IP address or domain name of a server in the cloud).
  • Tell Mosquitto to subscribe to ‘MyTopic’ and ‘MyTopic2’ and publish them to the MQTT broker in the cloud on our behalf.
  • Set the MQTT client ID to be used with the cloud-based MQTT broker to be ‘MyBridgeClient’.
  • Set the MQTT user name (defined by the MQTT broker> to be ‘myMQTTAccount’.
  • Set the MQTT user password (defined by the MQTT broker> to be ‘myMQTTPassword’.
  • Define the CA file (PEM file provided by the cloud-based MQTT broker) to be located at ‘/etc/mosquitto/cacert.crt’.

Figure 3: mosquitto.conf fragment

Figure 3 shows the fragment of mosquitto.conf that required changes; the rest of the settings can be left as those provided by default.

Mosquitto can now be started by executing the command:

mosquitto -c /etc/mosquitto/mosquitto.conf

LAN Network Security

Like many cases of IoT devices in the last 100 metres, the only access to the Internet is through the connected router. This makes our network security model simpler since it allows us to define firewall rules on the router that can be very specific about which ports and IP addresses to allow access. In OpenWRT (and other linux-based OSs) this is done using iptables. There is a lot of information about how to use iptables available on the Internet; please see  Ubuntu IPTables HowTo → as one example.  Iptables would allow you to define access restrictions for local devices as well if further control is desired.

This article has shown that the MQTT protocol can be used for data exchange throughout an IoT system, from devices connected in the last 100 metres, as well as public-facing processing centres in the cloud, without comprising security.


Leave a Reply

You must be logged in to post a comment.