Can't reach mqtt broker from external network

Skip to first unread message

Andrea Giordano

Oct 8, 2017, 3:55:16 PM10/8/17

I have a MQTT broker installed on a raspberry pi 3 running inside a network owned by a Vodafone station revolution. In order to access to raspberry from a device located out of the network I enabled port forwarding on the station mapping the fixed local ip of the raspberry with a pair of internal-external port. So linking port 1880 (node-red server on rpi) I have access from the extern of the network using the public ip of the station and the public port. At this point everything works. This lied me to think port forwarding works correctly.

I've done the operation for the mqtt broker installed on the same rpi (rpi3-mqtt in the pic). I have a python script (running on a laptop outside the network) which publish data on it with this code:

mqttClient = mqtt.Client()
mqttClient.connect(host=raspberry_MQTT_ip, port=1883)
mqttClient.publish("topic/sensorLCacc", jsonData)

where raspberry_MQTT_ip is the public ip of the vodafone station. Clearly I added port 1883 to port forwarding options in the station as already done with port 1880. Unfortunately in this case, when I execute the script it raise an exception when it tries to create the connection, as the ip was not reachable.

I used telnet public_ip 1883 and the connection is established. I disabled firewall on the vodafone station. Everything works if I try to reach the mqtt broker using the local ip of the raspberry.

I attached port forwarding options of the station:

error trace:

Traceback (most recent call last):
  File "/Users/giordano/Dropbox/Andrea/tesi/sensorsScripts/simulatedsensors/", line 49, in <module>
    mqttClient.connect(host=raspberry_MQTT_ip, port=1883)
  File "/Library/Python/2.7/site-packages/paho/mqtt/", line 760, in connect
    return self.reconnect()
  File "/Library/Python/2.7/site-packages/paho/mqtt/", line 887, in reconnect
    sock = socket.create_connection((self._host, self._port), source_address=(self._bind_address, 0))
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/", line 575, in create_connection
    raise err
socket.error: [Errno 61] Connection refused

where line 49 of simulatedsensors/ is 

mqttClient.connect(host=raspberry_MQTT_ip, port=1883)

Any ideas?

Paul Fremantle

Oct 9, 2017, 1:27:31 PM10/9/17
If you can telnet on port 1883 to the broker, its not clear what is going on. Have you tried putting a network tracer like Wireshark on the Pi?


To learn more about MQTT please visit
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
For more options, visit

Paul Fremantle
Doctoral Researcher, University of Portsmouth, School of Computing
Visiting Scientist, Institute of the Architecture of Application Systems, Stuttgart
Visiting Lecturer, Software Engineering Programme, Oxford University
Co-Founder, WSO2
Apache Member and Committer
twitter: pzfreo / skype: paulfremantle / blog:

Andrea Giordano

Oct 9, 2017, 5:23:02 PM10/9/17
yes I can use telnet. That's very strange. 
I noted a new behaviour, the publishing on the broker works for some seconds and then the error appears: it seems like a block provided by the router... I have also deactivated firewall and used DMZ on the raspberry ip.
No, I have no tracer on pi, maybe I can try 
To unsubscribe from this group and stop receiving emails from it, send an email to

To post to this group, send email to
Visit this group at
For more options, visit

Oct 10, 2017, 3:57:17 AM10/10/17

Do you have two interfaces on the machine where you run your MQTTClient?  

The possibility may be the Telnet traffic going via interface which resolves the MQTT_Broker_IP while the MQTT client goes via the other interface which does not resolve the Public IP 

A Wild Guesss !! 

Cheers , 
Bevywise Networks

Gambit Communications

Oct 10, 2017, 11:14:05 AM10/10/17
If you can telnet to the 1883 port, you have proven that it's likely not a layer 4 problem.
In our experience, the symptoms you describe means that the server asynchronously disconnects your session
(thus you think some PUBLISH requests succeed).
The only way to diagnose this is by looking at broker logs (a good broker will give you a hint why it does not like
the session).
The next best thing is an open-source broker that you can modify to get at the reason.
If you don't have access to the logs, then the next best thing is to get a PCAP from a protocol analyzer like
wireshark and GUESS from the protocol exchange.
Reply all
Reply to author
0 new messages