Mosquito Server Refuses Connections Ubuntu 18.04












0















This is a fairly narrow issue, but I'm hoping the Ubuntu group can help. I asked on SO, but I am fairly sure the error I am getting is due to a missing setting in Ubuntu or an issue with my router port. I don't know how to debug this.



I installed Mosquitto on my Ubuntu 18.04 system. It operates on port 1883 by default. You can specify the exact port either on the command line or in the config file. I've tried many variations:



I opened port 1883 in the firewall via the ufw. That seems correct:



mark_admin:~$ sudo ufw status
Status: active
To Action From
-- ------ ----
1883 ALLOW Anywhere
5900 ALLOW Anywhere
1883 (v6) ALLOW Anywhere (v6)
5900 (v6) ALLOW Anywhere (v6)


I am able to connect to it from another computer on the local network. But when I try to open a connection from the "outside world" using the computer's actual IP address, I get a "No connection could be made because the target machine actively refused it" Error.



EDIT: Solved. I was port forwarding on the wrong router.










share|improve this question

























  • How do you define "the computer's actual IP address" in this context? The point of port forwarding is to route traffic from your router's WAN IP address to the private LAN IP address - the LAN IP has no significance on the "out"side

    – steeldriver
    Feb 26 at 23:10











  • @steeldriver: What I meant is the address I would get from "WhatsMyIP" (i.e. 96.221.154.134) as opposed to the local address of 192.168.0.155. But I am wondering now if I need to do the port forwarding at the Version Router, not my TP-Link. Because that is what actually faces the outside world. I'm not sure. I don't know servers and routers real well.

    – MarkJoel60
    Feb 27 at 1:20











  • Hmm... so you have multiple NAT routers between you and the public network? or is one configured as a plain switch?

    – steeldriver
    Feb 27 at 1:44











  • On the TP-link, when you login to it, can you look and see if there is as status page or anything for "WAN" and if it lists an IP address there? What is it? That can help us tell if there is more than one layer of NAT to deal with here.

    – Azendale
    Feb 27 at 1:51











  • @steeldriver - Yes. My actual router to the outside world is a Verizon Fios Modem/Router. Then I plug into that with the tp-link. Now that I am looking at it, it makes sense that the port is getting blocked at the FIOS level and the request is never seen by the Tp-Link to forward it. Does that sound about right?

    – MarkJoel60
    Feb 27 at 14:40
















0















This is a fairly narrow issue, but I'm hoping the Ubuntu group can help. I asked on SO, but I am fairly sure the error I am getting is due to a missing setting in Ubuntu or an issue with my router port. I don't know how to debug this.



I installed Mosquitto on my Ubuntu 18.04 system. It operates on port 1883 by default. You can specify the exact port either on the command line or in the config file. I've tried many variations:



I opened port 1883 in the firewall via the ufw. That seems correct:



mark_admin:~$ sudo ufw status
Status: active
To Action From
-- ------ ----
1883 ALLOW Anywhere
5900 ALLOW Anywhere
1883 (v6) ALLOW Anywhere (v6)
5900 (v6) ALLOW Anywhere (v6)


I am able to connect to it from another computer on the local network. But when I try to open a connection from the "outside world" using the computer's actual IP address, I get a "No connection could be made because the target machine actively refused it" Error.



EDIT: Solved. I was port forwarding on the wrong router.










share|improve this question

























  • How do you define "the computer's actual IP address" in this context? The point of port forwarding is to route traffic from your router's WAN IP address to the private LAN IP address - the LAN IP has no significance on the "out"side

    – steeldriver
    Feb 26 at 23:10











  • @steeldriver: What I meant is the address I would get from "WhatsMyIP" (i.e. 96.221.154.134) as opposed to the local address of 192.168.0.155. But I am wondering now if I need to do the port forwarding at the Version Router, not my TP-Link. Because that is what actually faces the outside world. I'm not sure. I don't know servers and routers real well.

    – MarkJoel60
    Feb 27 at 1:20











  • Hmm... so you have multiple NAT routers between you and the public network? or is one configured as a plain switch?

    – steeldriver
    Feb 27 at 1:44











  • On the TP-link, when you login to it, can you look and see if there is as status page or anything for "WAN" and if it lists an IP address there? What is it? That can help us tell if there is more than one layer of NAT to deal with here.

    – Azendale
    Feb 27 at 1:51











  • @steeldriver - Yes. My actual router to the outside world is a Verizon Fios Modem/Router. Then I plug into that with the tp-link. Now that I am looking at it, it makes sense that the port is getting blocked at the FIOS level and the request is never seen by the Tp-Link to forward it. Does that sound about right?

    – MarkJoel60
    Feb 27 at 14:40














