Announcement

Collapse
No announcement yet.

mDNS (external)

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mDNS (external)

    Hello, I am just trying Untangle and I have all setup quite correctly and working.
    Since I use VLANs and I segregated IOT vs trusted LAN devices, I am having problems with my domotics devices not discovering from the controllers (on LAN) and the devices (on IOT).

    I know that Untangle does not implement a mDNS repeater (avahi like) and I don't have the info to set it in expert mode (if someone could send me a PM on this ).

    I could install on a separate ubuntu server an avahi daemon but I do not know how to give it "free" access to all VLANs to let it do his job.

    Any advice on this?
    Currently I can use an UBUNTU server virtualized on a phisical server connected to IOT....

    Thank you
    Chris

  • #2
    Ok I resolved!

    Comment


    • #3
      How please?

      Comment


      • #4
        I installed avahi in a separated VMM on the same phisical server where Untangle is installed (Synology NAS).

        Now I am trying to do the same with docker but I cannot have docker to see VLANs....

        Comment


        • #5
          Hi guys!

          Just figured this one out :-)

          In the end, Untangle runs Debian linux, so there just simple download the relevant avahi packages from the official Debian (buster) repo.

          Here are the two packages needed:
          (https)://packages.debian.org/buster/libavahi-core7
          (https)://packages.debian.org/buster/avahi-daemon

          SSH to your firewall.
          Download each package using wget.

          Install the first package:
          apt install ./libavahi-core7_0.7-4+b1_amd64.deb

          And the second one:
          apt install ./avahi-daemon_0.7-4+b1_amd64.deb

          Any dependencies will be downloaded from Untagles repo.

          Then, modify your /etc/avahi/avahi-daemon.conf:
          allow-interfaces=the interfaces you want to be able to Broadcast Boujour. Separate them by using (,) commas.
          example:
          allow-interfaces=eth1,eth2.20
          and then change enable-reflector to say yes
          enable-reflector=yes

          All done, now just restart the avahi-daemon:
          systemctl restart avahi-daemon.service
          Then do a status check:
          systemctl status avahi-daemon.service

          The output should look something like this:

          [root @ gw] /var/log # systemctl status avahi-daemon.service
          ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
          Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
          Active: active (running) since Wed 2021-02-10 11:12:45 CET; 17min ago
          Main PID: 452 (avahi-daemon)
          Status: "avahi-daemon 0.7 starting up."
          Tasks: 2
          Memory: 2.3M
          CGroup: /system.slice/avahi-daemon.service
          ├─452 avahi-daemon: running [gw.local]
          └─480 avahi-daemon: chroot helper

          Feb 10 11:14:32 gw.hemma avahi-daemon[452]: Registering new address record for 172.16.120.1 on eth2.20.IPv4.
          Feb 10 11:14:32 gw.hemma avahi-daemon[452]: Withdrawing address record for 172.16.120.1 on eth2.20.
          Feb 10 11:14:32 gw.hemma avahi-daemon[452]: Leaving mDNS multicast group on interface eth2.20.IPv4 with address 172.16.120.1.
          Feb 10 11:14:32 gw.hemma avahi-daemon[452]: Interface eth2.20.IPv4 no longer relevant for mDNS.
          Feb 10 11:14:32 gw.hemma avahi-daemon[452]: Joining mDNS multicast group on interface eth2.20.IPv4 with address 172.16.120.1.
          Feb 10 11:14:32 gw.hemma avahi-daemon[452]: New relevant interface eth2.20.IPv4 for mDNS.
          Feb 10 11:14:32 gw.hemma avahi-daemon[452]: Registering new address record for 172.16.120.1 on eth2.20.IPv4.
          Feb 10 11:14:32 gw.hemma avahi-daemon[452]: Withdrawing address record for fe80::4262:31ff:fe12:130f on eth2.20.
          Feb 10 11:14:32 gw.hemma avahi-daemon[452]: Leaving mDNS multicast group on interface eth2.20.IPv6 with address fe80::4262:31ff:fe12:130f.
          Feb 10 11:14:32 gw.hemma avahi-daemon[452]: Interface eth2.20.IPv6 no longer relevant for mDNS.

          Remember, to check your firewall logs, you may have to add allowance for destination port UDP 5353 for the relevant network/interface(s) depending on level of paranoia in your existing firewall rules. :-)

          /Stefan

          Comment


          • #6
            You know that will likely break again at the next Untangle upgrade, right?
            Five time Microsoft ASP.Net MVP managing a Lenovo RD330 / E5-2420 / 16GB with Untangle 16.5.2 to protect a 1Gbps fiber link for ~450 residential college students and associated staff and faculty

            Comment


            • #7
              Originally posted by jcoehoorn View Post
              You know that will likely break again at the next Untangle upgrade, right?
              I actually think it wont. :-)
              It's just two packages using Untangles own "distro" dependencies.
              This kind of packages will survive major upgrades on the OS -side. In case you didn't know, since we don't add a new repository, it's stand-alone packages, they will keep starting and be "linked-library-compatible"(ldd) for at least 7 years looking at Debian distro cycles.

              Worst and best case -thing that could happen would be that Untangle finally adds mdns "native"-support and could potentially collide with these two packages. At that point, just remove the two packages. :-)

              Untangle uses apt/repo -mechanics, no black magic really.

              Comment


              • #8
                Neither package is in the Untangle repository. We do not include all the libraries from Debian. Either way, since the package is installed via the command line is not supported. YMMV.

                [root @ gatewayhm] ~ # apt-cache show avahi-daemon
                N: Unable to locate package avahi-daemon
                E: No packages found
                [root @ gatewayhm] ~ # apt-cache show libavahi-core7
                N: Unable to locate package libavahi-core7
                E: No packages found
                Attention: Support and help on the Untangle Forums is provided by
                volunteers and community members like yourself.
                If you need Untangle support please call or email [email protected]

                Comment


                • #9
                  To update you would need to monitor for updates and wget the newer versions and install them manually. Keep copies of your config files too. Then check after any upgrades. Not really that hard.

                  And unless you have a commercial subscription working on the command line is no longer a threat. You don't have support anyway.

                  Comment


                  • #10
                    Originally posted by jcoffin View Post
                    Neither package is in the Untangle repository. We do not include all the libraries from Debian. Either way, since the package is installed via the command line is not supported. YMMV.

                    [root @ gatewayhm] ~ # apt-cache show avahi-daemon
                    N: Unable to locate package avahi-daemon
                    E: No packages found
                    [root @ gatewayhm] ~ # apt-cache show libavahi-core7
                    N: Unable to locate package libavahi-core7
                    E: No packages found
                    Well, actually what I said was the the two packages downloaded from Debian's official Buster repo gets their dependencies satisfied with the packages that are in your Untangle repo. :-)

                    You do perhaps realize that this rather pointless discussion wouldn't have to exists if you guys at Untangle invested some quality working hours in adding the features that your paying customers has been asking for... for many years... just sayin ;-)

                    So, instead of reminding your customers that if they want to fix your products short comings, they end up loosing their support, spend that time adding the features instead.

                    Personally, I'm only using Untangle at home, so it's no big deal should I my two downloaded packages cause any problems during an upgrade. I've been keeping servers alive for the past 30 years, so I'm not that worried even if you try to throw curve-balls at your customers during upgrades.

                    Untangle is a nice little firewall package, I like the graphs and the UI. And the apps-concept is also nice, however, I wouldn't consider deploying it commercially since most of the apps depends on Debian modules that you (Untangle) can't seem to patch when there are bugs, so in those scenarios the customer would have to wait for the Debian patch to trickle down to you. So, I'm not convinced that your way of packaging your "distro" is that well thought through. Sounds good on paper when you want to sell support, but in reality it comes up short. I would suggest you guys actually forking off from Debian and maintain your own proper distro so that you can patch it and allow users to contribute patches as well. Yes, it will cost more hours maintaining it, but you could harden the firewall so much better.

                    Enough ranting for this evening. Have an awesome morning sir! :-)

                    Comment


                    • #11
                      Originally posted by donhwyo View Post
                      To update you would need to monitor for updates and wget the newer versions and install them manually. Keep copies of your config files too. Then check after any upgrades. Not really that hard.

                      And unless you have a commercial subscription working on the command line is no longer a threat. You don't have support anyway.
                      I agree, however, lazy me uses ansible, so it's not that much to maintain. And there's no need to monitor for newer versions, only thing that could mess the "old"-ones up would be if Untangle's next version should have an upgrade, non-backward compatible libc -core-package. But, since Debian's distro's are basically always backward compatible linking-level (ldd), I can't remember when if I ever had that problem. But I appreciate your concern, thank you! :-)

                      Comment


                      • #12
                        Originally posted by datstma View Post
                        Well, actually what I said was the the two packages downloaded from Debian's official Buster repo gets their dependencies satisfied with the packages that are in your Untangle repo. :-)
                        You literally said it was from our repo which is incorrect as Untangle repo is a subset of Debian.
                        Originally posted by datstma View Post
                        It's just two packages using Untangles own "distro" dependencies
                        Originally posted by datstma View Post
                        You do perhaps realize that this rather pointless discussion wouldn't have to exists if you guys at Untangle invested some quality working hours in adding the features that your paying customers has been asking for... for many years... just sayin ;-)
                        We prioritize features implemented based on the greatest need. Everyone thinks their need should be a priority.
                        Last edited by jcoffin; 02-11-2021, 02:44 PM.
                        Attention: Support and help on the Untangle Forums is provided by
                        volunteers and community members like yourself.
                        If you need Untangle support please call or email [email protected]

                        Comment


                        • #13
                          Originally posted by jcoffin View Post
                          You literally said it was from our repo which is incorrect as Untangle repo is a subset of Debian.

                          We prioritize features implemented based on the greatest need. Everyone thinks their need should be a priority.
                          I realize, that you are trying to "win an argument". Please don't condescend your other customers needs in public, it's bad PR. Next time, say something like "we value your opinion and will take into consideration". And once again, read what I actually wrote, again... I wrote (as you quoted btw) "...packages using Untangles own "distro" dependencies". The word "literally" actually means that you interpreted it word for word, which you for some strange reason then decided not to do. The packages, i.e. the two downloaded ones, has dependencies. These dependencies are managed by the package manager called APT. When installing the two packages (that you downloaded) the package manager (APT) checks which dependencies the two packages has, it then checks with its own repository cache (i.e. Untangle's repo) and finds out that the dependencies can be satisfied by packages available in the Untangle repo. Yes, I'm over-explaining ;-)

                          Now, the "clever" response from you next should be -"we value your opinion and will take into consideration" ;-)

                          Cheers!

                          Comment


                          • #14
                            Actually I'm not trying to "win", I'm just clarifying for other forum readers that this is a mod and it may have upgrade issues in the future. Have a great weekend.
                            Attention: Support and help on the Untangle Forums is provided by
                            volunteers and community members like yourself.
                            If you need Untangle support please call or email [email protected]

                            Comment


                            • #15
                              Originally posted by jcoffin View Post
                              We prioritize features implemented based on the greatest need. Everyone thinks their need should be a priority.
                              The request for a mDNS reflector is currently the 4th highest ranked item in the Untangle NG Firewall Feature Requests List.

                              As of today, it has 566 votes. Many of the comments (mine included) are requesting the Untangle product management team to provide the community with a better response on both IF as well as WHEN this feature will be implemented as a supported feature. Currently, the tag is simply "Under Consideration", this is a non-answer. The request has been up since August 2018, how much longer do you need to "consider"?

                              Please ask your product management team to provide the community (minimally) with a "Date for a Date", meaning "a date when we will have a more definitive answer about IF and if so WHEN this feature is planned for inclusion in Untangle Firewall NG". If that's not possible at this time, how about a "date for a date for a date", you can see where I'm going.

                              Based on my own research before purchasing a Home Protect Basic license, as well as the specific comments on this feature request, your main competitors in this space all include support for an mDNS reflector:
                              - pfSense / OpnSense
                              - Sophos UTM
                              - Ubiquiti UDM / EdgeRouter / USG

                              This is a feature that is absolutely necessary for the seamless function of modern networks in many small/medium business as well as home use cases. Every day that passes, more and more IOT devices are being installed in our networks, ease of use is one of the many reasons why this is the case. mDNS is a big part of why these devices achieve the ease of use that is resulting in their market success.

                              That same ease of use is the reason why many of us have chosen to put Untangle NG Firewall at the center of our network security.

                              The fact remains that these IOT devices should be isolated in separate VLANS (which Untangle supports quite easily) except without the mDNS reflector service many of the key use cases for these devices are flat broken.

                              For your users that are unwilling to forego either the IOT devices entirely, or the ease-of-use that mDNS affords when used with these devices, we have three choices:
                              1. Abandon Untangle NG Home Protect entirely and switch to a competing platform that has prioritized support for an mDNS reflector, based on their customer need (which many of us also have, just look at your own feature request list).
                              2. The solution described in this thread: manually add the mDNS reflector service at the Untangle OS shell, in a manner that you correctly state is not supported by Untangle. That said, many of your Home Protect Basic users don't have direct support from Untangle as that is a non-trivial additional expense.
                              3. Run the mDNS reflector externally from Untangle in a VM or on a lightweight appliance such as a rPI.

                              For option 1, you've lost a customer (you are already driving away potential customers to other solutions by not supporting this feature).
                              For options 2 and 3, your users end up taking on an additional setup and maintenance burden that we don't have with competing solutions.

                              So, how about it, can the Untangle Product Management team please give the community more feedback on this highly requested (and highly needed) feature other than "under consideration" and "we prioritize features on the greatest need".

                              I'm a relatively new customer (just a few months), this is my first forum post, I love Untangle, it has been rock solid and I've barely scratched the surface of what it can do. I'm in the process of implementing VLANS, which is the reason why I searched for this solution, so I can continue using my AppleTV, HomeKit, ChromeCast and other IOT devices seamlessly as well as securely.

                              Comment

                              Working...
                              X
                              😀
                              🥰
                              🤢
                              😎
                              😡
                              👍
                              👎