[SOLVED] IPTV, IGMPProxy and Firewall issues

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

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

1 Like

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.

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.

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:

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

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.

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?

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

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

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.

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

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.

I guess you're still not willing to re-admit that the Wiki may have an error...despite my showing you that igmpproxy also makes UDP sockets...OK, cool...

I told you that was from LuCI...just look at your own firewall page, same as yours. Also...RAW rules can only be INPUT, FORWARD is not an option with RAW.

Same [normal] thing from iptables:

root@LEDE:~# iptables -L -t raw
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DROP ipencap-- anywhere anywhere
DROP all -- !44.xxx.xxx.0/24 anywhere
ACCEPT all -- anywhere anywhere TTL match TTL < 7
ACCEPT all -- anywhere anywhere TTL match TTL < 7
ACCEPT udp -- anywhere base-address.mcast.net/4 TTL match TTL < 7
ACCEPT all -- 192.168.xxx.2 base-address.mcast.net/4 TTL match TTL < 7
DROP all -- anywhere anywhere TTL match TTL < 7

The confusion is that I contend that igmpproxy also proxies the downstream UDP traffic as well.

/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 'fd7e:xxxx:xxxx::/48'

config interface 'lan'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.xxxx.1'
	option igmp_snooping '1'
	option ip6addr '2001:470:xxxx:xxxx::1/64'
	option ip6prefix '2001:470:xxxx:xxxx::/64'
	option _orig_ifname 'eth0.1 radio0.network1 wlan0 radio1.network1 wlan1'
	option _orig_bridge 'true'
	option ifname 'eth0.1'

config interface 'wan'
	option ifname 'eth0.2'
	option _orig_ifname 'eth0.2'
	option _orig_bridge 'false'
	option proto 'dhcp'
	option peerdns '0'
	option delegate '0'
	option dns '74.82.42.42 156.154.70.5 198.82.247.98 44.60.44.3 2001:470:20::2 2001:468:c80:6101:0:100:0:62 2610:a1:1018::5'
	option macaddr 'xx:xx:xx:xx:xx:xx'

config interface 'wan6'
	option ifname 'eth0.2'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'
	option peerdns '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 '0t 1 4t'

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

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

config interface 'network2'
	option proto 'static'
	option type 'bridge'
	option igmp_snooping '1'
	option _orig_ifname 'eth0.3'
	option _orig_bridge 'true'
	option ifname 'eth0.3'
	option netmask '255.255.255.0'
	option ipaddr '192.168.xx.1'
	option ip6addr '2001:470:xxxx:xxxx::1/64'
	option ip6prefix '2001:470:xxxx:xxxx::/64'

config interface 'untrusted'
	option proto 'static'
	option ifname 'eth0.5'
	option netmask '255.255.255.0'
	option delegate '0'
	option ipaddr '192.168.xxx.1'

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

config interface 'amprnet'
	option type 'bridge'
	option proto 'static'
	option delegate '0'
	option _orig_ifname 'eth0.4'
	option _orig_bridge 'true'
	option ifname 'eth0.4'
	option ipaddr '44.xxx.xxx.1'
	option netmask '255.255.255.0'
	option broadcast '44.xxx.xxx.255'

config route
	option interface 'amprwan'
	option target '0.0.0.0'
	option netmask '0.0.0.0'
	option gateway '169.xxx.xxx.xxx'
	option onlink '1'
	option table '44'

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

config interface 'henet'
	option proto '6in4'
	option peeraddr '216.xxx.xxx.xxx'
	option ip6addr '2001:470:xxxx:xxxx::2/64'
	option ip6prefix '2001:470:xxxx::/48'
	option mtu '1480'

config interface 'amprwan'
	option _orig_ifname 'tunl0'
	option _orig_bridge 'false'
	option ifname 'tunl0'
	option proto 'none'

config interface 'guest_net'
	option proto 'static'
	option ifname 'eth0.6'
	option ipaddr '192.168.xxx.1'
	option ip6addr '2001:470:xxxx:xxxx::1/64'
	option ip6prefix '2001:470:xxxx:xxxx::/64'
	option type 'bridge'
	option netmask '255.255.255.0'

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

config interface 'inet_wireguard'
	option proto 'wireguard'
	option private_key '+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
	list addresses '192.168.xxx.2/30'

config wireguard_inet_wireguard
	option public_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
	list allowed_ips '0.0.0.0/0'
	option endpoint_host 'vpn.xxxxxx.net'
	option endpoint_port '55555'

config route
	option interface 'inet_wireguard'
	option target '10.xxx.xxx.0'
	option netmask '255.255.0.0'

config interface 'home_wireguard'
	option proto 'wireguard'
	option private_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
	option listen_port 'xxxxx'
	list addresses '172.xxx.xxx.1/24'

config interface 'azire_wireguard'
	option proto 'wireguard'
	option private_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
	list addresses '10.10.xxx.xxx/32'
	list addresses '2a03:8600:xxxx:xxxx::1f65/128'

config wireguard_azire_wireguard
	option public_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
	option endpoint_host '193.xxx.xxx.xxx'
	option endpoint_port 'xxxxx'
	list allowed_ips '0.0.0.0/0'
	list allowed_ips '::'

config rule
	option src '44.xxx.xxx.0/24'
	option dest '192.168.xxx.0/24'
	option priority '22'
	option lookup 'main'

config rule
	option src '44.xxx.xxx.0/24'
	option dest '192.168.xxx.0/24'
	option priority '23'
	option lookup 'main'

config rule
	option src '44.xxx.xxx.0/24'
	option dest '192.xxx.xxx.0/24'
	option priority '24'
	option lookup 'main'

config rule
	option dest '44.xxx.xxx.0/24'
	option priority '44'
	option lookup 'main'

config rule
	option in 'amprwan'
	option dest '0.0.0.0/0'
	option priority '45'
	option lookup '44'

config rule
	option in 'amprnet'
	option dest '0.0.0.0/0'
	option priority '46'
	option lookup '44'

config rule
	option src '44.xxx.xxx.0/24'
	option priority '47'
	option lookup '44'

I get:

Body is limited to 32000 characters; you entered 35522.

If i add firewall, that'll be a 2nd post.

My firewall is too long to post, but you've seen the relevant rules.

I still receive:

Body is limited to 32000 characters; you entered 35522.

but again, the only rules I created related to igmpproxy multicast is:

Custom /etc/firewall.user:

#Allow Multicast
iptables -t raw -A PREROUTING -i eth0.2 -d 224.0.0.0/4 -p udp -m ttl --ttl-lt 7 -j ACCEPT
#Final Drop
iptables -t raw -A PREROUTING -m ttl --ttl-lt 7 -j DROP

Again, I can remove the above 2 iptables rules and also make this working rule instead:

config rule
option target 'ACCEPT'
option src 'wan'
option family 'ipv4'
option proto 'udp'
option dest_ip '224.0.0.0/4'
option name 'Allow-UDP_Multicast_In'

It's official description is pretty meager but it explicitly says it only handles IGMP...

Based on that it seems like a forward rule would be the intended use...

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

  1. 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 (224.0.0.5) [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.

So it seems like maybe igmpproxy expanded it's scope and now the docs are out of date.

1 Like

This is not true. I have no such rule. The only rule I have added on top of the default Lede firewall rules is the UDP FORWARD rule for packets with destination 224.0.0.0/4.

Can you show the hits for this rule as well as results of:

ip route show

Also, we all agree that the igmpproxy script makes a FW3 rule to FORWARD to the downstream interface, so why is creating a second FORWARD rule necessary???