0












0








0








This is a fairly narrow issue, but I'm hoping the Ubuntu group can help. I asked on SO, but I am fairly sure the error I am getting is due to a missing setting in Ubuntu or an issue with my router port. I don't know how to debug this.



I installed Mosquitto on my Ubuntu 18.04 system. It operates on port 1883 by default. You can specify the exact port either on the command line or in the config file. I've tried many variations:



I opened port 1883 in the firewall via the ufw. That seems correct:



mark_admin:~$ sudo ufw status
Status: active
To Action From
-- ------ ----
1883 ALLOW Anywhere
5900 ALLOW Anywhere
1883 (v6) ALLOW Anywhere (v6)
5900 (v6) ALLOW Anywhere (v6)


I am able to connect to it from another computer on the local network. But when I try to open a connection from the "outside world" using the computer's actual IP address, I get a "No connection could be made because the target machine actively refused it" Error.



EDIT: Solved. I was port forwarding on the wrong router.










share|improve this question
















This is a fairly narrow issue, but I'm hoping the Ubuntu group can help. I asked on SO, but I am fairly sure the error I am getting is due to a missing setting in Ubuntu or an issue with my router port. I don't know how to debug this.



I installed Mosquitto on my Ubuntu 18.04 system. It operates on port 1883 by default. You can specify the exact port either on the command line or in the config file. I've tried many variations:



I opened port 1883 in the firewall via the ufw. That seems correct:



mark_admin:~$ sudo ufw status
Status: active
To Action From
-- ------ ----
1883 ALLOW Anywhere
5900 ALLOW Anywhere
1883 (v6) ALLOW Anywhere (v6)
5900 (v6) ALLOW Anywhere (v6)


I am able to connect to it from another computer on the local network. But when I try to open a connection from the "outside world" using the computer's actual IP address, I get a "No connection could be made because the target machine actively refused it" Error.



EDIT: Solved. I was port forwarding on the wrong router.







firewall port-forwarding






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 27 at 19:39







MarkJoel60

















asked Feb 26 at 22:38









MarkJoel60MarkJoel60

153




153













  • How do you define "the computer's actual IP address" in this context? The point of port forwarding is to route traffic from your router's WAN IP address to the private LAN IP address - the LAN IP has no significance on the "out"side

    – steeldriver
    Feb 26 at 23:10











  • @steeldriver: What I meant is the address I would get from "WhatsMyIP" (i.e. 96.221.154.134) as opposed to the local address of 192.168.0.155. But I am wondering now if I need to do the port forwarding at the Version Router, not my TP-Link. Because that is what actually faces the outside world. I'm not sure. I don't know servers and routers real well.

    – MarkJoel60
    Feb 27 at 1:20











  • Hmm... so you have multiple NAT routers between you and the public network? or is one configured as a plain switch?

    – steeldriver
    Feb 27 at 1:44











  • On the TP-link, when you login to it, can you look and see if there is as status page or anything for "WAN" and if it lists an IP address there? What is it? That can help us tell if there is more than one layer of NAT to deal with here.

    – Azendale
    Feb 27 at 1:51











  • @steeldriver - Yes. My actual router to the outside world is a Verizon Fios Modem/Router. Then I plug into that with the tp-link. Now that I am looking at it, it makes sense that the port is getting blocked at the FIOS level and the request is never seen by the Tp-Link to forward it. Does that sound about right?

    – MarkJoel60
    Feb 27 at 14:40



















  • How do you define "the computer's actual IP address" in this context? The point of port forwarding is to route traffic from your router's WAN IP address to the private LAN IP address - the LAN IP has no significance on the "out"side

    – steeldriver
    Feb 26 at 23:10











  • @steeldriver: What I meant is the address I would get from "WhatsMyIP" (i.e. 96.221.154.134) as opposed to the local address of 192.168.0.155. But I am wondering now if I need to do the port forwarding at the Version Router, not my TP-Link. Because that is what actually faces the outside world. I'm not sure. I don't know servers and routers real well.

    – MarkJoel60
    Feb 27 at 1:20











  • Hmm... so you have multiple NAT routers between you and the public network? or is one configured as a plain switch?

    – steeldriver
    Feb 27 at 1:44











  • On the TP-link, when you login to it, can you look and see if there is as status page or anything for "WAN" and if it lists an IP address there? What is it? That can help us tell if there is more than one layer of NAT to deal with here.

    – Azendale
    Feb 27 at 1:51











  • @steeldriver - Yes. My actual router to the outside world is a Verizon Fios Modem/Router. Then I plug into that with the tp-link. Now that I am looking at it, it makes sense that the port is getting blocked at the FIOS level and the request is never seen by the Tp-Link to forward it. Does that sound about right?

    – MarkJoel60
    Feb 27 at 14:40

















