[SOLVED] IPTV, IGMPProxy and Firewall issues

Installing and Using OpenWrt Network and Wireless Configuration
41

Hmm...

I would try the following.

Search for your wan interface in /etc/config/network
(i guess ops device supports swconfig)

config switch_vlan
	option device 'switch0'  // may differ
	option vlan '3'  // may differ
	option vid '6'  // may differ (should be vlan 6?)
	option ports '4t 6t'  // may differ

Create the the following new vlan

config switch_vlan
	option device 'switch0'  // may differ
	option vlan '4'  // may differ
	option vid '4'  // Vlan id 4
	option ports '4t 6t'  // may differ.

caution: only alter the switch config if you know how to recover you device in the case you lose access.

Create the vlan 4 interface:
(Copy and pasted from OP x) )

config interface 'iptv'
	option proto 'dhcp'
	option ifname 'eth0.4'
	option classlessroute '1'
	option vendorid 'IPTV_RG'
	option defaultroute '0'
	option peerdns '0'
	option gateway '0'

config interface 'lan'
     ......
     option igmp_snooping '1'
     ......

config route
    option interface 'iptv'
    option target 'x.x.x.x/x'
    option gateway 'x.x.x.x'

Is this even needed? Why doesn't the isp dhcp server push the routes?
If someone could explain this to me please?
Actually i would try to remove option classlessroute, defaultroute, peerdns and gateway and then check what the the isp dhcp hands out?

firewall

config zone
	option name 'iptv'
	option output 'ACCEPT'
	option masq '1'
	option network 'wan'
	option family 'ipv4'
	option forward 'DROP'
	option input 'DROP'
	option mtu_fix '1'

config forwarding
	option dest 'iptv'
	option src 'lan'

igmpproxy

config igmpproxy
	option quickleave 1

config phyint
	option network iptv
	option direction upstream
	list altnet 0.0.0.0/0

config phyint
	option network lan
	option direction downstream

And let the igmp proxy init script create the firewall rules.
or if not wanted

config rule
        option src      iptv
        option proto    igmp
        option target   ACCEPT

config rule
        option src      iptv
        option dest     lan
        option proto    udp
        option dest_ip  224.0.0.0/4
        option target   ACCEPT
        option family   ipv4

Maybe increase the ttl by 1
/etc/firewall.user

/usr/sbin/iptables -t mangle -A PREROUTING -p udp -d 224.0.0.0/4 -i iptv -j TTL --ttl-inc 1

Also try to force igmp version 2
/etc/sysctl.conf

net.ipv4.conf.all.force_igmp_version=2

42

The OP has a working config...I'm so lost why you enter threads and suggest the OPs reconfigure thier devices...and finding issues not noted by the OP themselves (i.e. suggesting the OP alter TTLs when only you report this issue).

Regarding my statement...as in another thread you misinterpret my words. I clearly state that IGMP is upstream and UDP is downstream. You can try to confuse the OP if you wish. Using phrases like "interfaces on the router..." I fear you might then confuse the OP by suggesting IGMP snooping.

Lastly, you ask:

Please don't troll the OP. It's obviously not sensible that someone is pushing routes for multicast...it seems you don't grasp either protocol well - DHCP nor multicast/IGMP.

@Mushoz, if your config now works, consider marking the thread "[SOLVED]"... otherwise, we await when you are able to fruther test the slutter.

43

?
So OPs config is not working?
His last question was if he could bridge the x.4 vlan into his lan network.
But that sounds like a bad idea.

This is wrong?

The router needs to know the igmp memberships on both sides.
Downstream and upstream.
The only thing that needs to be "proxified" are the multicast streams.
Example:
Router with 2 interfaces/networks.
Lets call them interface/network A and interface/network B.
Host Y on network A wants to receive a multicast stream from network B.
Host Y sends his igmp join request
The router will take note of it and now has the info in his igmp membership table.
E.g. Host Y is member of multicast group "some multicast address here" on interface/network A.
Now we do the same for host X on network B.
E.g. Host X is member of the same multicast group as host Y on interface/network B.

When a multicast route for that multicast route is setup, the router will forward those multicast streams.

As you see there is no need to proxify the igmp messages from network a to network b.
Or im wrong here?
//edit
Okay i see what you mean...

