12

I'd like my MQTT broker to be accessible from outside my home network, but I'm a bit reluctant to open a port in the firewall. And I'd like to avoid using my home IP.

It's pretty convenient to have an unencrypted open broker at home, but that doesn't work if I am going to expose it. What other options do I have?

4
  • @Bence Kaulics any suggestions on what's missing from my answer?
    – hardillb
    Sep 11, 2017 at 9:56
  • 1
    @hardillb Your answer is a good summary but I think it could be helpful to have some more details about each point. E.g. How to setup such bridge between two brokers. Also I simply would well come other ideas if there are any, this bounty description is the best I could find, your answer stands on its own as well. Maybe I should have chosen the "Did not receive enough attention" reason. Sep 11, 2017 at 10:22
  • As a non-expert, I would agree that point 2 (which seems the most valuable part of the answer) could be elaborated a little more. Maybe with a link to a how-to, now sure. Sep 11, 2017 at 13:23
  • unfortunately each different type of broker has a different way to configure a bridge so it is impossible to give a generic answer (Likewise with authentication/TLS setup)
    – hardillb
    Sep 11, 2017 at 17:14

3 Answers 3

10
+50

You basically have 3 options if you don't want to forward a port.

  1. Use a broker in the cloud so client from home always connect out to it. Use TLS and authentication so others can't eavesdrop or inject unwanted messages
  2. Use a cloud broker and set up a bridge between the internal broker and cloud broker (you still want to encrypt and set username/password on the cloud broker). This has the advantage that internal things keep working if the internet connection goes down.
  3. A VPN on all external devices to allow access to your home network (but, to be honest, you're probably going to have to either open a port for the VPN or have a router that supports being a VPN server)

But forwarding a port to a properly configured (about the same as the cloud broker) is not really a risk.

1
  • 1
    I like the cloud home bridge idea, that has the added bonus that all reporting services outside my home network will still function normally if my local broker drops out. And the local broker will get the "missed" data when coming back online. Great! :) Sep 7, 2017 at 18:44
3

Since the broker is a server, you MUST open at least one port for clients to connect.

So, your problem becomes a special case of exposing a service on the Internet.

This has been done via DMZ, either through proxy or other way to enforce stricter authentication than the default service. If your proxy lives on the cloud, that just extends your DMZ to the cloud.

Your simplest approach is probably to harden your broker (disable anonymous clients) and restrict who can connect to it through the firewall (allow only certain client IP addresses, if you know them in advance).

1
  • 3
    That is not correct, I have bridged my local broker with a cloud one. And since the bridge connection is initiated from inside my home network no port opening is required. Sep 15, 2017 at 7:04
3

@hardillb gave a good answer but let me try to add a few details adding some "real-life" touch:

  1. Choose some MQTT broker available to the public. HiveMQ can be a good example and you can start with the try-out page describing how to connect to the broker:

Connect to Public Broker

Host: broker.hivemq.com

Port: 1883

Websocket Port: 8000

  1. Choose which client best fits to you and use it for internal broker interconnection with the public MQTT broker. For example your C client could be Paho MQTT. The client has support for SSL/TLS so your security remains on a high level.

  2. Paho MQTT embedded can be your choice for external devices.

  3. HiveMQ has a pay-as-you-go licencing policy so you can consider it with care. Anyway you can check out this page for a list of cloud available and testing available MQTT brokers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.