Firewall blocking multicast traffic despite rule to the contrary

Andrew453

Hi

I'm trying to get multicast IPTV working with my ISP, TalkTalk.

I've set up the igmpproxy correctly (I think), and I can see the multicast traffic coming through. However, the firewall is blocking it.

A typical entry in the firewall log is as follows:

Act Time If Source Destination Proto
X Apr 30 00:16:53 WAN 10.103.218.73 233.51.229.167:5000 UDP

The rule responsible for the block is:
@38(1000000113) block drop log quick inet proto tcp from any port = 0 to any

However, my WAN firewall rules include:

ID Proto Source Port Destination Port Gateway Queue Schedule Description
IPv4 * * * 224.0.0.0/4 * * none

The network 224.0.0.0/4 should include anything from 224.0.0.0 to 239.255.255.255, but the firewall is still blocking the traffic.

Even if I add an easy rule to pass the traffic, it's still blocked.

I note the "any port = 0" bit of the blocking rule, and the fact that the source address (10.103.218.73) doesn't have a port number. Is that the reason it's being blocked? If so, how do I pass this traffic please.

Many thanks,

Andrew

doktornotor

@Andrew453:

A typical entry in the firewall log is as follows:

Act Time If Source Destination Proto
X Apr 30 00:16:53 WAN 10.103.218.73 233.51.229.167:5000 UDP

The rule responsible for the block is:
@38(1000000113) block drop log quick inet proto tcp from any port = 0 to any

That does not make any sense. That rule is to block tcp, not UDP. How did you come up with that "responsible" rule?

Andrew453

It comes from pressing the red cross icon.

See the screenshot below.

Do you think I've found a bug in pfSense?

![2015-04-30 Problem firewalled traffic.jpg](/public/imported_attachments/1/2015-04-30 Problem firewalled traffic.jpg)
![2015-04-30 Problem firewalled traffic.jpg_thumb](/public/imported_attachments/1/2015-04-30 Problem firewalled traffic.jpg_thumb)

doktornotor

I think all the rules descriptions get useless in your case due to the infamous "wheeeeeeeeeeee lets log every IGMP packet" bug. Look at the raw log instead and see the rule number, just the first number after filterlog:. When you have that rule number , you should get the really matching rule by using something like


pfctl -vvsr | grep "^@###("

(Replace the ### with the rule number, obviously.)

Andrew453

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

doktornotor

Yeah. Now, as noted above:


pfctl -vvsr | grep "^@39("

Andrew453

I get the following:

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

doktornotor

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.

Andrew453

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?

doktornotor

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.

Andrew453

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?

Andrew453

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.

Andrew453

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.

doktornotor

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

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.

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.

doktornotor

@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.

Andrew453

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?

doktornotor

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.

Andrew453

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.

2chemlud

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.