igmpproxy is a simple multicast routing daemon which uses IGMP forward-
       ing to dynamically route	multicast traffic. Routing is done by defining
       an  "upstream"  interface on which the daemon act as a normal Multicast
       client, and one or more "downstream" interfaces that serves clients  on
       the  destination	 networks.

igmpproxy "act" as client on the upstream interface and thereby "mimics" clients from the downstream interface.
Yeah okay. From that point of view someone could say igmpproxy is "proxifing" igmp memberships.
But i think all what is does is:
make the kernel join the igmp group on the upstream interface according to the memberships on the downstream inteface.
And sets up the multicast routes accordingly.

So an input (igmp )and forward (udp multicast) firewall rule is right choice here.

Maybe i should ask more clearly?
Why add a manual route?

Whats wrong with igmp snooping?

44

The issue seems to be fixed by disabling quickleave :slight_smile: No more stuttering. A few things I have learned along the way.

IGMPProxy does two things:

  1. It acts as a proxy for IGMP messages (as the name already implies) by sending incoming upstream IGMP messages downstream and vice versa. Hence IGMPProxy is listening for these IGMP and thus an INPUT rule should be used for these.
  2. It adds the required multicast routes from upstream to downstream so that these multicast streams can be received on the IPTV devices. More importantly, igmpproxy itself does not listen to / proxy these multicast streams. Hence an INPUT rule is not correct for udp traffic with destination 224.0.0.0/4. This traffic should be handled by a FORWARD rule to the desired firewall zone. So the OpenWRT/Lede wiki is correct.

So why did my INPUT rule work when I was using a separate IPTV firewall zone and why is @lleachii's INPUT rule working?

  1. The init.d script for igmpproxy adds the required FORWARD rule automatically. You can view these rules via iptables --list
  2. This script also adds the required igmp INPUT rules automatically. Hence, setting up IGMPProxy on Lede/OpenWRT should require NO manual firewall configuration whatsoever. However, see my next point.

So why wasn't the automatically generated FORWARD rule saving the day when I was using the my iptv interface within the wan firewall zone?

  1. The init.d script for igmpproxy has a bug. It is using the config option network (which is an interface) for defining the source/destination (which is a firewall zone) in the FORWARD rule. Hence my earlier observation that the firewall zone needs an identical name as the interface for my iptv to work when I didn't add the FORWARD rule manually.
  2. I haven't worked with Openwrt/Lede's init.d scripts ever before, but it shouldn't be too hard to fix. Either a new zone option needs to be introduced in the config file that defines the upstream and downstream firewall zone, or the IMO cleaner solution, the interface defined with the network option should be used to automatically fetch the zone this interface is assigned to. The last bit is probably the hardest part to figure out. I will have a go at it and create a pull request if successful. If not, I will file a bug report.
  3. For reference: https://github.com/lede-project/source/blob/master/package/network/services/igmpproxy/files/igmpproxy.init

Some random other observations:

  1. Openwrt/Lede is using quite an ancient igmpproxy version from the old sourceforge repository. Some of the strange log entries @johnnysl and I were seeing should be fixed in the newer release. The project has moved to Github quite a while ago.
  2. I have created a Bug report for this issue as well: https://bugs.openwrt.org/index.php?do=details&task_id=1456
  3. Changing the makefile shouldn't be hard at all. Unfortunately, the patches would also need to be redone for the new source code, which would be outside the scope of my coding skills.

So how is my final working and more importantly stutter free setup?

  1. The iptv interface (eth0.4) is assigned to the wan firewall zone.
  2. Quickleave was disabled to fix the stuttering.
  3. The required FORWARD rule was added manually, since the bug prevents the rules from being generated automatically due to the interface name being iptv while the zone name is wan

Hopefully this is helpful information for other people as well. Marking the thread as solved now. Thanks to all who have helped me :slight_smile:

2 Likes
45

I'm glad you got it wokring...jus a few notes:

  • Some people keep stating to use a route, this is merely a work around. Multicast IPs are not normal SRC and DST addresses.
  • These go upstream, most people already allow INPUT on the LAN and OUTPUT on WAN by default, this is why I keep mentioning that you should not need a rule to allow IP Protocol No. 2 on the LAN.

