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

    Firewall blocking multicast traffic despite rule to the contrary

    Scheduled Pinned Locked Moved Firewalling
    25 Posts 5 Posters 7.0k 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.
    • A
      Andrew453
      last edited by

      Thanks.  This is what it says in the raw logs:

      Apr 30 08:48:35 filterlog: 39,16777216,,1000000113,re0,match,block,in,4,0x80,,60,0,0,DF,17,udp,1356,10.103.218.73,233.51.229.167,0,5000,1336
      Apr 30 08:48:35 filterlog: 39,16777216,,1000000113,re0,match,block,in,4,0x80,,60,0,0,DF,17,udp,1356,10.103.218.73,233.51.229.167,0,5000,1336
      Apr 30 08:48:35 filterlog: 39,16777216,,1000000113,re0,match,block,in,4,0x80,,60,0,0,DF,17,udp,1356,10.103.218.73,233.51.229.167,0,5000,1336
      Apr 30 08:48:35 filterlog: 39,16777216,,1000000113,re0,match,block,in,4,0x80,,60,0,0,DF,17,udp,1356,10.103.218.73,233.51.229.167,0,5000,1336
      Apr 30 08:48:35 filterlog: 39,16777216,,1000000113,re0,match,block,in,4,0x80,,60,0,0,DF,17,udp,1356,10.103.218.73,233.51.229.167,0,5000,1336

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

        Yeah. Now, as noted above:

        
pfctl -vvsr | grep "^@39("
        1 Reply Last reply Reply Quote 0
        • A
          Andrew453
          last edited by

          I get the following:

          $ pfctl -vvsr | grep "^@39("
          @39(1000000113) block drop log quick inet proto udp from any port = 0 to any

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

            Yeah. This comes from this code:

            
