Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Support
  3. "Special" treatment of port 53 does not work in all cases

"Special" treatment of port 53 does not work in all cases

Scheduled Pinned Locked Moved Solved Support
6 Posts 2 Posters 1.1k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R Offline
      R Offline
      Robin
      wrote on last edited by
      #1

      I tried installing AdGuard Home to give it a try. However, I noticed that I wasn't getting any responses to DNS queries I was throwing at the Cloudron machine. I connected in through ssh, and checked netstat -anlp, and saw that port 53 was only bound on one of the two interfaces that machine has.

      I went digging, and found that src/docker.js treats port 53 in a special manner (see getLowerUpIp). This doesn't work for my specific case, where I have two interfaces, and one of those interfaces is for a special internal-only purpose and doesn't really have any external network access.

      I'm not sure how this could best be resolved. I guess the easy solution might be to bind to all external interfaces, rather than just the first?

      girishG 2 Replies Last reply
      0
      • R Robin

        I tried installing AdGuard Home to give it a try. However, I noticed that I wasn't getting any responses to DNS queries I was throwing at the Cloudron machine. I connected in through ssh, and checked netstat -anlp, and saw that port 53 was only bound on one of the two interfaces that machine has.

        I went digging, and found that src/docker.js treats port 53 in a special manner (see getLowerUpIp). This doesn't work for my specific case, where I have two interfaces, and one of those interfaces is for a special internal-only purpose and doesn't really have any external network access.

        I'm not sure how this could best be resolved. I guess the easy solution might be to bind to all external interfaces, rather than just the first?

        girishG Offline
        girishG Offline
        girish
        Staff
        wrote on last edited by
        #2

        @robin would it work for you if I made it bind to all the IPv4 interfaces (other than loopback)?

        We have to figure a way to filter out all the internal docker interfaces and bridges.

        You can quickly check this like below on your server:

        $ node
        Welcome to Node.js v14.15.4.
        Type ".help" for more information.
        > os.networkInterfaces()
        
        R 1 Reply Last reply
        0
        • R Robin

          I tried installing AdGuard Home to give it a try. However, I noticed that I wasn't getting any responses to DNS queries I was throwing at the Cloudron machine. I connected in through ssh, and checked netstat -anlp, and saw that port 53 was only bound on one of the two interfaces that machine has.

          I went digging, and found that src/docker.js treats port 53 in a special manner (see getLowerUpIp). This doesn't work for my specific case, where I have two interfaces, and one of those interfaces is for a special internal-only purpose and doesn't really have any external network access.

          I'm not sure how this could best be resolved. I guess the easy solution might be to bind to all external interfaces, rather than just the first?

          girishG Offline
          girishG Offline
          girish
          Staff
          wrote on last edited by
          #3

          @robin Ideally, I would want to bind to 0.0.0.0 but we can't because there is an internal DNS server on port 53. The code then needs a way to bind explicitly to the "external" interfaces of the server.

          Looks like we can:

          • ls -l /sys/class/net/ | grep -v virtual and this lists potential interfaces
          • ip link show - this shows even the virtual interfaces. not sure how i can filter them out . there is ip link show type but cannot find a suitable type option to use
          1 Reply Last reply
          0
          • girishG girish

            @robin would it work for you if I made it bind to all the IPv4 interfaces (other than loopback)?

            We have to figure a way to filter out all the internal docker interfaces and bridges.

            You can quickly check this like below on your server:

            $ node
            Welcome to Node.js v14.15.4.
            Type ".help" for more information.
            > os.networkInterfaces()
            
            R Offline
            R Offline
            Robin
            wrote on last edited by
            #4

            @girish Yeah, binding to all interfaces would work for me. And I think it's reasonable enough to assume that Cloudron can "own" any interfaces it is given access to, just like a 0.0.0.0 bind would normally, so that seems fine...

            Some searching finds me this, which looks potentially useful:

            https://serverfault.com/questions/1019363/using-ip-address-show-type-to-display-physical-network-interface

            The one liner given there (with jq) does indeed report only the two physical interfaces I have:

            # ip -details -json link show | jq -r '
            > .[] | 
            >       if .linkinfo.info_kind // .link_type == "loopback" then
            >           empty
            >       else
            >           .ifname
            >       end
            > '
            enp1s0
            enp2s0
            
            girishG 1 Reply Last reply
            0
            • R Robin

              @girish Yeah, binding to all interfaces would work for me. And I think it's reasonable enough to assume that Cloudron can "own" any interfaces it is given access to, just like a 0.0.0.0 bind would normally, so that seems fine...

              Some searching finds me this, which looks potentially useful:

              https://serverfault.com/questions/1019363/using-ip-address-show-type-to-display-physical-network-interface

              The one liner given there (with jq) does indeed report only the two physical interfaces I have:

              # ip -details -json link show | jq -r '
              > .[] | 
              >       if .linkinfo.info_kind // .link_type == "loopback" then
              >           empty
              >       else
              >           .ifname
              >       end
              > '
              enp1s0
              enp2s0
              
              girishG Offline
              girishG Offline
              girish
              Staff
              wrote on last edited by
              #5

              @robin thanks, I have fixed it here -https://git.cloudron.io/cloudron/box/-/commit/1e665b63234ba7cfdfd6d16679a2261418c7449c . It will be in the next release.

              R 1 Reply Last reply
              1
              • girishG girish

                @robin thanks, I have fixed it here -https://git.cloudron.io/cloudron/box/-/commit/1e665b63234ba7cfdfd6d16679a2261418c7449c . It will be in the next release.

                R Offline
                R Offline
                Robin
                wrote on last edited by
                #6

                @girish I patched my docker.js manually, and I can confirm that port 53 is now exposed on all interfaces, as I would expect! Thanks!

                1 Reply Last reply
                1
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                  • Login

                  • Don't have an account? Register

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • Bookmarks
                  • Search