If you want to call them "routes" that's cool too; but they are packets being sent to you, because you requested a subscription to them via an IGMP Packet. Again, a forward rule is only if you route...You should NEVER (manually) route 224.0.0.0/4! I fear you have put in a workaround that can open a vulnerability to your LAN from your WAN subnet if you did so. BTW in OpenWRT, they're called Firewall Redirects, not [Static] Routes.

I also wonder how my setup works, yet I block everything on WAN, have no allow rule on LAN for IGMP, and only have an allow rule for the inbound 224.0.0.0/4 to the router...

I fear a troll's misguidance again...I agree, I also have those fw3 rules:

3412 119.95 KB ACCEPT 2 * * 0.0.0.0/0 0.0.0.0/0 /* !fw3: ubus:igmpproxy[instance1] rule 0 */

0 0.00 B zone_network2_dest_ACCEPT udp * * 0.0.0.0/0 224.0.0.0/4 /* !fw3: ubus:igmpproxy[instance1] rule 1 */

98 3.06 KB ACCEPT 2 * * 0.0.0.0/0 0.0.0.0/0 /* !fw3: ubus:igmpproxy[instance1] rule 2 */

Please be advised though, my RAW rule supersedes RULE 1 noted above (again, because I drop all low TTLs for security reasons). So, this only proves why I keep noting you do not need a rule for IP Protocol No. 4. I allow input on LAN by default, so only the single rule created for IGMP subscription responses on WAN is actively needed.

|4823|169.56 KB|ACCEPT|all|eth0.2|*|0.0.0.0/0|224.0.0.0/4|TTL match TTL < 7

|2548|79.62 KB|ACCEPT|all|br-network2|*|192.168.xxx.xxx|224.0.0.0/4|TTL match TTL < 7

(The lower rule is for other multicasting, not IGMP based.)
(and I should note...the packets automatically forward toward your default gateway.)

I agree...thanks for the bug report, and I'm glad quickleave did fix your issue!

46

Could you manually remove this rule and see if it still works? Really curious about it.

What does this line mean exactly?

Packets, size, rule, ?, interface, ?, source, destination, TTL match

47

Both lines show the same statistics...just results from an iptables list command as displayed in the LuCI web GUI....and I've showed you the rule in a previous post...

Which is why, I don't see how removing a rule with 0 packets hits and 0 bytes will prove your case otherwise...I don't have an issue with my IGMP Multicasting...I would have surmised that you would have requested the opposite - to have me remove my RAW rule to test, instead.

I'll update you of the results in a future post.

48

@Mushoz...I just realized something...

From: https://wiki.openwrt.org/doc/howto/udp_multicast

Firewall configuration
As with igmpproxy you need to accept IGMP traffic and also you need to allow it for INPUT:

config rule
option src wan
option proto igmp
option target ACCEPT

config rule
option src wan
option proto udp
option dest_ip 224.0.0.0/4
option target ACCEPT

As you may recall...you stated:

As you can see, the Wiki in fact says to make an INPUT rule regarding igmpproxy. It is correct...and I doubt the forward rule works for me...

So I removed the RAW TTL rules...it stopped working...

So why does my input work...perhaps because multicast_snooping is enabled...So, that brings us here:

From the Wiki:

Multicast forwading
With IGMP snooping, multicast forwarding is disabled for bridges. One pure bridge solution is to disable multicast_snooping.

Add the following in /etc/rc.local

echo "0" > /sys/devices/virtual/net/br-lan/bridge/multicast_snooping

Replace br-lan with your actual bridge interface, sometimes also called br0.
This will forward all multicast packets to all ports on your bridge, making igmpproxy or udpxy unnecessary.

49

Wouldnā€™t that flood all ports including wireless? It would kill wireless performance imho

1 Like
50

What would flood all ports???

If you mean the IGMP Snooping setup, yes, it would. Which is why it's not the recommended config. It even says in the Wiki such a config is:

So...those who enable IGMP Snooping are going against the Wiki's instructions - if they wish to properly setup igmpproxy.

51

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.

52

But...my devices (like most devices) still expect UDP traffic - per the Multicast protocol, though. I have no way to change that. Hence I can't use the UDP proxy.

