Score:0

Unable to connect to my self hosted cloud MQTT broker

cn flag

I have followed the instructions to configure Mosquitto on CentOS 7, provided by digital ocean. I believe I have most of the stuff set up correctly, I was able to follow all the instructions with some deep diving to find solutions for some deprecated instructions. But, I am able to subscribe and publish messages to a topic when I'm logged on to my server.

However, I want to access my own MQTT broker from a different client than the server's address (duh). I'm unable to connect, no matter what I try - I feel the connection attempt doesn't reach my broker (both using an online viewer like https://hobbyquaker.github.io/mqtt-admin/ and a locally installed one like MQTT explorer ).

My mosquitto.conf is pretty simple, and I have simplified it more to allow anonymous connections, but with TLS for both web sockets over port 8083 and (default?) mqqt over port 8883.

Complete mosquitto.conf file (updated after Halfgaar's reaction):

allow_anonymous true
#password_file /etc/mosquitto/passwd (I have disabled this to simplify my connection attempt)
log_dest file /var/log/mosquitto.log
log_type all

listener 1883 localhost

listener 8883 0.0.0.0
protocol mqtt # newly added, but still doesn't seem to do anything
certfile /etc/letsencrypt/live/iot.mydomain.com/cert.pem
cafile /etc/letsencrypt/live/iot.mydomain.com/chain.pem
keyfile /etc/letsencrypt/live/iot.mydomain.com/privkey.pem

listener 8083 0.0.0.0
protocol websockets
certfile /etc/letsencrypt/live/iot.mydomain.com/cert.pem
cafile /etc/letsencrypt/live/iot.mydomain.com/chain.pem
keyfile /etc/letsencrypt/live/iot.mydomain.com/privkey.pem

Later I thought the default Mosquitto.conf file contains much more settings, and copied a fresh copy of the default settings in my configuration file, and at the end of the file added the configuration mentioned above. So now I have a default config with the above overrides. Restarting the mosquitto service was succesfull.

Then I figured it had something to do with the firewall perhaps. I've checked if the ports 1883, 8883 en 8083 were open through firewall-cmd --zone=public --permanent --list-ports and found that part of that output indeed reported 8883/tcp 8083/tcp 1883/tcp.

The specified log file doesn't contain any information for attempted connections, so I'm blind there. Can someone point me in a direction to find more clues to solve this issue?

Update Upon @Halfgaar's reaction: I updated the config with binding to public addresses (I'm only repeating what he said, I have no clue), when I run netstat -n -l -t -p the output is below. Despite I'm not able to connect to the broker from my laptop (or anywhere else).

# netstat -n -l -t -p | grep mosquitto
tcp        0      0 0.0.0.0:8883            0.0.0.0:*               LISTEN      2573/mosquitto      
tcp        0      0 127.0.0.1:1883          0.0.0.0:*               LISTEN      2573/mosquitto      
tcp6       0      0 :::8083                 :::*                    LISTEN      2573/mosquitto      
tcp6       0      0 ::1:1883                :::*                    LISTEN      2573/mosquitto 

Update I also stumbled upon a firewall rule that made me think if I would be able to connect with an mqtt protocol, therefore I also executed firewall-cmd --zone=public --permanent --add-service=mqtt and reloaded the firewall.

Little progress I've moved forward from getting the error Disconnected from server to connect ETIMEDOUT 1.2.3.4:8883 (where 1.2.3.4 is the IP of my server). Not sure what this means in terms of progress, but I am somewhere else as where I was before...

Update The output for iptables -L INPUT -n is as follows:

# iptables -L INPUT -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
INPUT_direct  all  --  0.0.0.0/0            0.0.0.0/0           
INPUT_ZONES_SOURCE  all  --  0.0.0.0/0            0.0.0.0/0           
INPUT_ZONES  all  --  0.0.0.0/0            0.0.0.0/0           
DROP       all  --  0.0.0.0/0            0.0.0.0/0            ctstate INVALID
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Solved It seemed I also had another (software) firewall on my VPS which I had to configure as well. When I opened the ports in that firewall too I was able to login.

ng flag
Can you also post the output of `iptabes -L INPUT -n`? BTW: a closed port will give an immediate reject. A fire-walled port, typically, will time out.
Ben Fransen avatar
cn flag
Thanks for your reply. I've updated my post with the output.
Score:0
cn flag

I would like to thank @Halfgaar for the assistance and trying to help me solve it. Meanwhile I also contacted support from my VPS hosting provider. The issue was firewall related, though not the firewall we were exploring. There's a software firewall in place as well, and I had to open the ports there too (of course). I wasn't aware I also had another firewall active on my VPS. I am able to login to my broker now!

Score:0
ng flag

You'not binding to your public network interfaces. If you do netstat -n -l -t -p you can see on what address processes are listening.

Do:

listener 1883 0.0.0.0

listener 8883 0.0.0.0
certfile /etc/letsencrypt/live/iot.mydomain.com/cert.pem
cafile /etc/letsencrypt/live/iot.mydomain.com/chain.pem
keyfile /etc/letsencrypt/live/iot.mydomain.com/privkey.pem

listener 8083 0.0.0.0
protocol websockets
certfile /etc/letsencrypt/live/iot.mydomain.com/cert.pem
cafile /etc/letsencrypt/live/iot.mydomain.com/chain.pem
keyfile /etc/letsencrypt/live/iot.mydomain.com/privkey.pem
Ben Fransen avatar
cn flag
Thanks for your reply. I tried to follow along, but I still can't connect. Any suggestions? I've updated my question with the output from your netstat query.
Ben Fransen avatar
cn flag
Additional info> I've been fiddling around to see the differences with and without binding to 0.0.0.0, but the netstat output doesn't seem to bother - and even without binding to 0.0.0.0 I see the websockets protocol port listed with netstat, with binding its not vissible.
ng flag
@BenFransen are there entries in the Mosquitto log? Also, I edited my answer; the first listener should have been port 1883.
Ben Fransen avatar
cn flag
there aren't any logs for failed connection attempts or so. The only entries in the log are from when I subscribe and publish through SSH directly on the server ( not from outside the server).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.