How do you define "the computer's actual IP address" in this context? The point of port forwarding is to route traffic from your router's WAN IP address to the private LAN IP address - the LAN IP has no significance on the "out"side

– steeldriver
Feb 26 at 23:10





How do you define "the computer's actual IP address" in this context? The point of port forwarding is to route traffic from your router's WAN IP address to the private LAN IP address - the LAN IP has no significance on the "out"side

– steeldriver
Feb 26 at 23:10













@steeldriver: What I meant is the address I would get from "WhatsMyIP" (i.e. 96.221.154.134) as opposed to the local address of 192.168.0.155. But I am wondering now if I need to do the port forwarding at the Version Router, not my TP-Link. Because that is what actually faces the outside world. I'm not sure. I don't know servers and routers real well.

– MarkJoel60
Feb 27 at 1:20





@steeldriver: What I meant is the address I would get from "WhatsMyIP" (i.e. 96.221.154.134) as opposed to the local address of 192.168.0.155. But I am wondering now if I need to do the port forwarding at the Version Router, not my TP-Link. Because that is what actually faces the outside world. I'm not sure. I don't know servers and routers real well.

– MarkJoel60
Feb 27 at 1:20













Hmm... so you have multiple NAT routers between you and the public network? or is one configured as a plain switch?

– steeldriver
Feb 27 at 1:44





Hmm... so you have multiple NAT routers between you and the public network? or is one configured as a plain switch?

– steeldriver
Feb 27 at 1:44













On the TP-link, when you login to it, can you look and see if there is as status page or anything for "WAN" and if it lists an IP address there? What is it? That can help us tell if there is more than one layer of NAT to deal with here.

– Azendale
Feb 27 at 1:51





On the TP-link, when you login to it, can you look and see if there is as status page or anything for "WAN" and if it lists an IP address there? What is it? That can help us tell if there is more than one layer of NAT to deal with here.

– Azendale
Feb 27 at 1:51













@steeldriver - Yes. My actual router to the outside world is a Verizon Fios Modem/Router. Then I plug into that with the tp-link. Now that I am looking at it, it makes sense that the port is getting blocked at the FIOS level and the request is never seen by the Tp-Link to forward it. Does that sound about right?

– MarkJoel60
Feb 27 at 14:40





@steeldriver - Yes. My actual router to the outside world is a Verizon Fios Modem/Router. Then I plug into that with the tp-link. Now that I am looking at it, it makes sense that the port is getting blocked at the FIOS level and the request is never seen by the Tp-Link to forward it. Does that sound about right?

– MarkJoel60
Feb 27 at 14:40










2 Answers
2






active

oldest

votes


















0














I am assuming that your server has internet access.



If you can get to the port on the local network, then the problem is definitely with the port forwarding.



First, does your server machine have a static IP address inside the network? If not, I highly recommend getting that fixed first. The reason for this is that when you set up a port forward, it will want to know what internal (192.168.0.x range) address to forward to. But if your server is Dynamic (using DHCP) then it will occasionally move, and every time it does, it will break the port forwarding.



Second, looking at your screenshot of the port forwarding settings, it mostly looks good, EXCEPT, it has 192.168.0.144, which is different than the 192.168.0.155 listed in the comments on the question. Make sure you fix that.



Third, where are you testing connecting with the outside address (96.221.154.134)? If it is from behind the same router, unless your router supports "hairpin NAT" (which most consumer routers don't) then it will not work. But it will work for everyone else "out on the internet" (IE, people not behind the same router). So it could be all working, and just how you are testing it could be broken. Obviously, if you are behind the same router, you should just use the internal address instead of the public address (if possible, IE, you aren't using DNS names that answer with the same address regardless of what router you are behind).



