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

    Multicasts port 5353, 224.0.0.251, unblockable!

    Scheduled Pinned Locked Moved Firewalling
    18 Posts 5 Posters 9.9k Views
    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.
    • F
      fishy
      last edited by

      Hello,

      I have two networks, 192.168.1.0/24 and 192.168.100.0/24. The router and firewall is ofcourse pfsense between these networks. On my 192.168.1.0/24 I have a machine that multicasts mDNS that for some traverse into the 192.168.100.0/24 network, something I dont want. I have been blocking UDP port 5353 on the WAN interface and Floating interface (!) and still the damn packets come though. I have also blocked 224.0.0.251 IP that is the multicastadress it uses.

      Anyone have any idea how I can block this kind of traffic?

      1 Reply Last reply Reply Quote 0
      • D
        doktornotor Banned
        last edited by

        Dude. You block traffic where it first hits the firewall. If you get a traffic from 192.168.1.0/24, you block it on that interface, NOT on WAN. WTF.

        1 Reply Last reply Reply Quote 0
        • F
          fishy
          last edited by

          @doktornotor:

          Dude. You block traffic where it first hits the firewall. If you get a traffic from 192.168.1.0/24, you block it on that interface, NOT on WAN. WTF.

          Well, it hits the WAN interface first. Its a lab env. But I think it should block it if I put the rule on Floating?

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by

            I'm not going to waste time guessing what are your networks set up like. Post info here. (Firewall logs, firewall rules, network setup).

            1 Reply Last reply Reply Quote 0
            • KOMK
              KOM
              last edited by

              You didn't specify, but we're to assume that 192.168.1.0/24 is your WAN net and 192.168.100.0/24 is your LAN?

              1 Reply Last reply Reply Quote 0
              • F
                fishy
                last edited by

                @KOM:

                You didn't specify, but we're to assume that 192.168.1.0/24 is your WAN net and 192.168.100.0/24 is your LAN?

                192.168.1.0 is my WAN and 192.168.100.0 is my LAN.

                1 Reply Last reply Reply Quote 0
                • KOMK
                  KOM
                  last edited by

                  Please post a screenshot of your WAN rules.

                  1 Reply Last reply Reply Quote 0
                  • F
                    fishy
                    last edited by

                    here are the rules…

                    and a a wireshark sniff on the mDNS  traffic.

                    My network looks like this

                     labnetwork          +---------------------+            imaginary WAN. :)
                                         |                     |
                                         |                     |
                    +--------------+     |    pfsense with two |     +----------------------+
                    |              |     |    interfaces.      |     |                      |
                    |  192.168.100.0/24  |                     |     |      192.168.1.0/24  |
                    |  LAN         |     |                     |     |      WAN             |
                    +--------------+     |                     |     +----------------------+
                                         |                     |
                                         |                     |
                                         |                     |
                                         |                     |
                                         +---------------------+
                    
                    

                    fwruleswan.jpg
                    fwruleswan.jpg_thumb
                    wireshark-mdns.jpg
                    wireshark-mdns.jpg_thumb

                    1 Reply Last reply Reply Quote 0
                    • KOMK
                      KOM
                      last edited by

                      Where is your trace coming from, WAN or LAN?  I have no idea why it's acting this way.  Lots of other users complaining about those packets being blocked when they actually want them.

                      1 Reply Last reply Reply Quote 0
                      • F
                        fishy
                        last edited by

                        @KOM:

                        Where is your trace coming from, WAN or LAN?  I have no idea why it's acting this way.  Lots of other users complaining about those packets being blocked when they actually want them.

                        I should said they come from a client on the 192.168.100.0/24 network. :) I have tried all kind of ACL, and I dont manage to block the mDNS traffic. Other traffic works as it should. Its just a lab env so I might install a new pfsense fw and see of its somekind of configuration issue.

                        1 Reply Last reply Reply Quote 0
                        • D
                          doktornotor Banned
                          last edited by

                          @fishy:

                          I should said they come from a client on the 192.168.100.0/24 network. :)

                          OMG. Which part of "you must block where the traffic comes from" is unclear? Put the blocking on LAN, not WAN!!!

                          1 Reply Last reply Reply Quote 0
                          • KOMK
                            KOM
                            last edited by

                            It's very hard to diagnose and fix a problem when you provide incorrect details.  Knowing your WAN from your LAN is kind of important to get right.

                            1 Reply Last reply Reply Quote 0
                            • D
                              doktornotor Banned
                              last edited by

                              Yeah. For starters, why don't you just MOVE whatever to a completely different space? Why don't you use 10.x.x.x. or 172.16.x.x on one or the other to make it much more clear?

                              As a side note: hope you did not install shit like Avahi on your pfSense. That will reflect those mDNS multicasts among different networks by default and by design.

                              1 Reply Last reply Reply Quote 0
                              • F
                                fishy
                                last edited by

                                @doktornotor:

                                @fishy:

                                I should said they come from a client on the 192.168.100.0/24 network. :)

                                OMG. Which part of "you must block where the traffic comes from" is unclear? Put the blocking on LAN, not WAN!!!

                                I have had the blocking on WAN and LAN and Floating. Still is the traffic mDNS traffic comming trough the interfaces.

                                I have not changed network address space yet. My WAN is on a private address space. :)

                                No Avahi  on pfsense. But it is Avahi  from my mediaplayer that seend out these requests.

                                1 Reply Last reply Reply Quote 0
                                • F
                                  fishy
                                  last edited by

                                  I see the mDNS traffic on both the LAN and WAN interface if I do a packet capture in pfsense. But its not seen in the webinterface, even if I make a rule that should log mDNS traffic.

                                  Blocking 224.0.0.251, and even 224.0.0.0/6, UDP port 5353 and the source adress of the mDNS server!!

                                  1 Reply Last reply Reply Quote 0
                                  • D
                                    David_W
                                    last edited by

                                    Is it possible that you have IGMP snooping misconfigured on your switch, or a switch with a defective IGMP snooping implementation? It might be that pfSense has nothing to do with this.

                                    I hope you are running LAN and WAN on separate VLANs or separate switches, otherwise you have a single broadcast domain for both networks.

                                    1 Reply Last reply Reply Quote 0
                                    • F
                                      fishy
                                      last edited by

                                      I change to class b network. 172.16.199.0/16 and still getting mDNS packet…

                                      1 Reply Last reply Reply Quote 0
                                      • johnpozJ
                                        johnpoz LAYER 8 Global Moderator
                                        last edited by

                                        "and still the damn packets come though."

                                        Sorry but multicast is not going to pass through pfsense..  And it sure and the F is not going to come from wan to lan..  So clearly you have your wan and lan connected at layer2.. multicast is not going to route through pfsense..

                                        So how exactly do you have pfsense connect to what on its lan and wan?

                                        An intelligent man is sometimes forced to be drunk to spend time with his fools
                                        If you get confused: Listen to the Music Play
                                        Please don't Chat/PM me for help, unless mod related
                                        SG-4860 24.11 | Lab VMs 2.8, 24.11

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