Read that part more clearly, the important part is "As with". Those firewall rules are regarding setting up udpxy instead of igmpproxy, and the rule they have in common is that they both need to accept IGMP traffic via an INPUT rule, hence the "As with". This program does actually proxy the multicast traffic, since it transforms it into a unicast TCP connection, which means an udp INPUT rule is also required.
From the Wiki:
Above part is actually about igmpproxy and does actually use a FORWARD rule for the udp traffic to the LAN zone as you can also see.
Regarding igmp_snooping, I do have that enabled on my LAN bridge, since without it wireless performance is killed as expected. I enabled it via the igmp_snooping option in my network config file in case that matters.
I'm still extremely confused how my setup won't work with an INPUT rule, but does work with a FORWARD rule. Yet you have the exact opposite.
I am in the same boat, hence I do not use the UDP proxy either.
Ahhhh, now we might be getting somewhere. So igmp_snooping is something else than multicast_snooping? I thought they were different words for the same thing. I will have to do some reading to educate myself and hopefully tomorrow I can run some tests to fully understand how everything works
I am looking for more detailed information on this, as most are non-Linux manuals...
Only the OpenWRT wiki clearly defines these as different configs (and how to access them)...but here's the thing...if someone uses option igmp_snooping 1 and it disables "multicast_snooping" on bridges...if it were the same thing, you'd never enable IGMP Snooping.
I should also note, I don't need IGMP Snooping, as only one device (a downstream router with igmpproxy also enabled) is normally connected to the network2 Interface.
I agree, I may add a Wireless device to test that Multicast UDP is not on the WiFi portion of the network.
The scenario that is described here:
you bridged multiple interfaces, 2 or more
No routing, nothing. You only have that bridge to connect your networks together.
with igmp snooping off:
multicast traffic gets delivered on all bridge ports (e.g. all bridged networks/interfaces)
with igmp snooping on:
each bridge port watches out for igmp memberships and only deliver the multicast streams on those bridge ports, which have active igmp memberships.
So actually it should work in both cases?
As i stated above in my post.
You are right and you need that udp multicast forward rule if forwarding is not allowed.
And that igmp input rule if input connections to that interface(or zone) is not allowed.
Maybe illeachii has something else configured that allows forward of the udp multicast streams.
Or igmpproxy init script is doing its job x)
btw good catch with the init script if it is really the case.
I guess only from downstream interface to the upstream interface, to signal the sender on the upstream interface, hey i want that multicast traffic.
From upstream to down stream it makes no sense.
Because the host(s) that wants multicast traffic has to join the igmp group on the downstream interface first.
Then igmpproxy joins the same group on the upstream interface.
Then it setups the needed multicast routes in the kernel, as you can see with ip mroute for example.
(that also proves forward rule is needed if forwarding is prohibited)
Maybe igmpproxy does rewrite the src ip of the multicast packets so for the clients it looks like the multicast traffic originates from the router (or downstream interface).
I wont put the iptv interface into the wan zone.
Because in a default setup forwarding from lan to wan is allowed.
I know i made this suggestion earlier also to allow forwarding to the iptv zone.
But when i think about it
It is better to create a separate zone for iptv and dont allow forward by default in either direction.
And setup firewall rules accordingly.
Didnt you test quickleave 0 before and it didnt change anything?
1 forwarding_wan_rule all -- anywhere anywhere /* !fw3: user chain for forwarding /
2 zone_network2_dest_ACCEPT udp -- anywhere base-address.mcast.net/4 / !fw3: ubus:igmpproxy[instance1] rule 1 */
root@LEDE:~# iptables -D zone_wan_forward 2
It still works.
I also tested removing my TTL rule and the final TTL DROP...thereby only using the IGMPProxy-created FORWARD rule...it doesn't work - no FW hits
I've added my own FORWARD rule...it doesn't work...again, no FW hits
(These things originally prompted me to try the INPUT rule.)
I entered a normal INPUT rule...it works.
And I wouldn't expect such a FORWARD rule to work, as there's no route (as I noted, the route rule on the Wiki would only allow multicasting to the specified network, not ANY NETWORK...and my network is not numbered 22.214.171.124/4, in addition, it's masqueraded to WAN.
Same results whether IGMP snooping was on or off:
root@LEDE:~# vi /sys/devices/virtual/net/br-lan/bridge/multicast_snooping
This seems to be so.
I'm not sure, I've only done packet captures mirroring the WAN. The SRC of the downstream packets were always an IP Globally assigned to my ISP...the destination was always a multicast IP address - as it should be.
This will forward all multicast packets to all ports on your bridge, making igmpproxy or udpxy unnecessary.
I believe that the manual (and igmpproxy's FW3 scripts) improperly tells us to make a route to 126.96.36.199/4 at the desired Interface; and then make a FORWARD rule to ACCEPT UDP traffic to it. I don't believe this is correct - it seems to be a workaround; and would defeat the need for an IGMP proxying software.
If i understand correctly igmpproxy listens for igmp requests and forwards them upstream so the ISP knows to send multicast packets to the router. To do this it needs to accept igmp packets as input on lan and wan. then it sets up a route so when a multicast packet hits the wan interface it will be sent out over the lan interface if an igmp request Had Previously been received to subscribe from lan. To do that you need a firewall rule allowing forward for packets with multicast dst.
The confusion is regarding the fact that I need a FORWARD rule for the UDP multicast traffic in order to be able to watch IPTV, while @lleachii requires an INPUT rule to do the same. Since I don't fully understand why this is the case, it simply means that I do not fully understand how this stuff works. And so that's why I would like to learn more about this
@lleachii mind posting your full configuration as well so we can get to the bottom of this?
To get back to this: Isn't that asterisk (*) included in the line the destination interface? Because that would also make it a FORWARD rule. Sorry if that is a dumb idea, not really familiar with the syntax of those raw rules I assume the "all" is regarding the protocol, right?
Edit: multicast_snooping and igmp_snooping are, in fact, the same thing (unless they directly influence each other). Removing the option igmp_snooping 1 from my network config also results in:
However, the same behavior is observed when using an INPUT rule: IPTV plays for 1-2 seconds and then stops, the same behavior with igmp_snooping disabled. It's weird that it is able to play for a short while, but this is happening both with igmp_snooping disabled as enabled. Only way to fix it, is to go back to my FORWARD rule.
I 100% understand that, which is why I looked at the code...and found that it creates UDP sockets. Again, that would prove INPUT. Otherwise, why would IGMPProxy be making UDP sockets that relate to the requests in the IGMP packet???
I think we forget that the IGMP request expects UDP traffic in reply - that's the protocol, folks! Why would someone only write code to solve half the protocol???
In addition, the FORWARD rule only seems to work if users create a route to the desired network wanting multicast - for the control traffic. This was another warning.
RFC5771 (https://tools.ietf.org/html/rfc5771) states that the control block traffic is local, hence making a route for it is not best practice and likely dangerous...especially if the router only has Global IP address space on some or all interfaces (i.e. no NAT used).
Local Network Control Block (224.0.0/24)
Addresses in the Local Network Control Block are used for protocol
control traffic that is not forwarded off link. Examples of this
type of use include OSPFIGP All Routers (188.8.131.52) [RFC2328].
FORWARDING OFF-LINK FROM WAN TO LAN DEFINITELY BREAKS THIS.
I also see varions other router manuals: MicroTik, Cisco, Alpine Linux etc....few of them state a FORWARD rule is required...and if so, they add a routing rule.