Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Avahi trying to broadcast on public interface?

    Scheduled Pinned Locked Moved pfSense Packages
    8 Posts 2 Posters 391 Views 3 Watching
    Loading More Posts
    • 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.
    • C Offline
      clearscreen
      last edited by clearscreen

      It seems that when the public interface is PPPOE, Avahi will automatically try to broadcast in said interface (which I can see if fortunately blocked by the Firewall rules).

      I believe this is because in /usr/local/etc/avahi/avahi-daemon.conf there's a configuration setting that makes Avahi automatically use point-to-point interfaces.

      allow-point-to-point=yes
      

      From the avahi-daemon docs:

      allow-point-to-point= Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will make use of interfaces with the POINTOPOINT flag set. This option defaults to "no" as it might make mDNS unreliable due to usually large latencies with such links and opens a potential security hole by allowing mDNS access from Internet connections. Use with care and YMMV!
      

      Is there any supported mechanism to prevent Avahi from using this interface? (beyond just trying to manually force that setting to "no")

      1 Reply Last reply Reply Quote 0
      • dennypageD Offline
        dennypage
        last edited by

        One thing, make sure that Interface Action is set to "Allow Interfaces "rather than "Deny Interfaces".

        Avahi does have some quirks that cause it to do unexpected things. One of these is a bug/feature that causes Avahi to send packets on all interfaces, even if the interface was not configured. I used to use a firewall rule to silently drop these.

        Assuming you are on a recent version (2.8.0+ or 25.07+), you can also switch to mDNS-Bridge which is purpose built for bridging and does not have the various quirks that Avahi does.

        C 1 Reply Last reply Reply Quote 0
        • C Offline
          clearscreen @dennypage
          last edited by

          Yeah it's in allow interfaces.

          I'm fairly convinced the issue is the allow-point-to-point setting because the feature description seems to align rather well with what I'm seeing.

          I'm on 24.11 (which shows at the latest stable) and it seems mDNS-Bridge isn't here for me yet. Is 25.03 a beta version?

          dennypageD 1 Reply Last reply Reply Quote 0
          • dennypageD Offline
            dennypage @clearscreen
            last edited by

            @clearscreen said in Avahi trying to broadcast on public interface?:

            I'm fairly convinced the issue is the allow-point-to-point setting because the feature description seems to align rather well with what I'm seeing.

            That setting just allows point-to-point interfaces to be used (selected). Is your WAN connection actually a point-to-point interface? Mine certainly isn't and I've seen the exact same behavior.

            I'm on 24.11 (which shows at the latest stable) and it seems mDNS-Bridge isn't here for me yet. Is 25.03 a beta version?

            mDNS-Bridge is a replacement for Avahi, and appears in the 2.8.0 release of pfSense, and the 25.07 version of pfSense Plus. pfSense 25.07 is currently in RC. pfSense 25.03 doesn't exist anymore (it's now 25.07).

            C 1 Reply Last reply Reply Quote 0
            • C Offline
              clearscreen @dennypage
              last edited by

              @dennypage said in Avahi trying to broadcast on public interface?:

              That setting just allows point-to-point interfaces to be used (selected). Is your WAN connection actually a point-to-point interface? Mine certainly isn't and I've seen the exact same behavior.

              Then, I'm not sure what'd cause Avahi to publish on the public interface. I just tried disabling this option through the config files and it certainly didn't change anything, so I rolled it back to what it was.

              My wan is a PPPOE connection to my ISP.

              The interface is shown in the allow list in Avahi but is not selected. Interface action is "Allow Interfaces".

              mDNS-Bridge is a replacement for Avahi, and appears in the 2.8.0 release of pfSense, and the 25.07 version of pfSense Plus. pfSense 25.07 is currently in RC. pfSense 25.03 doesn't exist anymore (it's now 25.07).

              I guess I might need to update or wait for this to be stable.

              Thanks!

              dennypageD 1 Reply Last reply Reply Quote 0
              • dennypageD Offline
                dennypage @clearscreen
                last edited by

                @clearscreen said in Avahi trying to broadcast on public interface?:

                Then, I'm not sure what'd cause Avahi to publish on the public interface.

                It stems from Avahi's use of a single socket bound to all interfaces, which leaves a lot of room for problems. mDNS-Bridge uses individual sockets bound to each configured interface which precludes these kind of issues.

                C 1 Reply Last reply Reply Quote 0
                • C Offline
                  clearscreen @dennypage
                  last edited by clearscreen

                  Ok so circling back to this, mDNS Bridge resolved my issue. Thanks for your help!

                  Interestingly enough, @dennypage , I was just looking at mdns-bridge source code, but only realized now you're the author 😄

                  I’m not very familiar with mDNS, but I’m thinking of trying to implement one-way reflection (blocking either queries or broadcasts in a single direction). My motivation is to limit the possibility untrusted devices will fingerprint my home network while allowing trusted subnets to see devices on less trusted subnets. Before I dive in, is there any technical reason this wouldn’t be feasible? Just want to understand if there’s a fundamental limitation and I figured I might as well ask you first.

                  dennypageD 1 Reply Last reply Reply Quote 0
                  • dennypageD Offline
                    dennypage @clearscreen
                    last edited by

                    @clearscreen said in Avahi trying to broadcast on public interface?:

                    I was just looking at mdns-bridge source code, but only realized now you're the author

                    Yes. I'm also the maintainer of the pfSense Avahi package, which is why I felt compelled to write mdns-bridge. 😊

                    I’m not very familiar with mDNS, but I’m thinking of trying to implement one-way reflection (blocking either queries or broadcasts in a single direction). My motivation is to limit fingerprinting of my home network while allowing trusted subnets to see devices on less trusted subnets. Before I dive in, is there any technical reason this wouldn’t be feasible? Just want to understand if there’s a fundamental limitation and I figured I might as well ask you first.

                    With mdns-bridge, you do not block queries or responses, but choose what mDNS names are shared by each network segment. Avahi uses a similar approach, but is limited to what in mdns-bridge terms would be a Global Allow filter list only.

                    mDNS-Bridge is designed to give you detailed control of what mDNS names each segment is allowed to export or import, but I recommend keeping things simple if possible. I recommend starting with a Global Allow filter list to limit the overall scope, and exploring from there as needed.

                    One thing to keep in mind, as noted in the mDNS-Bridge README filters that include hostnames are best used only in deny filters.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.