Filtering bridge and multicast - solved
-
Hi,
I have a following pfsense config:
WAN(123.123.123.0/24)–--pfsense----DMZ(bridged to WAN)----server(123.123.123.10)
|
LAN(192.168.1.0/24)I would like to have iptv availability for the server, but igmp requests don't seem to reach WAN from DMZ. Is multicast supposed to work with filtering bridge?
-
It might if you have firewall rules specifically set to allow that traffic, or perhaps an allow all rule (proto any from any to any)
I know DHCP will traverse a bridge, but you need to specifically allow it from any to any on its related ports.
-
It might if you have firewall rules specifically set to allow that traffic, or perhaps an allow all rule (proto any from any to any)
I know DHCP will traverse a bridge, but you need to specifically allow it from any to any on its related ports.
Well actually i seem to get some IGMP V2 Membership Queries from WAN through the bridge, when i run wireshark on the server. So IGMP from WAN->DMZ seems to be working on some level. I don't understand, why it shouldn't work the other way around as i have a simple allow all rule on DMZ.
I have tested this with allow any protocol and port from any to any rule on WAN and DMZ and didn't get the iptv stream working. So the firewall shouldn't be a problem, unless there is a some kind of hardcoded blocking rule for this.
Could it simply be a routing issue or something?No, it can't be, because client's routing table doesn't change regarding if it's behind the bridge or not. And bridge itself shouldn't mess with routing. -
The problem persists, but I found the reason.
When VLC generates an IGMPv2 packet, it has a router alert option (http://www.rfc-archive.org/getrfc.php?rfc=2113) enabled in the internet protocol header. This is why the packet won't go through pfsense's bridge. I tested this with Nemesis without the router alert option and the IGMPv2 packets passed the bridge perfectly. Also my iptv immediately started to work, when I injected an IGMPv2 packet without the router alert option to the multicast ip.
So the question remains, is this a bug or not?
-
Not a bug, it's by design of PF. http://www.openbsd.org/faq/pf/filter.html#ipopts
We have no way in the GUI to accommodate this. You can hack filter.inc as a work around. Feature request opened.
http://redmine.pfsense.org/issues/show/54 -
Actually it's already there in 2.0 now. You should be able to backport that piece of the code without too much trouble if you have any familiarity with PHP.
-
Thank you very much! Got it working now. I'll add the changes below, if someone is interested.
I made two firewall rules to allow igmp packets with ip options pass from my DMZ to WAN. In the rules fxp2 is my DMZ interface and fxp3 is WAN interface. I had to do a bit of testing before I found the right line to add my rules. The default WAN interface out rule will block the packets, if you add the WAN interface rule after it.
Here are my changes to filter.inc (added 3 lines):
# let out anything from the firewall host itself and decrypted IPsec traffic pass out quick on \$lan proto icmp keep state label "let out anything from firewall host itself" pass out quick on \$wan proto icmp keep state label "let out anything from firewall host itself" # Allow IGMP traffic with ip options from DMZ to WAN pass in quick on fxp2 inet proto igmp from any to 224.0.0.0/4 allow-opts keep state pass out quick on fxp3 inet proto igmp from any to 224.0.0.0/4 allow-opts keep state # tcp.closed 5 is a workaround for load balancing, squid and a few other issues. # ticket (FEN-857512) in centipede tracker. pass out quick on $wanif all keep state ( tcp.closed 5 ) label "let out anything from firewall host itself" -
Hmm… it's in my 1.2.2 as well. :-\