Fourth, if you have multiple routers, with multiple layers of NAT, the whole "set a static internal IP & forward a port to that" applies to each router. So if you have two routers, A & B, with B behind A and A connected to your ISP, you need to set router B to have a static IP address on it's WAN/upstream connection (which is router A's "LAN" network). Then on router A, you need to set up port forwarding to router B's address. Then you repeat the process for router B: set a static IP address on the server, and then on router B, forward the port to the server's static IP.



PS: Isn't NAT & port forwarding fun? (that was sarcasm). You might ask your ISP if they have IPv6 available which is the long term solution to not having to deal with port forwarding or NAT. Most ISPs have been pretty slow to implement IPv6; mostly because few customers understand enough to know it would make this all easier (once we get everyone on IPv6).






share|improve this answer

































    1














    I'm posting this as an answer so I can give more detail in case anyone stumbles upon this in the future.



    Setting up the MOSQUITTO MQTT Server in Ubuntu 18.04 is actually not hard, but the steps are important.



    Step 1: Install Mosquitto Software



    sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
    sudo apt-get update
    sudo apt-get install mosquitto


    Step 2: Open Port 1883 and start firewall



    sudo ufw allow 1883 
    sudo ufw enable


    Step 3: Verify Mosquitto is not already running



    pgrep mosquitto


    [Note, if any number shows, that is the PID of an already running Mosquitto. You can just kill it. Also, you can try: sudo service mosquitto stop]



    Step 4: Start Mosquitto with verbose option



    mosquitto -v


    [Note: This starts Mosquitto without using any config file. It echos connection and status information to the screen. Easiest for quick debugging.]



    Step 5: Check connectivity using local host



    Go to your client machine (in my case a Windows 10 laptop) and run the MQTT client, connecting to the local address of the Linux Mosquitto server (in my case 192.168.0.144). You should be able to connect. In fact, you can do this step before you even open the firewall, since this is all on the local network, the firewall rules are irrelevant at this point. Until next step which is...



    Step 6: Check Connectivity using web tool



    use either: www.yougetsignal.com/tools/open-ports/ or
    https://canyouseeme.org/



    [NOTE: You will not get an OPEN state UNLESS THE MOSQUITTO BROKER IS RUNNING]



    Step 7: If Port Shows Closed When coming In from Internet (ie not localhost)



    Here's where I got tripped up. In my case, I have a Verizon Modem that ALSO has a firewall (because it has a router). I have my own wireless router, a tp-link Archer C1200, that I have plugged into the Fios Modem/Router. I started by putting the port forwarding in the tp-link. But that firewall comes after the Fios firewall so I needed to go to the first wall and do the port forward there.



    And this is the second thing that is tricky. All of the online how-to's said I should forward port 1883 to the local IP address of my Linux Server, which in my case was 192.168.0.144. But that was not correct in my case. The Archer C1200 was actually the device that I needed to forward to -- it handled the correct distribution from there. It had an address of 192.168.0.152 assigned to it from the Verizon router. I still have both forwardings in place (ie the Fios and the tp-link) and my guess is that I need them both.



    Now all pathways are open, you can follow the other Mosquitto instructions regarding logging, config files, Daemons, etc.



    Hope this saves someone some time down the road!






    share|improve this answer
























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "89"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1121524%2fmosquito-server-refuses-connections-ubuntu-18-04%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      0














      I am assuming that your server has internet access.



      If you can get to the port on the local network, then the problem is definitely with the port forwarding.



      First, does your server machine have a static IP address inside the network? If not, I highly recommend getting that fixed first. The reason for this is that when you set up a port forward, it will want to know what internal (192.168.0.x range) address to forward to. But if your server is Dynamic (using DHCP) then it will occasionally move, and every time it does, it will break the port forwarding.



      Second, looking at your screenshot of the port forwarding settings, it mostly looks good, EXCEPT, it has 192.168.0.144, which is different than the 192.168.0.155 listed in the comments on the question. Make sure you fix that.



      Third, where are you testing connecting with the outside address (96.221.154.134)? If it is from behind the same router, unless your router supports "hairpin NAT" (which most consumer routers don't) then it will not work. But it will work for everyone else "out on the internet" (IE, people not behind the same router). So it could be all working, and just how you are testing it could be broken. Obviously, if you are behind the same router, you should just use the internal address instead of the public address (if possible, IE, you aren't using DNS names that answer with the same address regardless of what router you are behind).



      Fourth, if you have multiple routers, with multiple layers of NAT, the whole "set a static internal IP & forward a port to that" applies to each router. So if you have two routers, A & B, with B behind A and A connected to your ISP, you need to set router B to have a static IP address on it's WAN/upstream connection (which is router A's "LAN" network). Then on router A, you need to set up port forwarding to router B's address. Then you repeat the process for router B: set a static IP address on the server, and then on router B, forward the port to the server's static IP.



      PS: Isn't NAT & port forwarding fun? (that was sarcasm). You might ask your ISP if they have IPv6 available which is the long term solution to not having to deal with port forwarding or NAT. Most ISPs have been pretty slow to implement IPv6; mostly because few customers understand enough to know it would make this all easier (once we get everyone on IPv6).






      share|improve this answer






























        0














        I am assuming that your server has internet access.



        If you can get to the port on the local network, then the problem is definitely with the port forwarding.



        First, does your server machine have a static IP address inside the network? If not, I highly recommend getting that fixed first. The reason for this is that when you set up a port forward, it will want to know what internal (192.168.0.x range) address to forward to. But if your server is Dynamic (using DHCP) then it will occasionally move, and every time it does, it will break the port forwarding.



        Second, looking at your screenshot of the port forwarding settings, it mostly looks good, EXCEPT, it has 192.168.0.144, which is different than the 192.168.0.155 listed in the comments on the question. Make sure you fix that.



        Third, where are you testing connecting with the outside address (96.221.154.134)? If it is from behind the same router, unless your router supports "hairpin NAT" (which most consumer routers don't) then it will not work. But it will work for everyone else "out on the internet" (IE, people not behind the same router). So it could be all working, and just how you are testing it could be broken. Obviously, if you are behind the same router, you should just use the internal address instead of the public address (if possible, IE, you aren't using DNS names that answer with the same address regardless of what router you are behind).



        Fourth, if you have multiple routers, with multiple layers of NAT, the whole "set a static internal IP & forward a port to that" applies to each router. So if you have two routers, A & B, with B behind A and A connected to your ISP, you need to set router B to have a static IP address on it's WAN/upstream connection (which is router A's "LAN" network). Then on router A, you need to set up port forwarding to router B's address. Then you repeat the process for router B: set a static IP address on the server, and then on router B, forward the port to the server's static IP.



        PS: Isn't NAT & port forwarding fun? (that was sarcasm). You might ask your ISP if they have IPv6 available which is the long term solution to not having to deal with port forwarding or NAT. Most ISPs have been pretty slow to implement IPv6; mostly because few customers understand enough to know it would make this all easier (once we get everyone on IPv6).






        share|improve this answer




























          0












          0








          0







          I am assuming that your server has internet access.



          If you can get to the port on the local network, then the problem is definitely with the port forwarding.



          First, does your server machine have a static IP address inside the network? If not, I highly recommend getting that fixed first. The reason for this is that when you set up a port forward, it will want to know what internal (192.168.0.x range) address to forward to. But if your server is Dynamic (using DHCP) then it will occasionally move, and every time it does, it will break the port forwarding.



          Second, looking at your screenshot of the port forwarding settings, it mostly looks good, EXCEPT, it has 192.168.0.144, which is different than the 192.168.0.155 listed in the comments on the question. Make sure you fix that.



          Third, where are you testing connecting with the outside address (96.221.154.134)? If it is from behind the same router, unless your router supports "hairpin NAT" (which most consumer routers don't) then it will not work. But it will work for everyone else "out on the internet" (IE, people not behind the same router). So it could be all working, and just how you are testing it could be broken. Obviously, if you are behind the same router, you should just use the internal address instead of the public address (if possible, IE, you aren't using DNS names that answer with the same address regardless of what router you are behind).



          Fourth, if you have multiple routers, with multiple layers of NAT, the whole "set a static internal IP & forward a port to that" applies to each router. So if you have two routers, A & B, with B behind A and A connected to your ISP, you need to set router B to have a static IP address on it's WAN/upstream connection (which is router A's "LAN" network). Then on router A, you need to set up port forwarding to router B's address. Then you repeat the process for router B: set a static IP address on the server, and then on router B, forward the port to the server's static IP.



          PS: Isn't NAT & port forwarding fun? (that was sarcasm). You might ask your ISP if they have IPv6 available which is the long term solution to not having to deal with port forwarding or NAT. Most ISPs have been pretty slow to implement IPv6; mostly because few customers understand enough to know it would make this all easier (once we get everyone on IPv6).






          share|improve this answer















          I am assuming that your server has internet access.



          If you can get to the port on the local network, then the problem is definitely with the port forwarding.



          First, does your server machine have a static IP address inside the network? If not, I highly recommend getting that fixed first. The reason for this is that when you set up a port forward, it will want to know what internal (192.168.0.x range) address to forward to. But if your server is Dynamic (using DHCP) then it will occasionally move, and every time it does, it will break the port forwarding.



          Second, looking at your screenshot of the port forwarding settings, it mostly looks good, EXCEPT, it has 192.168.0.144, which is different than the 192.168.0.155 listed in the comments on the question. Make sure you fix that.



          Third, where are you testing connecting with the outside address (96.221.154.134)? If it is from behind the same router, unless your router supports "hairpin NAT" (which most consumer routers don't) then it will not work. But it will work for everyone else "out on the internet" (IE, people not behind the same router). So it could be all working, and just how you are testing it could be broken. Obviously, if you are behind the same router, you should just use the internal address instead of the public address (if possible, IE, you aren't using DNS names that answer with the same address regardless of what router you are behind).



          Fourth, if you have multiple routers, with multiple layers of NAT, the whole "set a static internal IP & forward a port to that" applies to each router. So if you have two routers, A & B, with B behind A and A connected to your ISP, you need to set router B to have a static IP address on it's WAN/upstream connection (which is router A's "LAN" network). Then on router A, you need to set up port forwarding to router B's address. Then you repeat the process for router B: set a static IP address on the server, and then on router B, forward the port to the server's static IP.



          PS: Isn't NAT & port forwarding fun? (that was sarcasm). You might ask your ISP if they have IPv6 available which is the long term solution to not having to deal with port forwarding or NAT. Most ISPs have been pretty slow to implement IPv6; mostly because few customers understand enough to know it would make this all easier (once we get everyone on IPv6).







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Feb 27 at 21:37

























          answered Feb 27 at 1:43









          AzendaleAzendale

          8,92873962




          8,92873962

























              1














              I'm posting this as an answer so I can give more detail in case anyone stumbles upon this in the future.



              Setting up the MOSQUITTO MQTT Server in Ubuntu 18.04 is actually not hard, but the steps are important.



              Step 1: Install Mosquitto Software



              sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
              sudo apt-get update
              sudo apt-get install mosquitto


              Step 2: Open Port 1883 and start firewall



              sudo ufw allow 1883 
              sudo ufw enable


              Step 3: Verify Mosquitto is not already running



              pgrep mosquitto


              [Note, if any number shows, that is the PID of an already running Mosquitto. You can just kill it. Also, you can try: sudo service mosquitto stop]



              Step 4: Start Mosquitto with verbose option



              mosquitto -v


              [Note: This starts Mosquitto without using any config file. It echos connection and status information to the screen. Easiest for quick debugging.]



              Step 5: Check connectivity using local host



              Go to your client machine (in my case a Windows 10 laptop) and run the MQTT client, connecting to the local address of the Linux Mosquitto server (in my case 192.168.0.144). You should be able to connect. In fact, you can do this step before you even open the firewall, since this is all on the local network, the firewall rules are irrelevant at this point. Until next step which is...



              Step 6: Check Connectivity using web tool



              use either: www.yougetsignal.com/tools/open-ports/ or
              https://canyouseeme.org/



              [NOTE: You will not get an OPEN state UNLESS THE MOSQUITTO BROKER IS RUNNING]



              Step 7: If Port Shows Closed When coming In from Internet (ie not localhost)



              Here's where I got tripped up. In my case, I have a Verizon Modem that ALSO has a firewall (because it has a router). I have my own wireless router, a tp-link Archer C1200, that I have plugged into the Fios Modem/Router. I started by putting the port forwarding in the tp-link. But that firewall comes after the Fios firewall so I needed to go to the first wall and do the port forward there.



              And this is the second thing that is tricky. All of the online how-to's said I should forward port 1883 to the local IP address of my Linux Server, which in my case was 192.168.0.144. But that was not correct in my case. The Archer C1200 was actually the device that I needed to forward to -- it handled the correct distribution from there. It had an address of 192.168.0.152 assigned to it from the Verizon router. I still have both forwardings in place (ie the Fios and the tp-link) and my guess is that I need them both.



              Now all pathways are open, you can follow the other Mosquitto instructions regarding logging, config files, Daemons, etc.



              Hope this saves someone some time down the road!






              share|improve this answer




























                1














                I'm posting this as an answer so I can give more detail in case anyone stumbles upon this in the future.



                Setting up the MOSQUITTO MQTT Server in Ubuntu 18.04 is actually not hard, but the steps are important.



                Step 1: Install Mosquitto Software



                sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
                sudo apt-get update
                sudo apt-get install mosquitto


                Step 2: Open Port 1883 and start firewall



                sudo ufw allow 1883 
                sudo ufw enable


                Step 3: Verify Mosquitto is not already running



                pgrep mosquitto


                [Note, if any number shows, that is the PID of an already running Mosquitto. You can just kill it. Also, you can try: sudo service mosquitto stop]



                Step 4: Start Mosquitto with verbose option



                mosquitto -v


                [Note: This starts Mosquitto without using any config file. It echos connection and status information to the screen. Easiest for quick debugging.]



                Step 5: Check connectivity using local host



                Go to your client machine (in my case a Windows 10 laptop) and run the MQTT client, connecting to the local address of the Linux Mosquitto server (in my case 192.168.0.144). You should be able to connect. In fact, you can do this step before you even open the firewall, since this is all on the local network, the firewall rules are irrelevant at this point. Until next step which is...



                Step 6: Check Connectivity using web tool



                use either: www.yougetsignal.com/tools/open-ports/ or
                https://canyouseeme.org/



                [NOTE: You will not get an OPEN state UNLESS THE MOSQUITTO BROKER IS RUNNING]



                Step 7: If Port Shows Closed When coming In from Internet (ie not localhost)



                Here's where I got tripped up. In my case, I have a Verizon Modem that ALSO has a firewall (because it has a router). I have my own wireless router, a tp-link Archer C1200, that I have plugged into the Fios Modem/Router. I started by putting the port forwarding in the tp-link. But that firewall comes after the Fios firewall so I needed to go to the first wall and do the port forward there.



                And this is the second thing that is tricky. All of the online how-to's said I should forward port 1883 to the local IP address of my Linux Server, which in my case was 192.168.0.144. But that was not correct in my case. The Archer C1200 was actually the device that I needed to forward to -- it handled the correct distribution from there. It had an address of 192.168.0.152 assigned to it from the Verizon router. I still have both forwardings in place (ie the Fios and the tp-link) and my guess is that I need them both.



                Now all pathways are open, you can follow the other Mosquitto instructions regarding logging, config files, Daemons, etc.



                Hope this saves someone some time down the road!






                share|improve this answer


























                  1












                  1








                  1







                  I'm posting this as an answer so I can give more detail in case anyone stumbles upon this in the future.



                  Setting up the MOSQUITTO MQTT Server in Ubuntu 18.04 is actually not hard, but the steps are important.



                  Step 1: Install Mosquitto Software



                  sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
                  sudo apt-get update
                  sudo apt-get install mosquitto


                  Step 2: Open Port 1883 and start firewall



                  sudo ufw allow 1883 
                  sudo ufw enable


                  Step 3: Verify Mosquitto is not already running



                  pgrep mosquitto


                  [Note, if any number shows, that is the PID of an already running Mosquitto. You can just kill it. Also, you can try: sudo service mosquitto stop]



                  Step 4: Start Mosquitto with verbose option



                  mosquitto -v


                  [Note: This starts Mosquitto without using any config file. It echos connection and status information to the screen. Easiest for quick debugging.]



                  Step 5: Check connectivity using local host



                  Go to your client machine (in my case a Windows 10 laptop) and run the MQTT client, connecting to the local address of the Linux Mosquitto server (in my case 192.168.0.144). You should be able to connect. In fact, you can do this step before you even open the firewall, since this is all on the local network, the firewall rules are irrelevant at this point. Until next step which is...



                  Step 6: Check Connectivity using web tool



                  use either: www.yougetsignal.com/tools/open-ports/ or
                  https://canyouseeme.org/



                  [NOTE: You will not get an OPEN state UNLESS THE MOSQUITTO BROKER IS RUNNING]



                  Step 7: If Port Shows Closed When coming In from Internet (ie not localhost)



                  Here's where I got tripped up. In my case, I have a Verizon Modem that ALSO has a firewall (because it has a router). I have my own wireless router, a tp-link Archer C1200, that I have plugged into the Fios Modem/Router. I started by putting the port forwarding in the tp-link. But that firewall comes after the Fios firewall so I needed to go to the first wall and do the port forward there.



                  And this is the second thing that is tricky. All of the online how-to's said I should forward port 1883 to the local IP address of my Linux Server, which in my case was 192.168.0.144. But that was not correct in my case. The Archer C1200 was actually the device that I needed to forward to -- it handled the correct distribution from there. It had an address of 192.168.0.152 assigned to it from the Verizon router. I still have both forwardings in place (ie the Fios and the tp-link) and my guess is that I need them both.



                  Now all pathways are open, you can follow the other Mosquitto instructions regarding logging, config files, Daemons, etc.



                  Hope this saves someone some time down the road!






                  share|improve this answer













                  I'm posting this as an answer so I can give more detail in case anyone stumbles upon this in the future.



                  Setting up the MOSQUITTO MQTT Server in Ubuntu 18.04 is actually not hard, but the steps are important.



                  Step 1: Install Mosquitto Software



                  sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
                  sudo apt-get update
                  sudo apt-get install mosquitto


                  Step 2: Open Port 1883 and start firewall



                  sudo ufw allow 1883 
                  sudo ufw enable


                  Step 3: Verify Mosquitto is not already running



                  pgrep mosquitto


                  [Note, if any number shows, that is the PID of an already running Mosquitto. You can just kill it. Also, you can try: sudo service mosquitto stop]



                  Step 4: Start Mosquitto with verbose option



                  mosquitto -v


                  [Note: This starts Mosquitto without using any config file. It echos connection and status information to the screen. Easiest for quick debugging.]



                  Step 5: Check connectivity using local host



                  Go to your client machine (in my case a Windows 10 laptop) and run the MQTT client, connecting to the local address of the Linux Mosquitto server (in my case 192.168.0.144). You should be able to connect. In fact, you can do this step before you even open the firewall, since this is all on the local network, the firewall rules are irrelevant at this point. Until next step which is...



                  Step 6: Check Connectivity using web tool



                  use either: www.yougetsignal.com/tools/open-ports/ or
                  https://canyouseeme.org/



                  [NOTE: You will not get an OPEN state UNLESS THE MOSQUITTO BROKER IS RUNNING]



                  Step 7: If Port Shows Closed When coming In from Internet (ie not localhost)



                  Here's where I got tripped up. In my case, I have a Verizon Modem that ALSO has a firewall (because it has a router). I have my own wireless router, a tp-link Archer C1200, that I have plugged into the Fios Modem/Router. I started by putting the port forwarding in the tp-link. But that firewall comes after the Fios firewall so I needed to go to the first wall and do the port forward there.



                  And this is the second thing that is tricky. All of the online how-to's said I should forward port 1883 to the local IP address of my Linux Server, which in my case was 192.168.0.144. But that was not correct in my case. The Archer C1200 was actually the device that I needed to forward to -- it handled the correct distribution from there. It had an address of 192.168.0.152 assigned to it from the Verizon router. I still have both forwardings in place (ie the Fios and the tp-link) and my guess is that I need them both.



                  Now all pathways are open, you can follow the other Mosquitto instructions regarding logging, config files, Daemons, etc.



                  Hope this saves someone some time down the road!







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Feb 27 at 20:14









                  MarkJoel60MarkJoel60

                  153




                  153






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Ask Ubuntu!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1121524%2fmosquito-server-refuses-connections-ubuntu-18-04%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                      Mangá

                       ⁒  ․,‪⁊‑⁙ ⁖, ⁇‒※‌, †,⁖‗‌⁝    ‾‸⁘,‖⁔⁣,⁂‾
”‑,‥–,‬ ,⁀‹⁋‴⁑ ‒ ,‴⁋”‼ ⁨,‷⁔„ ‰′,‐‚ ‥‡‎“‷⁃⁨⁅⁣,⁔
⁇‘⁔⁡⁏⁌⁡‿‶‏⁨ ⁣⁕⁖⁨⁩⁥‽⁀  ‴‬⁜‟ ⁃‣‧⁕‮ …‍⁨‴ ⁩,⁚⁖‫ ,‵ ⁀,‮⁝‣‣ ⁑  ⁂– ․, ‾‽ ‏⁁“⁗‸ ‾… ‹‡⁌⁎‸‘ ‡⁏⁌‪ ‵⁛ ‎⁨ ―⁦⁤⁄⁕