Again, I agree...but those instructions also suggest enabling IGMP Spoofing...as you see, that disables multicast snooping...that's why you need the FORWARD (REDIRECT) RULE.

If multicast snooping is on, the router knows where the 224.0.0.0/4 packets are needed.

:grinning:

53

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 :slight_smile:

1 Like
54

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.

55

Regarding igmp snooping....

read the text more carefully

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?

@Mushoz
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?

56

@Mushoz, I deleted the FW3 IGMPPROXY rule...

root@LEDE:~# iptables -L zone_wan_forward --line-numbers

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 224.0.0.0/4, in addition, it's masqueraded to WAN.

Same results whether IGMP snooping was on or off:

Also...

root@LEDE:~# vi /sys/devices/virtual/net/br-lan/bridge/multicast_snooping

always showed:

1

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.

57

@shm0 and @Mushoz

It appears that igmpproxy creates the sockets...this would be on the OpenWRT...and therefore an INPUT rule...

I still can't explain why you all have success with FORWARD, save for the routes you created.

https://github.com/pali/igmpproxy/blob/master/src/udpsock.c

And this makes more sense at: https://wiki.openwrt.org/doc/howto/udp_multicast

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 224.0.0.0/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.

58

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.

I'm not sure what really is the confusion.

59

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 :slight_smile:

@lleachii mind posting your full configuration as well so we can get to the bottom of this?

Network:

root@LEDE:~# cat /etc/config/network 

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd76:7412:3e5b::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option igmp_snooping '1'

config interface 'wan'
	option _orig_ifname 'eth0.2'
	option _orig_bridge 'false'
	option proto 'pppoe'
	option ifname 'eth0.6'
	option username 'XXXXXXXXXXXXX'
	option password 'XXXXXXXXXXXXX'
	option ipv6 'auto'

config interface 'iptv'
	option proto 'dhcp'
	option ifname 'eth0.4'
	option vendorid 'IPTV_RG'
	option peerdns '0'
	option delegate '0'
	option defaultroute '0'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option vid '1'
	option ports '1 2 3 4 6t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option vid '2'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '3'

config switch_vlan
	option device 'switch0'
	option vlan '4'
	option vid '4'
	option ports '0t 6t'

config switch_vlan
	option device 'switch0'
	option vlan '5'
	option vid '5'

config switch_vlan
	option device 'switch0'
	option vlan '6'
	option vid '6'
	option ports '0t 6t'

config interface 'vpn'
	option proto 'wireguard'
	option private_key 'XXXXXXXXXXXXX'
	option listen_port '51820'
	list addresses '192.168.3.1/24'

config wireguard_vpn
	option public_key 'XXXXXXXXXXXXX'
	list allowed_ips '192.168.3.2'

Firewall:

root@LEDE:~# cat /etc/config/firewall 

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option target 'ACCEPT'
	option src 'wan'
	option name 'vpn'
	option family 'ipv4'
	option proto 'udp'
	option src_port '51820'
	option dest_port '51820'

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan'
	option log '1'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option mtu_fix '1'
	option masq '1'
	option network 'wan iptv'

config include
	option path '/etc/firewall.user'

config zone
	option name 'vpn'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option network 'vpn'
	option masq '1'

config include 'miniupnpd'
	option type 'script'
	option path '/usr/share/miniupnpd/firewall.include'
	option family 'any'
	option reload '1'

config forwarding
	option dest 'wan'
	option src 'vpn'

config forwarding
	option dest 'vpn'
	option src 'lan'

config forwarding
	option dest 'wan'
	option src 'lan'

config forwarding
	option dest 'lan'
	option src 'vpn'

config rule
	option enabled '1'
	option target 'ACCEPT'
	option src 'wan'
	option dest 'lan'
	option name 'iptv'
	option family 'ipv4'
	option proto 'udp'
	option dest_ip '224.0.0.0/4'

igmpproxy:

root@LEDE:~# cat /etc/config/igmpproxy
config igmpproxy
	option quickleave 0
#	option verbose 2

config phyint
	option network iptv
	option direction upstream
	list altnet 213.75.0.0/16

config phyint
	option network lan
	option direction downstream
60

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 :slight_smile: 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:

root@LEDE:~# cat /sys/devices/virtual/net/br-lan/bridge/multicast_snooping
0

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.