Firewall blocking multicast traffic despite rule to the contrary
-
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.
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.
-
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?
-
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.
-
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.
-
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.
-
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..
-
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.
-
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
-
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.
-
Bringing back an old thread, but just wanted to say that you definitely do need to comment out the lines in filter.inc to get talk talk TV working with the IGMP proxy. Just spent a frustrating evening trying to get it to work until I found this thread.