# We use the mighty pf, we cannot be fooled.
block {$log['block']} quick inet proto { tcp, udp } from any port = 0 to any tracker {$increment_tracker($tracker)}
block {$log['block']} quick inet proto { tcp, udp } from any to any port = 0 tracker {$increment_tracker($tracker)}
block {$log['block']} quick inet6 proto { tcp, udp } from any port = 0 to any tracker {$increment_tracker($tracker)}
block {$log['block']} quick inet6 proto { tcp, udp } from any to any port = 0 tracker {$increment_tracker($tracker)}

            in /etc/inc/filter.inc - the mighty pf indeed cannot be fooled since there's no way to override these quick rules via the GUI. Sigh.

            All of this behind the scenes stuff should be at least optionally exposed in the GUI.

            1 Reply Last reply Reply Quote 0
            • A
              Andrew453
              last edited by

              Thanks. So why is it objecting to the traffic?  Is it because it's incoming on port 0?

              Is it possible to amend that rule from the command line?

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

                No, there's nothing to be done with that rule beyond patching the /etc/inc/filter.inc. Not really convinced that this UDP traffic is the cause of your IPTV issues, though. You can comment it out, run Status -> Filter Reload and see if it helps.

                1 Reply Last reply Reply Quote 0
                • A
                  Andrew453
                  last edited by

                  Thanks.  I commented it out.  Now it blocks under a different rule!

                  Apr 30 09:16:11 filterlog: 57,16777216,,1000001581,re0,match,block,in,4,0x80,,60,0,0,DF,17,udp,1356,10.103.218.73,233.51.229.167,0,5000,1336
                  Apr 30 09:16:11 filterlog: 57,16777216,,1000001581,re0,match,block,in,4,0x80,,60,0,0,DF,17,udp,1356,10.103.218.73,233.51.229.167,0,5000,1336
                  Apr 30 09:16:11 filterlog: 57,16777216,,1000001581,re0,match,block,in,4,0x80,,60,0,0,DF,17,udp,1356,10.103.218.73,233.51.229.167,0,5000,1336
                  Apr 30 09:16:11 filterlog: 57,16777216,,1000001581,re0,match,block,in,4,0x80,,60,0,0,DF,17,udp,1356,10.103.218.73,233.51.229.167,0,5000,1336

                  $ pfctl -vvsr | grep "^@57("
                  @57(1000001581) block drop in log quick on re0 inet from 10.0.0.0/8 to any label "Block private networks from WAN block 10/8"

                  Is that another rule that cannot be overridden from the GUI?

                  1 Reply Last reply Reply Quote 0
                  • A
                    Andrew453
                    last edited by

                    Sorry, yes it is.  It's the block private networks option.  I've unchecked that now, and the traffic seems to be being passed (it's not in the log anymore).

                    IPTV still not working though, so will look for other issues.

                    Thanks for your help.

                    1 Reply Last reply Reply Quote 0
                    • A
                      Andrew453
                      last edited by

                      Touch wood, it seems to be working now.  :)

                      There was also an issue on the networks defined in the IGMP proxy.

                      Thanks for your help.

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

                        So, what really fixed it? When you put the filter.inc into original state, does it still work with the bogons blocking disabled?

                        1 Reply Last reply Reply Quote 0
                        • A
                          Andrew453
                          last edited by

                          No, the "@39(1000000113) block drop log quick inet proto udp from any port = 0 to any" rule blocks the incoming traffic, presumably because it's on port 0.

                          I spoke too soon though:  the IPTV works for an amount of time (anything from 5 secs to a few minutes) then falls over.  There's a post here which details the same problem:  http://www.dslreports.com/forum/r28895644-TDS-IPTV-Service-using-PFSense-Configuration-Instructions

                          I'll have a play later on - the conclusion from that thread was that it's some sort of QoS issue.

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

                            @Andrew453:

                            No, the "@39(1000000113) block drop log quick inet proto udp from any port = 0 to any" rule blocks the incoming traffic, presumably because it's on port 0.

                            You might want to file a bug about this.

                            @Andrew453:

                            I spoke too soon though:  the IPTV works for an amount of time (anything from 5 secs to a few minutes) then falls over.  There's a post here which details the same problem:  http://www.dslreports.com/forum/r28895644-TDS-IPTV-Service-using-PFSense-Configuration-Instructions

                            That's a different thing, best kept out of this thread.

                            1 Reply Last reply Reply Quote 0
                            • A
                              Andrew453
                              last edited by

                              Thanks.  Re the rule, isn't it working correctly, it just's the incoming traffic (for whatever reason) doesn't specify a port?  i.e. something wrong with the traffic rather than being a bug in the rule?

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

                                No idea what kind of traffic you are really seeing blocked without packet sniffing. These invisible impossible to override/re-order rules are all evil.

                                1 Reply Last reply Reply Quote 0
                                • A
                                  Andrew453
                                  last edited by

                                  Thanks.  I suppose it's more of a feature request then?  i.e. allow all these default rules to be customised from the GUI, rather than by rooting around in the bowels of the system.

                                  Thanks for your help.

                                  1 Reply Last reply Reply Quote 0
                                  • 2
                                    2chemlud Banned
                                    last edited by

                                    Logging anything nobody wants (IGMP), blocking things by hidden rules (bogon etc pp.)…

                                    Is pfSense a firewall or a black box still called firewall?

                                    I would expect ABSOLUTE transparency and ABSOLUTE capability for the user to turn on/off features in a single place (firewall rules, nowhere else hidden somewhere in the GUI) if you call it SECURITY APPLIANCE.

                                    It's a mess, in my opinion.

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

                                      Yeah the hidden rules are not a good idea.  And the ability to turn them off or modify them should be an option.  Its kind of nice that if you enable dhcp server for example it auto puts in a rule.  But they should NOT be hidden!!  And for example while dhcp gets rules, if you just run relay it does not get rules so does not work unless you allow for that traffic.  So it can be confusing yes.

                                      And stuff like bogon and private with no way to put rules above them is not good..

                                      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.7.2, 24.11

                                      1 Reply Last reply Reply Quote 0
                                      • A
                                        Andrew453
                                        last edited by

                                        Thanks.  Re the IPTV failing after a few minutes, I traced this to the fact pfSense is running an out of date/buggy version of igmpproxy.

                                        If you update to the latest version, it works.

                                        See the thread here:  https://forum.pfsense.org/index.php?topic=93293.0

                                        I agree with the comments re the hidden rules.  I'll post a bug report/feature request (also for the igmpproxy update) when I have a moment.

                                        1 Reply Last reply Reply Quote 0
                                        • A
                                          Andrew453
                                          last edited by

                                          Thanks.  I've posted a bug here re allowing the default filter.inc rules to be overridden from the GUI.

                                          https://redmine.pfsense.org/issues/4673

                                          1 Reply Last reply Reply Quote 0
                                          • A
                                            Andrew453
                                            last edited by

                                            Hi.  Just to say the bug was rejected as not being a bug, presumably for the reason I pointed out earlier that the rule is working correctly and it's a feature of the traffic (no specified port) which accounts for it being blocked.

                                            I've re-filed it as a feature request - i.e. to be able to override these hidden rules from the GUI.

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